Documentation Index

Fetch the complete documentation index at: https://docs.turbo360.com/llms.txt

Use this file to discover all available pages before exploring further.

Transaction stages

Prev Next

Overview

In Business Activity Monitoring (BAM), transaction stages represent the checkpoints or milestones within a business transaction. Each stage captures a distinct point in the lifecycle of a unit of work — for example, a message received, a process completed, or an error encountered.

In the Pull Model, stages are not instrumented by your integration solution. Instead, they are derived from query results. You configure each stage by defining a query against your App Insights, Log Analytics, or Azure Data Explorer (ADX) data source and mapping the fields in the query output to the stage properties BAM tracks.

Business value

Pull Model stages let you decompose an existing integration workflow into meaningful, observable steps — without touching the integration itself. You can surface multi-stage business visibility from telemetry that was already being written, giving your operations team a structured view of where work stands at each point in the process.

How it works

A stage in the Pull Model is a configuration within a business transaction that defines:

  • The query to run against the configured data source
  • Which query result field to use as the stage timestamp
  • Which fields to map to tracked properties for that stage
  • The expected sequence position of the stage within the transaction

When BAM runs the scheduled query for a transaction, it evaluates each configured stage independently. A stage is considered complete for a given transaction instance when the stage query returns a result that correlates to that instance's identifier.

A few things to keep in mind:

  • Each stage has its own query. Stages within the same transaction can query different tables or apply different filters in the same data source.
  • Stage order defines the expected sequence. BAM uses this to determine whether a transaction instance is progressing normally, is delayed, or has failed to reach a stage within the expected window.
  • A stage is identified by its correlation to the transaction instance. The same correlation property used to identify the instance is used to match stage results to the correct instance.
  • Stages in the Pull Model are read-only with respect to your source data — BAM evaluates query results but never writes back to App Insights, Log Analytics, or ADX.

The Pull Model and Push Model stages track the same outcome through different mechanisms. In the Push Model, your integration solution explicitly emits an event for each stage — BAM receives the event and records the stage as it happens. In the Pull Model, BAM discovers stage completion by querying for evidence that the stage occurred.

Related articles