skip to content

In an executable BPMN 2.0 expense process, when do you hold claim data in a data object, a property or a data store?

level: middleimportance: should knowfreq 30%

answer

  1. how long the data lives
  2. drawn or hidden
  3. beyond one instance
  4. the standard compares them to variables

basics

~20 s

In BPMN 2.0 a data object is visible data living as long as its process or sub-process instance; a property is hidden data on a process, activity or event, living as long as that element; a data store persists beyond the process.

solid answer

~50 s

All three are **item-aware elements**, which the standard compares to variables: each can carry an `ItemDefinition` describing its structure. A **data object** must be contained in a process or sub-process, is drawn on the diagram, is instantiated and disposed with that process or sub-process instance, and is accessible only within it and its children; the expense `Claim` document fits here. A **property** is not displayed; only processes, activities and events may contain one, and it lives and dies with its parent element, which suits internal working values such as an approval counter. A **data store** holds information that **persists beyond the scope of the process**, such as the finance ledger or the employee register; the process reaches it through data store references used as sources or targets of data associations. BPMN has no element literally named a process variable; these three cover that role.

go deeper

for a junior

Recall that data objects are drawn and live with their instance, properties are hidden, and data stores outlast the process.

for a middle

Explain lifetime and scope for each, including data object references and states, and pick one for each piece of claim data.

for a senior

Spot data that must outlive an instance but is modelled as a data object, and move it to a data store with associations.

for a principal

Set conventions for which working data is visible to business readers and which stays in hidden properties.

## Item-aware elements: BPMN's variables BPMN 2.0.2 models data through **item-aware elements**: data objects, data object references, data stores, properties, data inputs and data outputs. The standard says these are similar to the variable construct common to many languages. Each may reference an **ItemDefinition** through `itemSubjectRef`; the structure may be left underspecified if the modeller does not wish to define it. The standard itself has no element called a "process variable". When a developer asks where the process variables live, the answer is one of the elements below, chosen by visibility and lifetime. ## The three choices | Element | Drawn on the diagram | Contained by | Lifetime | Typical expense-process use | |---|---|---|---|---| | **Data object** | yes | a process or sub-process | instantiated and disposed with that process or sub-process instance | the `Claim` being reviewed | | **Property** | no | a process, activity or event | instantiated and disposed with its parent flow element | an approval-round counter on the process | | **Data store** | yes, through a data store reference | global, referenced by `dataStoreRef` | persists beyond the scope of the process | the finance ledger, the employee register | ## Data objects - A data object **MUST be contained** within a process or sub-process and **is displayed** on the diagram. - Its lifecycle is tied to its parent: when the process or sub-process instance is disposed, the data object instances in it are disposed and the data is no longer available. - It is accessible only while a live instance is guaranteed: by its parent process or sub-process and the elements inside it. - **Data object references** let the same data object appear several times, for example `Claim [submitted]` and `Claim [approved]`. A reference can specify a **state** but not an item definition; the data object specifies the item definition but not a state. - `isCollection` marks a data object holding a collection, such as the list of receipts. ## Properties - Properties are item-aware elements that are **not visually displayed**. - Only **processes, activities and events** may contain properties. - A property's lifecycle and accessibility follow its parent flow element. A process-level property is accessible to the process's immediate children and their contents. Use properties for working state the business reader does not need to see. ## Data stores - A data store provides a way for activities to **retrieve or update information that persists beyond the scope of the process**. - The same data store can be shown through **data store references** in several places. - A data store reference is item-aware, so it can be the source or target of a **data association**; data flowing into or out of the reference flows into or out of the store. For the expense process, reading the employee's cost centre and writing the paid claim to the ledger are data associations to data store references. The claim itself stays a data object, because it belongs to one instance. ## How the choice shows up at run time 1. When an activity starts, its data inputs are filled from data objects or properties through **data input associations**; at the end, **data output associations** copy outputs back. 2. Expressions reach the data with the standard's **XPath extension functions**, such as `getDataObject('Claim')`, `getProcessProperty(...)` and `getActivityProperty(...)`, when XPath is the expression language. 3. Anything that must be seen by the next claim or by another system belongs in a data store, not a data object. ## Choosing quickly Ask two questions of each piece of data. **Must it outlive this claim's instance?** Then it is a data store. **Must the business reader see it on the diagram?** Then it is a data object; otherwise a property on the process or activity that owns it. For the expense process this gives the claim as a data object, a hidden reminder counter as a property, and the ledger and employee register as data stores. ## Common mistakes - Using a data object to remember something across instances. It is disposed with the instance. - Drawing every internal counter as a data object, which clutters the analyst's diagram; a property is the hidden alternative. - Treating a data store as a queue between two processes; it is persistent information, and inter-process communication is a message.

  • In BPMN 2.0, can a data object reference carry its own item definition?
    No. A data object reference cannot specify an item definition, and a data object cannot specify states. The reference names a state, such as approved, while the data object it points at carries the structure.
  • In BPMN 2.0, who can read a data object defined in a sub-process?
    The sub-process and the elements inside it, while a live instance exists. The data object is disposed when the sub-process instance is disposed, so the parent process cannot read it afterwards unless it is copied out through a data association.
  • In BPMN 2.0, how does an XPath expression read a data object defined in a parent process?
    With the getDataObject extension function and its processName argument. The argument is optional; when omitted the process enclosing the activity is assumed, and it must be used to reach data objects of a parent process.

saying these in an interview costs you the question

  • Believing a data object survives after its process instance ends
  • Thinking properties are drawn on the process diagram
  • Using a data store to pass data within one process instance only
  • Assuming BPMN defines an element called process variable
  • Believing any flow element, including gateways, may hold properties