Resolving Ignition Perspective Screen-Scraping Failures

What is the HTTP GET actually returning?

The operator sees 54, then 55 a minute later, in a Planned Qty label on a Perspective view. The browser's developer tools show the same number in the Elements pane. A script that calls system.net.httpClient() and client.get(url) against that page never finds it, even though the same line-number approach works on conventional server-rendered pages.

The script and the browser are not reading the same document. A server-rendered page puts its values into the HTML body, so the value can sit on a predictable line (line 22 in a working example) that a script re-reads on each poll. A Perspective page arrives as a small application shell of script references and a mount point. The browser runs that JavaScript, opens a live session back to the Ignition gateway, receives the view definition and bound property values, and then builds the DOM. The Elements pane in the developer tools shows that built DOM. It is not the HTTP response. An HTTP client that does not execute JavaScript stops at the shell, so no line number ever holds the quantity.

Check before moving on:

1. Fetch the page and dump the body. In Ignition the get() call returns a response object, so read the body from its text property (response.text) rather than splitting the response object directly.
2. Search the body for the value currently on screen.
3. Compare the body length with the size of the DOM in the Elements pane.

If the value is absent and the body is mostly script tags, the page is client-rendered. No parsing strategy on the raw GET will recover the value.

Where does the number on the screen come from?

Trace the label back to its source. The label's text property is bound to something on the gateway, usually a tag, a named query or database binding, or an expression that does the math. That binding is what you want to read. The screen is only a copy of it. Ask the team that owns the view to open it in the Designer, select the Planned Qty component, and report the binding type and path.

Check: you have one concrete path, either a tag path or a query, that returns the same value the operator sees right now.

How do I expose the value with a WebDev endpoint?

A Perspective page is always served by an Ignition gateway, even when it is not the gateway your scraping script runs on. Install the WebDev module on the gateway that hosts the page and add a Python resource that returns the value as JSON. This is the most durable fix. The endpoint returns data, not presentation, so moving or restyling a component on the view does not break it.

1. On the hosting gateway, install and license the WebDev module.
2. In the Designer for the project that owns the view, create a Python resource under WebDev, for example plannedQty.
3. Implement doGet to read the source identified in the previous step and return JSON.
4. Save the project and note the resource URL. WebDev resources are served under the gateway's /system/webdev/ path followed by the project name and resource name.

# WebDev Python resource: doGet
# Tag path is a placeholder; use the path found on the label binding
def doGet(request, session):
    qv = system.tag.readBlocking(['[default]Line1/PlannedQty'])[0]
    return {'json': {
        'plannedQty': qv.value,
        'quality': str(qv.quality),
        'timestamp': str(qv.timestamp)
    }}

Return the quality and timestamp along with the value. A consumer that stores data blindly will record a stale or bad-quality number as if it were good.

Check: open the resource URL in a browser. You should get a small JSON object, and plannedQty should match the label on the Perspective view within one refresh.

What if WebDev cannot go on the hosting gateway?

Sometimes the other team will not add a module or an API this iteration. Pick the lowest-coupling path that still reads the data rather than the pixels.

When both gateways run Ignition, a remote tag provider and a WebDev endpoint both work. The remote tag provider is the better choice for a value that changes once a minute. You get tag change events and quality natively, with no polling code. Choose WebDev when the consumer is not an Ignition gateway or when the value comes from a query rather than a tag.

Treat a headless browser as a stopgap only. It executes the JavaScript and exposes the built DOM, but each instance is a real Perspective session, and component selectors change whenever the view is edited.

Check: the chosen path returns the live value with a quality indicator, from the machine that will run the logger.

How do I poll and store only on change?

On the consuming gateway, replace the line-number parser with a JSON read in a gateway timer event script. Keep the last stored value in a memory tag so a gateway restart does not reset the comparison.

Set the timer rate from how fast the value actually changes. For a value that increments about once a minute, a poll every few seconds catches every change without loading the hosting gateway. Keep the timeout shorter than the timer period so calls do not stack up.

Check: watch the gateway logs for the logger name. A clean run produces no warnings, and the insert table gains one row per change, not one row per poll.

How do I prove the stored value matches the screen?

1. Open the Perspective view in a browser next to a query tool pointed at the insert table.
2. Wait for the Planned Qty label to step, for example from 54 to 55.
3. Confirm a new row appears with 55 and a source timestamp that matches when the label changed, within one poll period.
4. Confirm no duplicate row was written for the polls that ran while the value held steady.
5. Force a bad read by pointing the tag path at a disabled or missing tag, or by stopping the endpoint. Confirm the logger warns and no row is inserted.
6. Ask the view owner to move or restyle the label, then confirm logging continues unchanged. This proves the pipeline reads data, not layout.

FAQ