skip to content

An analyst hands developers a BPMN 2.0 expense-reimbursement diagram to automate; what does it lack that an executable model needs?

level: middleimportance: must knowfreq 40%

answer

  1. one attribute on the process
  2. natural language versus formal expressions
  3. who does it, what does it call
  4. typed data in and out

basics

~20 s

A BPMN 2.0 diagram usually lacks what execution needs: isExecutable set to true, formal condition expressions instead of prose, implementation details on service and user tasks, typed data with inputs, outputs and data associations, and full definitions for messages and timers.

solid answer

~40 s

The analyst's model is a **non-executable** private process: it documents behaviour at a modeller-chosen level of detail, and the standard notes such models typically omit formal condition expressions. To execute it, developers add: `isExecutable="true"` on the process; **formal expressions** (`formalExpression` in a declared language) wherever the diagram has natural-language conditions like "Claim over limit?"; for **service tasks**, the `implementation` technology (default `##WebService`) and `operationRef`; for **user tasks**, resource assignment such as a `potentialOwner`; **ItemDefinitions**, data inputs and outputs and **data associations** so each task receives and returns typed data; **messages** on message events (their `messageRef` MUST be supplied when the process is executable); and a single `timeDuration`, `timeDate` or `timeCycle` on each timer. Repeated activities need `loopCharacteristics`. None of this changes the picture much; almost all of it is invisible in the diagram.

code

xml · 18 lines
xml
<process id="ExpenseReimbursement" isExecutable="true">
  <dataObject id="Claim" name="Claim" itemSubjectRef="tns:ClaimItem"/>

  <userTask id="ApproveClaim" name="Approve claim">
    <potentialOwner>
      <resourceRef>tns:lineManager</resourceRef>
    </potentialOwner>
  </userTask>

  <sequenceFlow id="OverLimit" sourceRef="ClaimChecked" targetRef="ApproveClaim">
    <conditionExpression xsi:type="tFormalExpression">
      getDataObject('Claim')/amount &gt; 500
    </conditionExpression>
  </sequenceFlow>

  <serviceTask id="PayClaim" name="Pay claim"
               implementation="##WebService" operationRef="tns:payClaimOperation"/>
</process>

go deeper

for a junior

Recall that a diagram is usually non-executable documentation and that isExecutable marks a process meant to run.

for a middle

List the concrete additions: formal expressions, task implementations and assignments, typed data and associations, message and timer definitions.

for a senior

Run the hand-over systematically, typing every task and checking each executable-only MUST before switching isExecutable on.

for a principal

Decide how analysts and developers share one model, and where engine-specific extensions are allowed to live.

## Two kinds of private process BPMN 2.0.2 distinguishes **executable** and **non-executable** private processes through the process attribute `isExecutable`: - A **non-executable** process documents process behaviour at a modeller-defined level of detail. The standard says information needed for execution, such as **formal condition expressions**, is typically not included. - An **executable** process is modelled for the purpose of being executed according to the standard's execution semantics. - `isExecutable` is optional in the schema and has no default; for a **public** process it may not be true. The expense diagram the analyst hands over is almost always the first kind. It is correct as documentation and incomplete as a program. ## What the developers must add | Gap in the diagram | What the executable model needs | Source rule in BPMN 2.0.2 | |---|---|---| | Process not marked executable | `isExecutable="true"` on the `process` | Process attributes table | | Conditions written as questions, such as "Claim over limit?" | a `formalExpression` in a declared expression language | natural-language expressions are not executable and are considered underspecified | | Service task "Pay claim" with no binding | `implementation` (default `##WebService`, or a URI) and `operationRef` | Service Task attributes | | User task "Approve claim" with no assignee | a resource role such as `potentialOwner`, often with parameter bindings | Human performers and potential owners | | Task boxes with no data | `ItemDefinition`s, `ioSpecification` with data inputs and outputs, data associations | Data modelling clause | | Message events with only a label | `messageRef` (MUST be supplied when executable) and `operationRef` | Message event definition | | Timer labelled "5 days" | exactly one of `timeDate`, `timeDuration`, `timeCycle`, in ISO 8601 formats | Timer event definition | | "Repeat until complete" note | `loopCharacteristics` defining the repetition criteria | Activity attributes | | Conditional event labelled in prose | a `FormalExpression` condition | Conditional event definition | ## Things that stop mattering Some diagram content has no execution meaning. The execution semantics chapter lists **non-operational** elements that an execution-conformant implementation may ignore, including: 1. **Manual tasks** and **abstract tasks** (plain tasks with no type). 2. **Data states** and **IORules**. 3. **Ad-hoc processes**. 4. The `isClosed` attribute of a process and the `isImmediate` attribute of sequence flows. A plain task labelled "Check receipts" therefore has to become a user, service, script or business-rule task before an engine can do anything with it. ## Also expect engine-specific additions The standard's attributes are sometimes not enough to bind a real system, for example a queue name or a form reference. BPMN handles this with its **extension mechanism**: extension elements and attributes defined in an external schema, with a `mustUnderstand` flag (default false) that says whether a consuming tool must understand the extension to process the model correctly. Those additions are valid BPMN, but another tool may ignore them, which is the usual reason an executable model loses behaviour when moved between tools. ## What the analyst's work keeps Not everything in the diagram has to change. Names and labels remain as names. **Lanes** are not mentioned in the execution semantics chapter at all, so they can stay as documentation of responsibility for the business reader. **Text annotations** only attach information through associations and can stay too. What changes is the detail behind the shapes: types, data, expressions and bindings. Keeping one model for both audiences is possible precisely because most executable detail is invisible in the drawing. ## A working order for the hand-over 1. Replace every untyped task with the task type the work really is. 2. Define the data: item definitions, the claim as a data object, inputs and outputs per task. 3. Formalise every condition and timer. 4. Bind service tasks and assign user tasks. 5. Set `isExecutable="true"` last, once nothing is underspecified. The example below shows the "Approve claim" step and the over-limit condition after this work, in the style of the standard's own examples.

  • In BPMN 2.0, can a public process be marked executable?
    No. For public processes, no value of isExecutable means the same as false, and the value may not be true. A public process shows only the touch-points with other participants, so it has nothing to execute.
  • In BPMN 2.0, what does the Common Executable conformance sub-class fix about an executable model?
    It is aimed at modelling tools that can emit executable models and fixes the supporting languages: data types in XML Schema, service interfaces in WSDL, data access in XPath. It also lists the elements and attributes such a tool must support.
  • In BPMN 2.0, why is a plain task with no type a problem for execution?
    An abstract task is one of the non-operational elements an execution-conformant engine may ignore. Without a type and its attributes, there is no defined behaviour, so the step must become a user, service, script, send, receive or business-rule task.

saying these in an interview costs you the question

  • Believing a clean diagram is already an executable model
  • Leaving gateway conditions as natural-language questions in an executable process
  • Setting several timer attributes on one timer definition
  • Assuming isExecutable defaults to true for every process
  • Thinking vendor extension attributes are portable between tools