skip to content

In a BPMN 2.0 process run by an engine, which elements make an expense-claim instance wait, and when does the instance complete?

level: juniorimportance: should knowfreq 35%

answer

  1. tokens stop where something external must happen
  2. people, messages and clocks
  3. catching, not throwing
  4. no token left, nothing active

basics

~20 s

In BPMN 2.0 an instance waits at user tasks until the assignee finishes, at receive tasks and catching message events until the message arrives, and at timers until they fire. It completes when no token remains and no activity is active.

solid answer

~40 s

Under the BPMN 2.0.2 execution semantics, a **start event** occurring creates a process instance and a token. The token moves on without pause through elements that finish on their own, such as a **send task**, and waits wherever completion depends on something outside the engine: a **user task** is distributed to the assigned person or group and completes when the work is done; a **receive task** waits for its message; a **catching intermediate event** (message, timer, signal, conditional) waits from the moment it is reached until the event occurs. A service, script or business-rule task waits only for the called service, script or rule to finish. The instance **completes** when no token remains and no activity is still active; a token reaching a **terminate end event** ends the whole instance abnormally.

go deeper

for a junior

Recall the waiting elements: user tasks, receive tasks and catching intermediate events such as timers and messages.

for a middle

Explain the completion rule: no tokens left and no active activities, with terminate end events ending everything abnormally.

for a senior

Diagnose stuck instances by finding the token parked at a wait whose trigger, message or assignee cannot occur.

for a principal

Weigh how many long waits a process should hold, since each is state the organisation must monitor and eventually clean up.

## The expense-reimbursement process as an engine sees it The analyst's model: an employee submits a claim (start event), the line manager approves it (user task), the process waits for scanned receipts from the expense-capture service (receive task), a reminder fires if the receipts do not arrive in five days (timer event), finance pays (service task) and the employee is notified (send task). An engine that claims **Process Execution Conformance** runs this according to the execution semantics chapter of BPMN 2.0.2. That chapter describes behaviour in terms of **tokens**: a start event creates one, it moves along sequence flows, elements consume and produce tokens, and an instance lives as long as tokens or active activities remain. ## Where the token waits | Element | Behaviour on activation | What ends the wait | |---|---|---| | **User task** | distributed to the assigned person or group | the person completes the work | | **Receive task** | begins waiting for the associated message | the message arrives; its data is assigned to the task's data output | | **Catching intermediate event** | waiting starts when the event is reached | the event occurs and is consumed | | **Service task** | invokes the operation with the task's data input | the service completes, or returns a fault treated as an error | | **Business rule task** | calls the associated business rule | the rule completes | | **Script task** | invokes the script | the script completes | | **Send task** | fills the message from its data input and sends it | completes immediately after sending | Two groups are worth separating in an interview: - **Human and external waits.** User tasks, receive tasks and catching events wait for something the engine does not control. These are what are usually meant by wait states, and they are where an instance can sit for days. - **Call-and-return work.** Service, script and business-rule tasks are active while the call runs, then complete. They wait for the called work, not for a person or an outside party. A **manual task** is a special case: the standard calls it a conceptual model only, never actually executed by an IT system, and lists it among the **non-operational** elements an execution-conformant engine may ignore. ## How the instance starts A process is instantiated when one of its **start events** occurs, and each occurrence creates a new instance, unless the start event takes part in a conversation with other start events, in which case correlation routes later events to the existing instance. A **receive task** with no incoming sequence flow and its `instantiate` attribute set to true can also start an instance. ## How the instance completes The standard states that an instance is completed if and only if: 1. there is **no token** remaining in the instance; 2. **no activity** of the process is still active; and 3. if it was created through an instantiating parallel event-based gateway, all the events after that gateway have occurred. All tokens must reach an **end node**, a node without outgoing sequence flows. A token reaching an **end event** triggers its result, for example sending the message of a message end event. A token reaching a **terminate end event** abnormally terminates the entire instance, cancelling whatever else is still running. ## Reading the expense model for waits Walking the analyst's diagram with the table above gives the instance's waits in order: - `Approve claim` (user task): waits for the line manager, possibly for days. - `Receive receipts` (receive task): waits for the expense-capture message correlated to this claim. - The five-day reminder (timer): waits for its duration, if it is modelled as a catching timer. - `Pay claim` (service task): active only while the payment call runs. - `Notify employee` (send task): sends and completes at once. When the last token reaches an end event and nothing is active, the claim's instance is complete. ## Why this matters to the developer receiving the model - Every **wait state** needs something that ends it: an assigned person for a user task, a correlated message for a receive task, a definition for a timer. - **Correlation** decides which instance a message reaches. For key-based correlation only one receive for a given correlation key can be active, so a message matches at most one instance. - An instance that never completes usually has a token parked at a wait whose trigger can never occur, such as a receive task for a message nobody sends.

  • In BPMN 2.0, how does a receive task know which running instance a message belongs to?
    Through correlation. With key-based correlation, only a single receive for a given correlation key can be active, so the message matches at most one process instance. With predicate-based correlation the message can be passed to multiple receive tasks.
  • In BPMN 2.0, what happens to other active paths when a token reaches a terminate end event?
    The entire process instance is abnormally terminated, so activities still running on parallel paths end too. A normal end event consumes only its own token, and the instance continues until no token and no active activity remain.
  • In BPMN 2.0, does an execution-conformant engine have to run manual tasks?
    No. The standard lists the manual task among non-operational elements that implementations conforming to Process Execution Conformance may ignore; it describes work never actually executed by an IT system.

A token is like a claim form moving through an office: it passes through desks that stamp it at once, but it sits in an in-tray while a manager is away or a receipt is still in the post. The claim is closed only when no copy of the form is left on any desk.

saying these in an interview costs you the question

  • Believing an instance completes when the first end event is reached
  • Treating a service task as a human wait state
  • Assuming a timer event waits without any timer definition
  • Thinking a manual task is executed and tracked by the engine
  • Believing a terminate end event ends only its own path