skip to content

In a BPMN 2.0 buyer-supplier collaboration, why can't a sequence flow join the buyer's send-order task to the supplier's receiving event?

level: middleimportance: must knowfreq 45%

answer

  1. whose process owns each token
  2. pool boundary is a wall for one line
  3. what the supplier catches
  4. lanes are not pools

basics

~20 s

In BPMN 2.0 a sequence flow never crosses a pool boundary: each pool holds a separate participant's process. The order is a message flow, consumed by the supplier's message start event, receive task or message catch event.

solid answer

~50 s

Each pool in a BPMN 2.0 collaboration represents a **participant**, and a white-box pool contains that participant's own process with its own tokens. Clause 7.6.1 says sequence flows cannot cross a pool boundary, and clause 9.4 says a **message flow** MUST connect two separate pools. So the buyer's `Send order` task is joined to the supplier by a message flow, and the supplier's process only moves when one of its own elements consumes the message: a message start event that instantiates the order handling, a receive task, or a message intermediate catch event. The reverse rule matters just as much: between two lanes of the **same** pool you use a sequence flow, because a message flow MUST NOT connect two objects in one pool. In the XML the difference is visible too: `sequenceFlow` lives inside a `process`, while `messageFlow` lives inside the `collaboration`.

code

xml · 25 lines
xml
<collaboration id="PurchaseOrderCollaboration">
  <participant id="Buyer" name="Buyer" processRef="BuyerProcess"/>
  <participant id="Supplier" name="Supplier" processRef="SupplierProcess"/>
  <messageFlow id="OrderMessageFlow" name="Purchase order"
               sourceRef="SendOrder" targetRef="OrderReceived"
               messageRef="PurchaseOrderMessage"/>
</collaboration>

<message id="PurchaseOrderMessage" name="Purchase order"/>

<process id="BuyerProcess">
  <startEvent id="NeedRaised"/>
  <sequenceFlow id="b1" sourceRef="NeedRaised" targetRef="SendOrder"/>
  <sendTask id="SendOrder" name="Send order" messageRef="PurchaseOrderMessage"/>
  <sequenceFlow id="b2" sourceRef="SendOrder" targetRef="BuyerDone"/>
  <endEvent id="BuyerDone"/>
</process>

<process id="SupplierProcess">
  <startEvent id="OrderReceived" name="Order received">
    <messageEventDefinition messageRef="PurchaseOrderMessage"/>
  </startEvent>
  <sequenceFlow id="s1" sourceRef="OrderReceived" targetRef="CheckStock"/>
  <task id="CheckStock" name="Check stock"/>
</process>

go deeper

for a junior

Remember the boundary rule: solid sequence flows stay inside one pool, dashed message flows cross between pools.

for a middle

Explain why: each pool runs its own process with its own tokens, so the receiver must catch the message with its own event or task.

for a senior

Diagnose a collaboration where the supplier never starts, tracing it to a message landing on an element that cannot catch it or a sequence flow crossing pools.

for a principal

Discuss message flows as the documented interface between organisations, and why each participant's process must still be complete and traceable on its own sequence flows.

## The scenario A buyer and a supplier exchange a purchase order. The model is a **collaboration**: one pool for the buyer, one for the supplier. Inside the buyer's pool a task `Send order` completes; inside the supplier's pool the order handling should begin. A tempting but illegal drawing puts a solid sequence flow from `Send order` straight to the supplier's first element. ## Why the sequence flow is illegal BPMN 2.0.2 states the rule in several places: - Clause 7.6.1: sequence flows cannot cross a **pool boundary**. - The glossary: a sequence flow can cross lanes of a pool but cannot cross the boundaries of a pool. - Clause 9.4: a message flow **MUST connect two separate pools** and **MUST NOT** connect two objects within the same pool. The reason is the token model. A sequence flow passes the token of one process instance to the next element of the **same** process. The buyer's process and the supplier's process are different processes run by different participants; there is no shared token that could move from one to the other. The specification says so directly: a token does not traverse a message flow, since it is a message that is passed down it. ## What the correct model looks like | Element in the model | Connector | Why | |---|---|---| | Buyer `Send order` to supplier's order-received event | **message flow** | crosses two pools; carries the order message | | Supplier `Confirm order` to buyer `Receive confirmation` | **message flow** | crosses two pools the other way | | Buyer `Approve order` (Purchasing lane) to `Send order` (Accounts lane) | **sequence flow** | two lanes of one pool; same process | | Supplier start event to `Check stock` | **sequence flow** | inside the supplier's process | On the receiving side, a message must land on something that can **catch** it: 1. A **message start event**. The specification says each message flow targeting a start event represents an instantiation mechanism for the process, so the order creates a new supplier process instance. 2. A **receive task** or a **message intermediate catch event** in the middle of an already-running supplier process. 3. The **pool boundary** itself, when the supplier is drawn as a black box and its internal process is not shown. ## Rules at the endpoints of a message flow - An **activity** may be the source or target of zero or more message flows. - A **start event** may be the target of message flows but MUST NOT be their source. - An **end event** MUST NOT be the target of a message flow; it may be the source, and then its result must be `Message` or `Multiple`. - A **message intermediate event** may have one incoming or one outgoing message flow, but not both. - **Gateways**, lanes, data objects, groups and text annotations cannot take message flows at all (they are absent from Table 7.4). ## The XML makes the separation explicit The interchange format puts the two connectors in different containers. A `sequenceFlow` is a flow element inside a `process` and refers to its ends by `IDREF`. A `messageFlow` is declared in the `collaboration`, refers to its ends by `QName`, and can name the message with `messageRef`. The example below shows the purchase-order message flow from the buyer's send task to the supplier's message start event. ## A note on direction and labels The open circle of a message flow marks the **sender** and the open arrowhead the **receiver**, so direction is read from the connector itself. A label such as "Purchase order" names the message; in the XML the `messageRef` points at the `message` element that defines it. Two message flows in opposite directions between the same pair of elements (order out, confirmation back) are two separate connectors, never one double-headed arrow. ## How interviewers probe this - They show a diagram where a solid arrow crosses from buyer to supplier and ask what is wrong. The answer names both the connector type and the missing catching element. - They ask what happens in the supplier's process after the buyer's task completes. The honest answer: nothing, until the supplier's own element receives the message; the buyer's token continues only along the buyer's sequence flows. - They reverse it: two lanes, one pool, a dashed arrow between them. That is also illegal, because a message flow never stays within one pool.

  • In BPMN 2.0, can a message flow end on the supplier's pool boundary instead of a task?
    Yes. Clause 9.4 allows a message flow to connect either to the pool boundary or to a flow object inside the pool. Ending on the boundary is how you model a participant whose internal process you do not show; you still may not end on a lane, a gateway or a data object.
  • In BPMN 2.0, what does a message flow into a start event mean for the receiving process?
    Each message flow that targets a start event represents an instantiation mechanism for that process, and only one of the triggers is required to start a new instance. The purchase order therefore creates a new supplier process instance rather than continuing an existing one.
  • In BPMN 2.0, how does the buyer model waiting for the supplier's confirmation?
    With its own catching element on its own sequence flow path, such as a receive task or a message intermediate catch event, targeted by a message flow from the supplier. The buyer's token waits there; it is not the supplier's token arriving.

saying these in an interview costs you the question

  • Drawing a solid sequence flow from one pool into another pool
  • Believing the buyer's token continues into the supplier's process
  • Using a message flow between two lanes of the same pool
  • Pointing a message flow at a gateway to route the incoming order
  • Letting a message flow end on an end event of the receiving pool