Overview
This article answers common questions about defining business processes, configuring transactions, setting up stages, and managing transaction instances in the Business Activity Monitoring (BAM) Push Model.
Business value
Business processes and transactions are the core of BAM. Understanding how they relate to each other, how stages map to your source application's logic, and how instances are created and managed helps you model your integrations accurately from the start.
How it works
This article covers questions across four areas: business process and transaction structure, stage configuration, instance behavior, and lifecycle management. Questions progress from initial modeling decisions through to day-to-day instance management.
FAQs
-
What is the relationship between a business process, a transaction, and a transaction instance?
A business process represents an end-to-end integration scenario — for example, "Order processing" or "Invoice approval". A transaction defines the trackable unit within that process, including the stages it passes through and the properties BAM uses to identify and correlate messages. A transaction instance is a single execution of that transaction — one order, one invoice — created automatically when BAM receives a message matching the transaction definition. See Business transactions and Transaction instances for conceptual detail. -
How many stages can a transaction have?
There is no fixed maximum on the number of stages a transaction can have. However, each stage adds to the matching and evaluation work BAM performs on every incoming message. For practical performance and maintainability, Turbo360 recommends keeping stage counts proportionate to the complexity of the integration — typically between three and ten stages for most business processes. See Transaction stages for guidance on stage design. -
How does BAM correlate incoming messages to the correct transaction instance?
BAM uses the correlation ID included in each incoming message to match it to an existing transaction instance. If no instance exists with that correlation ID, BAM creates a new one. The correlation ID must be consistent across all messages belonging to the same transaction execution — it is the primary key BAM uses to assemble a complete instance from multiple stage messages. See 101 - Sending data to the BAM API for the required message schema. -
Can I add or change stages on a transaction that already has active instances?
Yes, you can modify stage configuration at any time. Changes apply to new instances — messages received after the change will be evaluated against the updated stage definitions. Existing open instances continue to be evaluated against the stage configuration that was active when the instance was created. Closed instances are not retroactively updated. -
What is the purpose of stage reprocessing, and when should I configure it?
Stage reprocessing allows BAM to trigger a retry of a failed stage by sending the original message back through the source application's processing logic. Configure reprocessing on a stage when the integration failure is transient — for example, a temporary unavailability of a downstream service — and retrying the same input is likely to succeed. Do not configure reprocessing for stages where the failure requires human intervention or data correction before retrying. See Configuring reprocess for transaction stages. -
How do I group related business processes together in the BAM interface?
Use business process groups to organize processes that belong to the same domain or team. A group is a logical container — it does not affect tracking behavior, but it improves navigation when you have a large number of processes. See Managing business process groups for setup instructions. -
Can I delete a transaction instance manually, and will that affect reporting?
Yes, individual transaction instances can be deleted from the tracking view using the available actions. Deletion is permanent — the instance is removed from BAM and will not appear in any subsequent queries or reports. Use deletion only for test instances or instances created in error. For genuine failed instances, prefer reprocessing or manual status update over deletion so the audit history is preserved. See Actions in transaction instances.