skip to content

In BPMN 2.0, what does a transaction sub-process add to an ordinary sub-process, and how do its cancel and hazard outcomes differ?

level: seniorimportance: nice to knowfreq 20%

answer

  1. double-line border
  2. three outcomes
  3. cancel end event inside
  4. hazard means no compensation

basics

~20 s

In BPMN 2.0 a transaction sub-process (double border) is controlled by a transaction protocol. It ends in success, cancel (rollback plus compensation of completed work, then a cancel boundary event) or hazard (interrupted without compensation, then an error boundary event).

solid answer

~50 s

A **transaction sub-process** is drawn with a **double thin line** and is governed by a transaction protocol. It has **three outcomes**. **Success**: every path reaches a non-cancel end event, the protocol confirms all participants succeeded, and the normal outgoing flow is taken. **Cancel**: triggered by a **cancel end event** inside the transaction or a cancel message from the protocol; the inner activities are rolled back and completed ones **compensated**, and only then does the flow leave through the **cancel boundary event**. **Hazard**: something went so wrong that neither success nor cancel is possible; an **error boundary event** catches it and the activity is interrupted **without compensation**. Cancel end and cancel boundary events are legal only for transaction sub-processes. For a loan, "Set up loan" (book account, reserve funds, register collateral) is a transaction: a rejected collateral registration cancels it; an unreachable core system is a hazard.

go deeper

for a junior

Recall the double border and that transactions have three outcomes: success, cancel and hazard.

for a middle

Explain which events are transaction-only (cancel end, cancel boundary) and that only cancel triggers rollback and compensation.

for a senior

Decide which failures are cancels with reliable compensation and which are hazards needing manual recovery, and model both exits explicitly.

for a principal

Judge whether coordinated transactional semantics are worth the protocol and compensation effort, or whether simpler explicit compensation serves the business.

## What makes a sub-process a transaction In BPMN 2.0 (OMG formal/13-12-09) a **transaction** is a specialised sub-process whose behaviour is controlled through a **transaction protocol**. Visually it is a rounded rectangle drawn with a **double thin line**, a border reserved for transactions. Its `method` attribute names the protocol used to commit or cancel; for an executable process it should be a technology-specific URI, and for compatibility with BPMN 1.1 it may be `##compensate`, `##store` or `##image`. An ordinary sub-process ends when its tokens are consumed. A transaction adds two things: an **agreed outcome** across all participants, and a **cancellation that includes compensation** of work already done inside it. ## The three outcomes | Outcome | How it arises | What happens to the inner work | How the flow leaves | |---|---|---|---| | Successful completion | all paths reach non-cancel end events and the protocol confirms every participant succeeded | kept | the normal outgoing sequence flow | | Failed completion (cancel) | a cancel end event is reached inside, or a cancel message arrives through the transaction protocol | cancellation actions: rollback and compensation of completed activities | the cancel intermediate event on the boundary, after rollback and compensation finish | | Hazard | something went so wrong that neither success nor cancel is possible | interrupted **without** compensation | an error intermediate event on the boundary | Two details make the table precise: - **Success is not immediate.** When paths reach non-cancel end events, the flow does not move straight back to the parent as it would from an ordinary sub-process. The protocol first verifies that all participants completed their part; if one of them reports a problem, the transaction can still end in cancel or hazard. - **Only cancel compensates.** The specification states that other ways of interrupting a transaction, such as an error or a timer, do not cause compensation. ## The events that belong to transactions 1. A **cancel end event** may be used only inside a transaction sub-process. 2. A **cancel boundary event** may be attached only to a transaction sub-process, never to another activity and never used in normal flow. It always interrupts. 3. An **error boundary event** on the transaction models a hazard, like an error on any activity. ## A loan-approval example Consider "Set up loan" as a transaction containing "Book loan account", "Reserve funds" and "Register collateral", each with a compensation handler ("Close account", "Release reservation", "Withdraw registration"). - **Success.** All three complete and the protocol confirms; the process continues to "Send welcome pack". - **Cancel.** The land registry rejects the collateral, so the model reaches a cancel end event. "Reserve funds" and "Book loan account" had completed, so they are compensated, then the flow leaves through the cancel boundary event to "Notify applicant". - **Hazard.** The core banking system stops responding mid-way, so nobody can tell what was booked. The error boundary event catches it and the flow goes to "Manual reconciliation"; no automatic compensation runs, because compensating from an unknown state could make things worse. ## When to use one - Use a transaction when several steps must **stand or fall together** and completed steps have well-defined reversals. - Use an ordinary sub-process with an explicit compensation throw when the business only wants "undo on cancel" and has no protocol coordinating participants. - Remember the cost: without a protocol and compensation handlers behind it, the double border is only notation. ## Mistakes to avoid - Drawing a cancel end event in an ordinary sub-process; it is only legal inside a transaction. - Expecting an error boundary event on a transaction to compensate; hazards do not. - Treating the double border as a database transaction; completed steps are reversed by compensation, not by an automatic undo.

  • In BPMN 2.0, why is compensation not run automatically on a hazard?
    A hazard means something went so wrong that neither normal success nor cancellation is possible, so the state of the inner work is unreliable. The specification interrupts the transaction without compensation and continues from the error boundary event, leaving recovery to the flow the modeller attaches there.
  • In BPMN 2.0, can a transaction that reached its end events still be cancelled?
    Yes. The flow does not return to the parent immediately; the transaction protocol first checks that every participant completed its part. If one reports a problem, the flow moves to the cancel or error boundary event even though the transaction had apparently finished.

saying these in an interview costs you the question

  • A cancel end event can end any sub-process.
  • A hazard compensates completed activities before the error flow.
  • A timer interrupting a transaction triggers compensation.
  • The double border alone makes the steps atomic, like a database transaction.
  • A transaction continues to its normal flow the moment its paths end.