Overview
A business transaction is the core tracking unit in the Push Model. It represents a single, named workflow that your organisation wants to monitor end-to-end — for example, an order fulfilment flow, an invoice approval, or a data pipeline run.
Each business transaction belongs to a business process, which groups related transactions together. Within a transaction, you define the stages that make up the workflow, the tracking properties BAM extracts at each stage, and the correlation mechanism that links events from different stages into a single traceable run. Each execution of a transaction produces a transaction instance.
Push Model business transactions use the Custom Logging type. Your integration solution emits events directly to the BAM API at each stage checkpoint, and BAM assembles those events into tracked instances in real time.
Business value
Business transactions give operations and development teams a consistent, named view of every workflow execution across their Azure integrations. Instead of inspecting raw logs or jumping between Azure services, you can see at a glance whether a transaction completed, failed, or is still in progress — and exactly where in the flow it stopped.
How it works
When you define a business transaction, you configure four things:
- Type — Set to Custom Logging for all Push Model transactions. This tells BAM to expect events sent directly from your integration solution via the BAM API at runtime.
- Stages — The ordered sequence of checkpoints in the workflow (e.g. "Received", "Validated", "Dispatched"). Each stage corresponds to a meaningful milestone your integration explicitly reports.
- Tracking properties — Key-value pairs extracted from each event payload (e.g.
OrderId,CustomerId). BAM uses these to correlate events from different stages into the same transaction instance. - Correlation — The shared property value — such as a unique order ID — that your integration passes at every stage. BAM uses this to assemble a complete, coherent instance across all stage events.
At runtime, each event emitted by your integration solution makes an HTTP call to the BAM API. BAM receives the event, matches it against the configured transaction and stage, and creates or updates the corresponding transaction instance. The result is a live, searchable record of every execution.
Each business process can contain multiple transactions. Each transaction can contain multiple stages.
Limitations
- A transaction can only belong to one business process. Moving a transaction to a different process requires recreating it.
- Tracking property names must be consistent across all stages. Mismatched names prevent BAM from correlating events into a complete instance.
- The Custom Logging type cannot be mixed with the Data Queries type within a single transaction.
- Deleting a transaction permanently removes all associated transaction instances and stage data.