In BPMN 2.0, what is the difference between an interrupting and a non-interrupting boundary event attached to an activity?

## Boundary events in BPMN 2.0 A **boundary event** is an intermediate event drawn on the edge of a task or sub-process. In BPMN 2.0 (OMG formal/13-12-09) it is always a **catching** event, it has no incoming sequence flow, and it must have an outgoing sequence flow (compensation is the exception, covered below). It is only live while the activity it is attached to is running: new non-interrupting handlers may be created only while the activity is in the Active state. Boundary events model what can happen *to* an activity while it runs: a deadline passes, a message arrives, an error or an escalation is raised inside it. The specification allows these triggers on a boundary: message, timer, error, escalation, cancel, compensation, conditional, signal, multiple and parallel multiple. ## Interrupting versus non-interrupting The difference is controlled by one attribute, **`cancelActivity`** on `boundaryEvent`, and shown by the event's border. | | Interrupting | Non-interrupting | |---|---|---| | Border | solid double circle | dashed double circle | | `cancelActivity` | `true` (the XML schema default) | `false` | | Attached activity | terminated when the event fires | keeps running | | Tokens after the event | one, on the boundary event's flow | two: one still in the activity, one on the boundary flow | | Can fire again? | no, the activity is gone | yes, handlers may run concurrently while the activity is active | The specification's own wording for the interrupting case: whenever the event occurs, the associated activity is terminated and a downstream token is generated on the unconditional sequence flow leaving the event, called an **exception flow**. For a multi-instance activity, all of its instances are cancelled. For the non-interrupting case: the activity continues to be active and a token is generated for the boundary flow in parallel, so "care MUST be taken" when that flow is merged back into the main flow; typically it should be ended with its own end event. ## Which triggers allow which mode Table 10.92 of the specification lists the permitted values of `cancelActivity` per trigger: - **Message, timer, escalation, conditional, signal**: true or false, the modeller chooses. - **Multiple**: true or false only if every contained trigger allows it; otherwise the more restrictive value. - **Error**: always true. An error boundary event always interrupts; there is no dashed error event. - **Cancel**: always true, and it may be attached only to a transaction sub-process. - **Compensation**: not applicable. Compensation can only be triggered after the activity completed, so there is nothing left to interrupt; the border is always solid and the event connects to its compensation activity by an association, not a sequence flow. - **None** and **link** events can never be attached to a boundary. ## The order-fulfilment example Consider a receive task "Await payment" in an order-fulfilment process, with three boundary events: 1. An **interrupting timer**, 48 hours. If no payment arrives in time, the wait is cancelled and the exception flow leads to "Cancel order". Only one token exists afterwards. 2. A **non-interrupting timer**, 24 hours. After a day the process sends "Payment reminder" while "Await payment" keeps waiting. Two tokens now exist for this order. 3. An **interrupting message** event, "Cancellation received". If the customer cancels first, the wait stops and the flow goes to "Release stock". Whichever interrupting event fires first wins: once the task is cancelled, its other boundary events stop listening. If the payment message arrives first, the task completes normally, its outgoing sequence flow carries the token to "Ship order", and none of the boundary events fire any more. ## Mistakes interviewers look for - Believing a non-interrupting event **pauses** the activity. It does not; both paths run at the same time. - Believing an interrupting event lets the activity **finish first**. The activity is terminated when the event occurs. - Merging a non-interrupting branch back into the main flow with an exclusive merge, which lets the extra token run the rest of the process a second time. - Drawing a dashed **error** event. Errors are critical and always interrupt; a non-critical notice from inside the activity is modelled as an **escalation** instead. - Forgetting that the XML default is `cancelActivity="true"`: omitting the attribute produces an interrupting event even if the diagram was meant to be dashed.