Processing boundary and timing control
Processing boundary and timing control defines when processing occurs and how work is grouped during order processing. By configuring transactions, events, and commit and rollback behavior, you control how and when system logic runs and how processing results are finalized.
This configuration helps ensure predictable processing, maintains data consistency, and provides controlled handling of errors and retries as orders move through workflows.
Overview
Processing boundary and timing control configuration governs how order processing work runs, not how teams structure workflows or define logic. It defines where processing begins and ends. It also defines when execution starts and which rules control commit and rollback behavior.
Transactions, events, and related dependencies provide a controlled execution model that supports reliable processing across complex workflows. This layer works closely with order processing workflows, conditions, actions, and services, but focuses specifically on execution timing and consistency.
Transactions in order processing
Transactions define execution boundaries within order processing. Each transaction represents a unit of work that groups related processing steps together and controls how changes are applied.
Within a transaction, processing follows one of two outcomes.
- Processing either completes successfully and commits changes, or
- Fails and rolls back changes to maintain consistency
Transactions help ensure that orders do not enter partial or invalid states during processing.
Types of transactions
Different transaction types support different execution scenarios:
- Externally triggered transactions start in response to external events or integrations.
- User‑triggered transactions start when a user performs an action in the system.
- Time‑triggered transactions start based on schedules or elapsed time.
Choosing the appropriate transaction type helps align execution behavior with how processing is initiated.
Transaction dependencies
Transaction dependencies define relationships between transactions and control execution order. Dependencies help ensure that related processing steps occur in the correct sequence and that downstream transactions run only after required work completes.
These dependencies help coordinate complex processing scenarios without tightly coupling execution logic.
Events
Events represent significant moments during order processing, such as transaction completion or status changes. Events provide trigger points for other processing without embedding logic directly in workflows or transactions.
By using events, you can respond to lifecycle changes in a consistent and loosely coupled way.
Defining transactions for process steps
Transactions are associated with specific process steps to control execution timing within workflows. Defining transactions at these points determines when work runs, how it is grouped, and how processing outcomes are handled.
This configuration enables consistent execution behavior across different workflows and processing scenarios.
Commit and rollback behavior
Commit and rollback behavior defines how the system finalizes or reverses changes that are made during transaction execution.
- Commit makes changes permanent when processing completes successfully.
- Rollback reverses changes when processing fails or cannot complete.
This behavior protects data integrity and helps ensure that orders progress through workflows in a controlled and predictable manner.
How this configuration is used
Processing boundary and timing control configuration supports several key aspects of order processing.
- Reliable execution of transactions within workflows
- Controlled sequencing of processing activities
- Safe handling of errors, retries, and exceptions
- Consistent integration behavior across internal and external systems
Because this configuration influences how processing is applied and reversed, evaluate changes carefully for downstream impact.