How Bridging Transactions Work

A Bridging transaction is a workflow that the system runs on your behalf: a sequence of activity blocks, drawn as a diagram, that reads data from somewhere, does something with it, and puts the result somewhere else. This topic explains what a transaction is made of and how data moves through it. For an introduction to the feature as a whole, see Bridging Overview; for how the engine schedules, retries, and distributes transactions across servers, see How Bridging Executes Transactions.

Core Elements

Bridging configuration is organized into three parts in the Bridging node in Workbench.

Element	Description
Transactions	A transaction is a single unit of work that the engine schedules and executes. It names the template to run and defines how it runs—retries, timeout, priority, recovery, and triggers. Transactions are grouped in folders beneath a transaction configuration node, which holds settings that apply to every transaction it contains, such as scheduling mode, thread count, logging database, and archiving. Learn more
Templates	A template is the workflow diagram itself: the activity blocks, the links between them, and the parameters the diagram accepts. Templates are designed in the Template Designer and can be reused by more than one transaction. Learn more
Variables	Variables are typed datasets that store values for use across activities and transactions. Local variables are private to a transaction instance; global variables are shared and are exposed as data points to the rest of the system. Learn more

The separation between a transaction and its template is what makes a workflow reusable. The template describes what to do; the transaction describes when to do it and under what conditions. Several transactions can share one template, each with its own triggers, global alias themes, and parameter values.

How a Transaction Runs

Every transaction begins at its Start activity and proceeds through the activities as the diagram links dictate, until it reaches an End activity that reports either Success or Failure. Within a single transaction, activities run one after another—concurrency in Bridging happens between transactions, not between the activities of one diagram.

Each link carries the outcome that causes the workflow to follow it, so the diagram can take a different path depending on what happened. Right-clicking an activity offers the link types that activity supports, such as:

• Add \<Completed> Link

• Add \<Failure> Link

• Add \<True> Link

• Add \<False> Link

• Add \<Canceled> Link

A Condition activity is the block that deliberately branches: its expression is evaluated atruntime, and the workflow continues along either the On True or the On False path. A link may also point backwards to an earlier activity, which is how a diagram repeats a set of blocks. Learn more

Because the engine works entirely in datasets, live data sources are converted to datasets at the moment of consumption:

• Single values from sources such as OPC UA, BACnet, or SNMP become a one-row dataset containing at least a value, quality, and a timestamp, plus any additional properties you request.

• Current alarms become a snapshot table of the active alarms at the moment the activity executes.

• Polled sources—database queries, web services, historical data, and .csv, .xml, or .json files—are read by reader activities, which control exactly when the read happens.

Activity Output Datasets

Every activity produces one output dataset, and that dataset is the only thing an activity hands to the rest of the workflow. Understanding this is the key to reading and building a diagram, because it explains both how activities are wired together and why an expression is written the way it is.

• Every activity produces a dataset, including readers of single values. A Real Time Input activity that reads one tag still returns a dataset: one row, whose first column is the point name and whose second column is the value. This is the most common source of confusion when an expression returns a tag name instead of a number.

• Activities can consume datasets from other activities. The Consume data from setting selects the dataset the activity works on: either Previous Activity or a specific activity named elsewhere in the diagram. An activity is not restricted to the block that precedes it.

• Completed outputs stay available. The output of an activity remains in memory for the life of the transaction instance, so an activity late in a diagram can read the dataset of one near the start. Activities are identified by name in these references, which is why every activity needs a meaningful, unique Activity Name. If a transaction hibernates, the outputs of the completed activities are saved with its state and restored when it resumes. Learn more

• Rows can be filtered. A Data Filter expression is evaluated once per row and decides which rows are passed to the output of a block, so you can narrow a large result set without adding an activity.

• Some activities iterate for you. The bulk activities—and the manipulators, writers, and Historical Upload—process every row of their input dataset in one step, evaluating their expressions once per row.

For the syntax used to reference a dataset, a cell, or a row count in an expression, see Bridging Dataset and Expression References.

Additional Data Inputs

There are other sources of values are available to any activity in the diagram:

• Parameters declared on the template, supplied per execution, and referenced as <<Name>>. Learn more

• Variables, local to the instance or global to the system, which persist a value between activities or between transactions. A variable is the standard way to hold a counter or an intermediate result. Learn more

• Trigger variables, exposing the attributes of the trigger or alarm that started the transaction, so a workflow can act on what caused it to run. Learn more