In BPMN 2.0, how do you show a purchase-order document produced by one task and read by the next, and why not with sequence flow?
answer
- data is not a flow node
- inputs and outputs have their own connector
- no token on the dotted arrow
- a shortcut on the sequence flow
basics
~20 sIn BPMN 2.0 the order is a data object wired by data associations: output from the creating task, input to the checking task. Sequence flow cannot touch data objects, and no token flows along data associations.
solid answer
~50 sA **data object** is not a flow node, so BPMN 2.0.2 never lets it be the source or target of a sequence flow (Table 7.3 leaves data objects out). Data movement uses **data associations**: a `dataOutputAssociation` copies an output of `Create order` into the `Purchase order` data object, and a `dataInputAssociation` copies the data object into an input of `Check order`. They are drawn with the directed-association look (dotted, with an arrowhead), and the specification says **tokens do not flow along a data association**, so they add no ordering; the sequence flow between the two tasks still decides order. As a visual shortcut you may attach the data object to that sequence flow with an association; the standard defines it as normalising the same two data associations. A plain undirected **association** is different again: it only links artifacts such as a text annotation.
code
xml · 15 lines<dataObject id="PurchaseOrderData" name="Purchase order"/>
<task id="CheckOrder" name="Check order">
<ioSpecification>
<dataInput id="CheckOrderInput" name="order"/>
<inputSet>
<dataInputRefs>CheckOrderInput</dataInputRefs>
</inputSet>
<outputSet/>
</ioSpecification>
<dataInputAssociation id="ReadOrder">
<sourceRef>PurchaseOrderData</sourceRef>
<targetRef>CheckOrderInput</targetRef>
</dataInputAssociation>
</task>go deeper
Recall that data objects hang off tasks with dotted data associations, and that solid sequence flows never touch them.
Explain data input and output associations, where they are contained, and why they carry data but no token.
Spot models where data arrows are read as ordering, and where a task can still wait because a data source is unavailable.
Discuss how strictly to model data in collaborative diagrams, trading readability of shortcuts against an unambiguous serialized model.
## The modelling problem In the buyer's process, `Create order` produces a purchase order and `Check order` reads it before it is sent. The document is modelled as a **data object**. The question is which connector ties it to the two tasks, and whether that connector says anything about order. ## Why sequence flow is the wrong connector A **sequence flow** connects **flow nodes** only: events, activities and gateways. BPMN 2.0.2 lists the objects that may have incoming or outgoing sequence flows and states that pool, lane, **data object**, group and text annotation are not among them. A data object cannot hold a token and cannot be "performed", so an arrow from `Create order` into the data object and on to `Check order` would claim the data object is a step in the process. It is not. ## Data associations: the right connector BPMN 2.0.2 introduces the **data association** for inputs and outputs: - A **data output association** belongs to the producing activity and copies one of its data outputs to a target such as a data object or a property. - A **data input association** belongs to the consuming activity and fills one of its data inputs from a data object or property. - Each data association has exactly one target and an optional **transformation** expression or **assignments**. With no transformation, exactly one source must be defined and its content is copied; with a transformation, zero to many sources may be listed. - Data associations are always **contained** by an activity or an event. Activities define two sets (input and output); events define one. A catch event uses it to push the received message's data into data objects; a throw event uses it to fill the message it sends. The specification is explicit that **tokens do not flow along a data association**, and as a result it has no direct effect on the flow of the process. Order still comes from the sequence flow between `Create order` and `Check order`. ## Notation: three dotted lines that mean different things | Connector | Look | Typical use | Carries | |---|---|---|---| | **Association** (undirected) | dotted, no arrowhead | text annotation to a task | information only | | **Directed association** | dotted, one or two arrowheads | a direction hint between artifacts | information only | | **Data association** | dotted with arrowhead, same look as a directed association | data object to or from an activity or event | data, no token | In BPMN 1.2, directional associations did the data job. BPMN 2.0 kept the look but made the data association a separate element with execution meaning. ## The sequence-flow shortcut The standard allows a data object to be **associated with a sequence flow** instead of being wired to both tasks. Clause 10.4.1 calls this a visual shortcut that normalises two data associations: one from an item-aware element contained by the source of the sequence flow to the data object, and one from the data object to an item-aware element contained by the target. Readers should expand it in their heads into those two data associations. It does not make the data object part of the sequence flow's token path. ## Common reading errors 1. Treating the dotted arrow from the data object into `Check order` as what triggers `Check order`. It is not; the incoming sequence flow is. 2. Drawing a message flow from a data object to the supplier to "send" the order. Data objects are not in the message flow rules; a send task or a message throw event sends, and its data association fills the message. 3. Using a plain association to show data input, the BPMN 1.2 habit, without the data association underneath in the serialized model. ## What a reviewer checks - Every task that reads the purchase order has a data **input** association from the data object, and every task that changes it has a data **output** association to it. - No solid line touches the data object. - Order between the two tasks is still expressed by their own sequence flow; removing the data associations must not change what runs next. ## In the interchange format In XML, data associations are child elements of the activity: `dataInputAssociation` and `dataOutputAssociation`, each with `sourceRef` elements and one `targetRef`. The example shows `Check order` declaring an input and filling it from the purchase-order data object.
- In BPMN 2.0, can a data association start or delay a task the way a sequence flow does?Not by itself. Tokens do not flow along a data association. However, if a source of a data association is unavailable, the specification says the association cannot execute and the containing activity or event must wait, so missing data can hold a task that its sequence flow has already enabled.
- In BPMN 2.0, how does a message start event get the incoming order into a data object?Through the event's own data association. For a catch event, data associations push data from the received message into data objects and properties; the message flow delivers the message, the data association stores it.
- In BPMN 2.0, what does a data object drawn on a sequence flow mean?It is a visual shortcut that normalises two data associations: an output of the flow's source into the data object, and the data object into an input of the flow's target. It adds no ordering beyond the sequence flow itself.
saying these in an interview costs you the question
- Drawing a sequence flow into or out of a data object
- Believing the data association arrow is what starts the consuming task
- Showing BPMN 2.0 data input with a plain annotation-style association only
- Sending the order with a message flow from the data object
- Assuming a data object on a sequence flow becomes a step in the process