Handling Delays When Syncing Ignition Gateway Data with SAP via REST API

[britanneywiley]

I’ve been working on a project where Ignition Gateway exchanges production order and equipment status data with an SAP S/4HANA system over REST APIs. The integration mostly runs fine, but I’m seeing random delays when there’s a burst of tag updates. Sometimes the data reaches SAP immediately, but the acknowledgment or callback takes a few minutes to show up in Ignition’s event scripts.

The network and server performance look normal, so I’m wondering if Ignition might be queuing or reusing sessions in a way that causes temporary hold-ups. Has anyone come across similar behavior when connecting Ignition to SAP or other enterprise systems? I’d be really interested to hear how you’ve handled things like throttling, retries, or connection pooling to keep the sync reliable during heavy loads.

I’ve been reviewing a few integration resources and also revisited some Pass4Future SAP’s exam practice material to better understand SAP’s response handling, but I’d love to get some real-world insight from people who’ve tuned Ignition for high-volume REST communication.

Appreciate any thoughts or experiences you can share.

[Kevin.Herron]

@britanneywiley

or callback takes a few minutes to show up in Ignition’s event scripts.

Are you doing all of this from tag event scripts?

[britanneywiley]

@Kevin.Herron

Are you doing all of this from tag event scripts?

Hi Kevin!

Thanks for getting back to me, Yes, exactly, I’m handling everything within tag event scripts at the moment. The callback delay seems inconsistent; sometimes the SAP acknowledgment shows up right away, other times it lags by a few minutes even though the data transfer itself completes successfully.

I’ve been testing whether the tag event queue or script execution context in Ignition could be introducing the delay, especially under heavier tag update loads. I’m considering moving the REST call logic to a gateway event or message handler to see if it improves response consistency.

[David_Stone]

@britanneywiley

tag event scripts

Best practices and pitfalls with Tag Event Scrips

I use system.util.invokeAsynchronous() extensively in tag change scripts, as we were running into performance issues. The pitfalls Kevin mentioned about the guaranteed order of events does not apply to my use case. Your example may be massive improved if refactored with the new reading functions to only read (blocking) and write (async) once. Pseudo-code: val = currentValue.value readlist = [] for i in range(1, 33): packPath = str(tagPath).replace("Battery/inNumberOfPacks","Pa…

[pturmel]

To add to David's linked advice:

It is unsafe for the tag system for you to do your API calls from tag events (on the tag or called from the tag). Or any other operation that requires traffic across a network with indeterminate timing. (Database calls, most tag writes, any OPC direct calls, et cetera.)

Move all such operations to Gateway events (in the project, subscribed to tags but not on the tag). Possibly in timer events, for anything that needs to be paced.