Bridging Logs and Statistics

Bridging keeps a record of every transaction it runs and its outcome. The engine also publishes live counters describing the engine status in real time.

Transaction Log

Each execution of a transaction produces one log record. While the transaction is running, the record holds its current state, the instance identifier, the account that started it, the global alias themes and parameter values it uses, the trigger that caused it, when it started, which retry it is on, and the last reported error. When the transaction finishes, the record is moved to the completed set together with the detailed trace of the run.

The trace is organized in two levels, and both are visible to clients through the Bridging .Query data point:

  • Activity traces—one entry per activity execution, recording its name and type, its state, when it started and ended, how long it ran, which retry it was on, the activity that followed it, and any error it reported. An activity that repeats in a loop produces one entry per pass.

  • Data step traces—entries recorded within an activity, naming each step the activity performed and the value it produced. Data steps are where you see an expression being evaluated and what it evaluated to—for example, a Parameter Expression Evaluation step showing the resolved value of a parameter.

Selecting the Level of Detail to Keep

The amount written to the log is set per transaction on the Transaction Settings tab, under Advanced Settings. Detail is valuable while you build a workflow and costly once it runs in production, so these settings are meant to be revisited.

Setting

Description

Execution Log

Determines how much is recorded. You can select one of the following options:

  • Trace only workflow messages
  • Trace workflow and activity information
  • Trace workflow information, activity information and every data step within the activity

Log Only Failed Transactions

Available when the log records more than workflow messages. Keeps the detailed trace only for executions that failed.

Maximum activities logged

Limits the log to the specified number of the most recent activity entries, counting both retries and repeats in loops, so a transaction that loops many times does not produce an unbounded log.

Develop with the data step level selected, and then reduce the detail before the transaction goes into production. Data step tracing writes an entry for every expression evaluation in every activity.

Storing and Archiving the Log

Log records are written to the Bridging runtime database. By default, this is the GENESIS configuration database; to send the records elsewhere, select Use a custom database for logging on the Transaction Configuration and supply a Connection String.

Because the log grows with every execution, each Transaction Configuration has its own archiving policy under Archiving. Archiving moves old records out of the runtime database and into files in the selected folder.

An archived record is removed from the runtime database, so it no longer appears in the Bridging Viewer or in a .Query result.

Live Statistics

Alongside the log, the Bridging point manager publishes data points that describe the engine's current activity. Because they are common GENESIS points, you can trend them, set an alarm on them, show them in a display, or collect them in the Data Historian—the same as any process value.

  • Server counters report how much work is in flight: how many transaction requests have arrived, how many are running, how many succeeded, failed, were canceled or rejected, how many are hibernating, and how long the queue is.

  • Per-transaction points report the state of a single transaction: whether it is active, when it last executed and with what status, how long the execution took, and the last error it reported.

  • Performance counters expose the same engine measurements to Windows performance monitoring tools, which is useful for correlating Bridging throughput with system-wide CPU and memory behavior.

For the names of the individual points and counters, see Bridging Data Points.

A sustained queue length or a growing gap between requested and completed transactions is the signal that a configuration is undersized. The remedies are the thread count, the transaction priorities, hibernation, and distributed scheduling. Learn more

Reading the Log and Statistics

You can view Bridging logs and statistics using various GENESIS components.

GENESIS component

To display the data

Workbench

In Project Explorer under Bridging > Transactions, right-click the desired transaction, select Test Transaction to run it, and read the Transaction Log for that run immediately.

GraphWorX

Do one of the following:

  • In the runtime mode, select Bridging in the Tools section of the Runtime ribbon to open Transaction Manager, then select the transaction you want to execute, and download the execution logs.
  • Create your own display built from the Bridging Navigator, Bridging Viewer, and Table controls, or open an existing one. Learn more

Data Explorer

Browse the bwx: point manager to read the counters and per-transaction points, and to inspect the .Query dataset directly. Learn more

TraceWorX

View diagnostic messages from the Bridging point manager, the workflow engine, the logging service, and the archiver. These trace logs pertain to the point manager directly and not necessarily to individual transactions. Learn more