Tracking
A historical, searchable view of every step of every integration that has run on the platform — a capability no other middleware, BizTalk included, offers. Turn it on per port to record full step-by-step detail, then query it from a single screen.
Tracking is what makes a finished run inspectable. The runtime always keeps a thin internal record of in-flight messages so a suspended run can be resumed, a running run can be observed, and an errored run shows up where you would expect — that lightweight travel is independent of Tracking and is always on. Tracking is the historical layer on top of it: per-port, opt-in, and once enabled it persists the full step-by-step record of each run for later search and analysis.
This is the differentiator. BizTalk has tracking too, but Tracking in Art2link ESB stitches every step of an integration's execution together and lets you walk a single run end-to-end — or sweep a whole status category at once — through a single screen. No other middleware connects the steps the way this does.
Tracking is enabled per port, not per integration. Each port carries a single tracking-level setting with three values, ordered from lightest to most detailed:
| Level | What is recorded |
|---|---|
| Only on Error | Nothing is written for successful runs. On failure, the full step history is persisted including the message body at each step — there is no separate Only on Error + Body level; failure recording always includes the body. Cheapest level when failures are rare. |
| Enabled | Every run through this port is recorded — timestamps, step identifiers, message type, adapter. Message bodies are not stored. |
| Enabled + Body | Every run is recorded, including the full message body at each step. Most diagnostic, most expensive in storage. |
The tracking level toggle lives on the port itself, alongside the Exceptions option. See Ports → Options available on every port for the port-side description.
Tracking is filtered by the Selected Application. With a Selected Application set, every count and every row on the Tracking screen is restricted to that Application. With no Selected Application, the screen spans every Application the user has access to. The behaviour matches every other artifact list in the platform.
The Tracking screen is laid out in three regions, top to bottom — status boxes, a filter strip, and a results grid.
1. Status boxes. Five boxes at the top, each showing a status name and a live count: Successful Running Suspended Exceptions Errors. Clicking a box loads the matching records into the grid below; the same box also exposes an action menu that applies to the entire count at once (see Actions).
2. Filter strip. A row of filters that narrow what the grid shows: Tracking ID, Start Date, End Date, and Message Type. Filters compose with the active status box and with the Selected Application.
3. Results grid. One row per integration run, sortable by start time, with the originating port, message type, and start timestamp visible. Expanding a row reveals the run's full step-by-step history — see Step-by-step drill-down.
| Status | Meaning |
|---|---|
| Successful | The run completed end-to-end without raising an error. |
| Running | The run is currently in flight on one or more ports. Counts in this box are live and can change between refreshes. |
| Suspended | The run is paused and waiting on operator action. Resumable, or terminable, from this screen. |
| Exceptions | The run failed, and the failure was handled by the port's configured exception: the port had a Message Type assigned for the failure path, the runtime emitted a message of that type onto the bus, and any subscriber to it (an alert send port, a log writer, a downstream compensation flow) picked it up. See Ports → Options available on every port for how to configure an exception path. |
| Errors | The run failed and the failure was not handled — either the port had no configured exception, or the configured exception itself raised an uncaught fault. |
Actions are identical whether triggered on a single row or on the whole status box. The box variant applies the action to every record currently in that status, scoped by the active filters.
| Status | Available actions |
|---|---|
| Successful | — |
| Running | Terminate Suspend |
| Suspended | Terminate Resume |
| Exceptions | — |
| Errors | — |
Expanding a row in the results grid exposes the full step-by-step history of that run — one line per step, in execution order, across every port the run touched. The columns are:
| Column | What it shows |
|---|---|
| Timestamp | When the step executed, to the second. |
| Port | The port that owned this step. |
| Step ID | A numbered identifier for the lifecycle stage (adapter, pipeline, map, variables on entry / on exit, and so on). Hover the badge to see the stage's human-readable name. The full enum of step IDs is published separately as a reference. |
| Type | The port type the step belongs to, with a color matching the Ports palette: Receive bronze, Send blue, Loopback sage, Null rose. See Ports for the port-type model. |
| Adapter | The adapter bound to the port, when relevant. Loopback and null ports have no adapter and leave this column blank. |
| Message Type | The Message Type carried by the run at this step. |
| Body | A preview of the message body at this step. Populated only when the originating port was set to Enabled + Body; otherwise the column is blank for that step. Clicking the preview opens the full body. |
Every integration run is stamped with a single Tracking ID when it enters the platform. The same ID flows through every port the run touches, which is what lets the screen reassemble one logical run from steps recorded by different ports. Use the Tracking ID filter on the top strip to recall the complete history of one specific run, even months later.
That's Tracking
Set the level you need on each port, run integrations, and the Tracking screen is where the history of every run lives — searchable, drillable, and bulk-actionable.