Skip to main content

How a flow is executed

A flow describes which data is moved from where to where under which conditions. This page describes what the runtime does with this information: the order in which the transfer objects are processed, how many flows run simultaneously, and what happens to the rest of the flow if an error occurs.

The order is determined during configuration​

You do not define the order of the transfer steps manually—the OPC Router calculates it based on the Item Links in the flow:

  • A transfer object is assigned its step number only after all transfer objects from which an Item Link leads to this object have been numbered. This means an object never runs before the objects that supply it with values.
  • If the flow branches, multiple objects may be due to run at the same time. In that case, their vertical arrangement on the design surface determines the order: the object located higher up runs first. Arrange the objects accordingly if the order is important to you.

You can see which step an Item Link belongs to by hovering the mouse over it. The calculated order is part of the engineering and is transferred to runtime via “Publish” ; it is not recalculated at runtime.

A transfer, a worker thread, one step at a time​

A running transfer occupies exactly one of the worker threads that the OPC Router reserves for transfers and processes the transfer steps strictly one after the other. There are no parallel branches within a flow:

  • If the flow branches, the branches are processed sequentially, not simultaneously.
  • If multiple branches converge again, the converging object is not processed until all of its predecessors have been processed.

A slow step therefore delays the entire rest of the flow. You can achieve concurrency by using multiple flows, not by the order of steps within a single flow.

Only one transfer runs at a time per trigger​

A trigger always starts only one transfer at a time: Only after its transfer is complete can the same trigger trigger the next one.

During an ongoing transfer, the transfer objects associated with triggers that did not initiate that transfer are skipped. Whether a single trigger is sufficient or all triggers must be triggered is determined by the trigger link; see Settings for Flows and Templates .

What Happens in Case of an Error​

The rest of the transfer is canceled​

If a transfer step fails, the OPC Router will not execute the remaining steps of that transfer. The completion process still runs through all transfer objects in the flow—including those that were no longer scheduled to run. This ensures that no trigger remains stuck in its triggered state, and the next transfer can begin.

The aborted transfer is not repeated. The flow itself remains ready: The next trigger starts a new transfer, beginning again at the first step.

Protecting Part of the Flow Against Errors​

If a part of the flow is to be able to handle an error, enclose it using the error handling (Try/Catch) transfer object. The section to be protected is located in the TRY branch and can be retried multiple times if desired; an optional CATCH branch handles the final failure and provides the error information. An error handled in this way does not terminate the transfer—nor does one that the transfer object swallows without a CATCH branch.

If the target system has failed​

An error caused solely by the remote system being temporarily unavailable does not have to result in data loss: With "" and "Store and Forward" , the OPC Router temporarily stores the data and forwards it as soon as the transfer is possible again. Store and Forward can be enabled globally and additionally on a per-flow basis; see Settings for Flows and Templates .

Troubleshoot the error​

The failed transfer appears in the Flow Status as a red transfer point; if you hover over the faulty transfer object in the flow, the OPC Router displays the details. The flow node in the status tree also displays the most recently reported status as a colored dot—the correspondence between colors and statuses is described at Colors in the Status Tree . Additional information recorded by the OPC Router can be found in the event log and in the log files .

Subprocesses and repetitions occupy the same worker thread​

A called subprocess —a branch or a function (FX)—does not run on its own thread, but within the current transfer on the same worker thread. The caller waits until the sub-process is complete. The [ property limits how deeply calls can be nested by setting the maximum call depth for sub-processes ](../plug_in/additional_functions/unterablaeufe/README.md#nesting-and-maximum-call-depth), with a default value of 16.

The error-handling (Try/Catch) transfer object does not enclose its own flow, but rather serves as the caller of two such sub-processes: the TRY branch and the optional CATCH branch. If repetition is enabled, the transfer waits at this object until all attempts, including their wait times, are complete—the worker thread remains occupied for that duration. Therefore, when repetition is enabled, check whether the maximum possible sum of attempts and wait times still fits within the flow timeout.

How many flows run simultaneously​

By default, the OPC Router allocates 80 worker threads for transfers, plus 5 additional threads reserved for high-priority flows. If all threads are in use, any additional triggered transfers wait in a queue; there is one queue per flow priority .

  • The 80 general worker threads process high-priority transfers first, followed by normal-priority, and then low-priority transfers.
  • The 5 reserved worker threads process only high-priority transfers.

A transfer in progress is never interrupted. A higher priority gives a flow precedence in the queue and—in the case of high priority—additional worker threads; it does not displace a transfer that is already in progress. Therefore, “overload” means that the triggered event waits until a worker thread becomes available.

The "System Load" card in the service status at shows how many transfer requests could not be processed immediately—either for general workers or for high-priority workers.

The flow timeout limits the load​

Because a running transfer is not preempted, the OPC Router instead limits its runtime: Each flow has a flow timeout ; if not specified, the default is 300 seconds. As soon as only 15% of the allowed runtime remains, the OPC Router issues an early warning.

Set a custom flow timeout for flows that are expected to take longer—for example, because they process large query results or involve iterations.

Triggering a Flow Manually​

You don’t have to wait for a trigger to run a test: In the status tree of the Status Display, right-click on the flow and select “Trigger Flow”.” The flow does not require a trigger for this. For information on how these transfers appear in the status chart and what additional data is logged, see Flow Status.