BPMN - Fundamentals
In BPMN, there is no direct diagrammatic notation for drawing a process on its own. Indeed, either the process' content is drawn “as is”, i.e., a BPMN process diagram or several processes' content are drawn with communications between each other, i.e., a BPMN collaboration diagram (a.k.a. BPMN orchestration diagram).
From ver 2.x of BPMN, a BPMN conversation diagram (example*) is an infrastructural (summarized) vision of a BPMN collaboration diagram while a BPMN choreography diagram (example*) puts forward interaction coordination as a whole.
In short, a BPMN conversation diagram shows the “network infrastructure” while a a BPMN choreography diagram shows how this network infrastructure is used in terms of “business interaction protocol”.
As described, these new BPMN diagram types only aim at bringing out more readability and thus comprehensibility without any introduction of essential (new) notation.
Notation allows markers as
sub-conversation 
,
multi-instance 
, etc.
Choregraphy: the way FSC and PSC exchange to each other.
A BPMN pool generally has a name. It is a support of a running process. For example, a case of Customer Relationship Management (CRM) may be modeled by means of a customer pool and a supplier pool. The interaction between the customer and the supplier BPMN processes makes up a BPMN collaboration diagram.
A BPMN lane generally has a name. It is a well-identified part of a running process (and graphically depicted “as is” within an inner rectangle).
Lanes can be further subdivided by lanes.
Contrary to a BPMN pool, a BPMN lane is a deliberately isolated functional part of a process that may
be viewed as a specific role or responsibility in terms of workflow.
A BPMN lane appears or disappears at design time according to business objectives: BPMN processes' shapes change for improvement and lanes play a great role in this changeability for management efficiency.
*An interesting analysis on modeling heuristics about BPMN pool versus BPMN lane is here…
The size of a BPMN model often requires a collapsed view (a.k.a. black-box view) of its interacting BPMN pools.
A BPMN activity is a functional unit whose name is preferably a verb (imperative mode) to make feel an action in the designed process. A BPMN activity is part of a BPMN pool or, a BPMN lane of a BPMN pool when lanes are used.
as a specialized BPMN activity, necessarily is intra-BPMN pool and intra-BPMN lane.
BPMN task inputs/outputs are BPMN sequence flows -▶ or, in a synchronization logic, BPMN control flows ○⚋▷; flows are elementary means for designing activity dependencies.
or white box
and a BPMN task are by definition disjunctive notions.
A BPMN embedded subprocess
is drawn in its wrapping process (or subprocess: no recursion limit).
(a.k.a. “reusable subprocess”)
does not inherit from that of BPMN embedded subprocess in the BPMN metamodel.
Most of the time, the look of a BPMN call activity is a thick contour.
However, sometimes, the + sign (black-box view) is also used to show its macroscopic nature.
Download jBPM .bpmn file
Download jBPM .bpmn file
Download jBPM .bpmn file
A BPMN sequence flow -▶ is a key notational construct for showing progress within a business process. Functional and behavioral elements of a business process dependent on each other; so, flows mark business dependencies. Besides, flows optionally carry data to irrigate business organizations.
*This two-lane model has implicit behavior: subprocess has no start event and no end. No start event (global process) leads to indeterminism at start time…
Download bpmn.io .bpmn file
,
Bizagi Modeler .bpm file
,
CATIA Magic .mdzip file
Work task,
merging for that the two extant Work (1st part) and Work (2nd part) tasks!
Tip: use a gateway…
Download Bizagi Modeler .bpm file
BPMN control flow ○⚋▷ and BPMN message flow ○⚋ ✉ ⚋▷ share the same semantics.
.
However, some tolerance exists.
and (send-receive) BPMN message task
.
Theoretically, an event is an external phenomenon with a null duration. The opposite notion is that of state (i.e., BPMN activity). Usually, “event” implies “caught event occurrence” although BPMN also supports the idea of “thrown event occurrence”.
Events like activities and gateways are known as “flow objects” in BPMN.
Event entries (except* BPMN start events 
)
and event exits (except* BPMN end events 
)
are BPMN sequence flows -▶.
*There are other minor exceptions
are possible, each associated with a BPMN lane for example).
can be, for instance, a BPMN start (caught) message event 
.
are possible, each associated with a BPMN lane for example).
(doc.+)
is a thrown* event: tasks and subprocesses inside an BPMN activity having a BPMN terminate event are forced to complete.
So, reaching a BPMN end event does not lead to process completeness when some execution paths are still active…
can be, for instance, a BPMN intermediate (caught) message event .
*Notation is sometimes a simple circle whose thickness is between “start” (thin) and “end” (thick)
Download bpmn.io .bpmn file
Tokens match to execution paths, which are often multiple! Processes terminate when all (inner) execution paths become inactive…
BPMN makes a distinction between event reception (the idea of BPMN caught event)
and event emission (the idea of BPMN thrown event), for instance, BPMN intermediate caught message event
and BPMN intermediate thrown message event .
For the sake of clarity, in a conceptual spirit, it is more opportunistic to view the notion BPMN thrown event as that of “activity” in general and not as that of “event” in a theoretical sense!
As a result, BPMN control flows ○⚋▷ and
BPMN message flows ○⚋ ✉ ⚋▷
aim at connecting BPMN thrown events to BPMN caught events across BPMN pools, typically,
○⚋▷*
(signals) or 
○⚋ ✉ ⚋▷ (messages).
*In principle, this notation between signals is not BPMN-compliant, but it may be tolerated to make communication flows more readable
BPMN start events ,
BPMN intermediate events ,
and BPMN end events
aim at being specialized*.
(doc.+)
⤳ interrupting
is necessarily a BPMN end event .
(doc.+)
in a subprocess; contrary to “error”, “escalation” rather means “business anomaly” in a functional sense.
.
*By default, throughout this tutorial, BPMN intermediate caught events are depicted when discussing event triggers (e.g., error, timer, etc.) in a general-purpose way
and BPMN end error event
(Kogito)
*Status can be interrupting only
Download Kogito .bpmn file
(Kogito)
Download Kogito .bpmn file
(Kogito)
Download Kogito .bpmn file
(Kogito)
Download Kogito .bpmn file
(doc.+)
⤳ interrupting
;
prior inner-activity effects are annihilated (i.e., “rollback”).
is only caught as a BPMN boundary event on the BPMN transaction subprocess.
(doc.+)
⤳ non-interrupting
marker)
in charge of a “user-defined rollback” is then linked, as output, to the caught compensation event.
*
*The relationship between a BPMN compensation event
and its compensation activity is not fully part of the process' execution flow:
a BPMN association ⇢ (instead of a BPMN sequence flow -▶)
is used to connect the BPMN compensation event
with the compensating activity.
In contrast, an BPMN compensation end thrown event 
is part of the process' execution flow
to trigger the compensation
Download bpmn.io .bpmn file
(doc.+)
*In BPMN, the concept of BPMN thrown timer event is meaningless
**ISO 8601 standard is used in BPMN platforms to formally express durations and dates
Download bpmn.io .bpmn file
Download bpmn.io .bpmn file
Download bpmn.io .bpmn file
Download bpmn.io .bpmn file
,
CATIA Magic .mdzip file
(doc.+)*
Other specializations** of BPMN start events ,
BPMN intermediate events ,
and BPMN end events .
is tricky, say,
a BPMN start conditional event 
requires appropriate user-defined observation.
*This doc. example is ambiguous: the exit flow from Check Application is not explicitly the boolean opposite of Application changed?
**By default, throughout this tutorial, BPMN intermediate caught events are depicted when discussing event triggers (e.g., error, timer, etc.) in a general-purpose way
Download bpmn.io .bpmn file
(doc.+)
,
BPMN message events have identified recipients.
occurs in one BPMN pool
while message reception
occurs in another one.
As a result, a BPMN message flow
○⚋▷
or ○⚋ ✉ ⚋▷
makes inter-pool collaboration explicit.
(doc.+)
use the broadcast mode of communication, i.e., any subscriber reacts to signal occurrence.
indifferently occurs in the same BPMN pool or in another one.
The impossibility of having
○⚋▷*
requires signal name matching in order to associate receptions with emissions.
*This notation between signals is not BPMN-compliant. Nevertheless, it may be tolerated to make communication flows more readable
Download bpmn.io .bpmn file
⤳
step 1
⤳
step 2
⤳
step 3
Download bpmn.io .bpmn file
⤳
step 1
⤳
step 2
⤳
step 3
⤳
step 4
⤳
step 5
Download bpmn.io .bpmn file
Download CATIA Magic .mdzip file
Second-class specializations* of BPMN start events ,
BPMN intermediate events ,
and BPMN end events
exist.
(doc.+)
to its associated BPMN caught link event .
(doc.+)
is a variation to support the AND semantics.
*By default, throughout this tutorial, BPMN intermediate caught events are depicted when discussing event triggers (e.g., error, timer, etc.) in a general-purpose way
Download bpmn.io .bpmn file
BPMN multiple event 
(XOR) is poorly supported in editors & platforms. It aims at replacing all 3 events on the left hand side model*.
*Exclusion when entering Have lunch is only intuitive
BPMN parallel multiple event 
(AND) aims at replacing all 3 events on the left hand side model.
A BPMN caught event* can be interrupting (default) or not. A dashed-line circle (double circle for BPMN intermediate caught event) means “non-interrupting”. Interruptibility** is systematically linked to the notion of BPMN boundary event (illustration).
*Interruptibility only makes sense for “received” events
**Note that some types can never be “non-interrupting”,
e.g., BPMN intermediate caught error event
A chemistry process requires enhanced capabilities in order to be better controlled. Namely,
the suite of the three first tasks must not last more than 1 min. If so, the process stops… Moreover,
an external decision may stop the waiting task to restart the process at the first Heat task… Finally,
the last Heat task may fail in a “unexpected way”…
Download Bizagi Modeler .bpm file
,
CATIA Magic .mdzip file
Download CATIA Magic .mdzip file
Download bpmn.io .bpmn file
A BPMN exclusive gateway establishes the path taken by a BPMN flow. Outgoing flows have conditions (a possible default flow as well) to compute execution paths in business processes. A synthesis about the possible BPMN gateway types in BPMN is here… or there…
(“full white”)
-▶.
(XOR semantics)
.
A BPMN gateway with possible/systematic parallelism establishes the path(s) triggered by BPMN flows. Inclusive gateways have conditions (a possible default flow as well) while parallel gateways have not.
(OR semantics)
FORK (flow divergence) often requires an associated JOIN (i.e., another BPMN inclusive gateway ) later on in the business process.
(AND semantics)
by substituting “systematic” to “optional”.
FORK (flow divergence) often requires an associated JOIN (i.e., another BPMN parallel gateway ) later on in the business process.
Download bpmn.io .bpmn file
Download bpmn.io .bpmn file
*A BPMN task has at most one incoming flow (error on D entry) and
a BPMN task has at most one outgoing flow (error on A exit).
(explicit versus implicit FORK*)
**
*While these two model pieces are known as equivalent, model on the top has to be preferred because of its explicit nature.
**Conditions as properties of the outgoing flows of a BPMN parallel gateway
are not allowed (OCEB 2 Certification Guide, Second ed., p. 120).
JOIN versus JOIN based on BPMN exclusive gateway *
*The model piece on the left hand side is both shaky and unclear in the sense that the Prepare & serve Bolognese sauce
might be executed twice: “If several sequence flows end in an activity, each incoming token triggers the activity.” (OCEB 2 Certification Guide, Second ed., p. 98).
The model piece on the right hand side is non-equivalent!
A BPMN complex gateway
has to be used when conditions cannot be expressed in “common logic”.
Tricky business rules correspond to such a situation.
may be advantageously replaced by
a BPMN business rule task 
.
*In the BPMN official doc., complex gateways are declared close to inclusive gateways.
⤳ example
Download bpmn.io .bpmn file
⤳ alternative
Download bpmn.io .bpmn file
The BPMN event-based gateway type
(start or intermediate) relies on events instead of conditions.
(XOR semantics)
but exclusion operates on concurrent event occurrences* instead of concurrent conditional data values.
“points to” a caught event among condition ,
signal ,
message ** or,
timer .
Any first occurrence of any “pointed” event triggers the flow and moves the business process forward.
(AND semantics, start only)
, but all event occurrences are expected instead of any of them.
*See The Pizza Collaboration case study (PDF, p. 4).
**A BPMN receive task is permitted as well.
⤳ example
⤳ example
*Please note that the Have speed dating task is executed once.
Download Bizagi Modeler .bpm file
*BPMN parallel event-based gateway: start only!
Download BPMN .bpmn file
Download bpmn.io .bpmn file
& BPMN
group 
A BPMN annotation is a BPMN model element without interpretation scope in terms of execution. By definition, an annotation is expressed in natural language*
and is bound to one or more execution-meaningful BPMN model elements.
A BPMN group allows
the isolation (by surrounding**) of a given set of BPMN model elements for easier readability, even comprehensibility.
Similar to a BPMN annotation , a BPMN group has no interpretation scope in terms of execution.
*Commenting on BPMN models
is obviously useful. Nonetheless, the presence of numerous BPMN annotations
may show, even prove, the designer's incapacity of precisely and completely modeling
all issues of a business process… So, be careful about any excessive use!
**Note that a group may cross over pool boundaries.
⤳ types“Abstract” BPMN tasks
are the basic notation for tasks, but specializations are possible*.
(doc.+)
embodies human (opposed to Information Technology - IT) intervention.
is not executable at all.
(doc.+)
may be executable when it corresponds, for instance, to a user interface (e.g., a Web form).
*An interesting analysis of the types and usages of
BPMN tasks
is here…
⤳ types cont'dThree types of BPMN task
embody Information Technology (IT) concerns (e.g., programming).
(doc.+)
requires a business rules engine for execution (e.g., Drools in Kogito)
or relies on the Decision Model and Notation -DMN- standard.
(doc.+)
encapsulates code (e.g.,
<script>…</script>in Activiti) that runs
in the BPMN process engine's thread of control.
(doc.+)
requires technology like Java API for RESTful Web Services (JAX-RS).
cont'd
⤳
BPMN message task
The idea of BPMN message task
creates confusion with that of BPMN message event
.
Despite some redundancy*,
a BPMN boundary event may be attached to BPMN message task
to catch any event (typically an error) that may occur within the task of message emission or message reception.
Moreover, these BPMN markers 
may be used to model multiple
message emissions or message receptions.
(doc.+)
.
(doc.+)
.
*An interesting analysis about the distinction between the ideas of BPMN message event
and BPMN message task
is here…
⤳ restriction*
While receive tasks
may have boundary events, they *CANNOT* in the case they act as outgoing elements of event-based gateways.
*BPMN official doc., p. 297
A BPMN embedded subprocess (example*)
is fully part of the execution scope of its wrapping process in the sense that they share data. This is the key difference with a
BPMN call activity (data must be explicitly transferred at calling time).
cannot terminate its wrapping process through a BPMN terminate event
(OCEB 2 Certification Guide, Second ed., p. 132).
cannot have inner pools and lanes; (possible) start events cannot have triggers as well
(OCEB 2 Certification Guide, Second ed., p. 110).
*Morning embedded subprocess here…
⤳ implicit parallelism*
*This is scenario 1. (scenario 3. is equivalent while scenario 2. is not: D is executed twice).
A BPMN event subprocess
is a self-contained subprocess that starts from an -interrupting or not- (BPMN official doc., p. 440) event
that may be thrown within its enclosing activity.
A BPMN event subprocess completes in an autonomous way and has access to the execution context of its enclosing activity.
interrupts its enclosing activity when its BPMN start event is made “interruptible” (default).
However, one may need the possibility of specifying that the BPMN event subprocess
starts without interruption of its enclosing activity. For example, for a timer, a BPMN start non-interrupting timer event
has to be used.
⤳ non-interruption
Download bpmn.io .bpmn file
⤳ interruption versus non-interruption
Download bpmn.io .bpmn file
BPMN activities may have BPMN markers to become more specific.
(doc.+)
(doc.+)
*Further detail and modeling heuristics are exposed here…
A BPMN activity (BPMN task ,
BPMN call activity ,
BPMN embedded subprocess , or
BPMN transaction subprocess )
may be equipped with a BPMN marker
to make it a BPMN multi-instance activity.
BPMN markers are (in an exclusive way): ;
activity' executions are stopped by textual conditions (no graphical counterpart).
(doc.+)*
(doc.+)
⤳ disjunctive from loop and sequential multiple
n times and the n executions occur in parallel.
(doc.+)
⤳ disjunctive from loop and parallel multiple
n times and the n executions occur in sequence.
*Contrary to parallel multiple and sequential multiple , loop
aims at processing the same data collection instance.
Download Kogito .bpmn file
Download bpmn.io .bpmn file
A BPMN transaction subprocess
(doc.+)
aims at grouping several activities as a whole: they all succeed or fail with respect to the subprocess execution scope.
relies on a transactional engine (e.g., Java Transaction Service - JTS).
⤳ example
Download bpmn.io .bpmn file
A BPMN default sequence flow
may be used for marking the exit of a BPMN activity or a BPMN gateway.
(OR semantics) or a
BPMN exclusive gateway (XOR semantics),
a default flow is used only if all the other outgoing
conditional* flow paths are not evaluated true.
may leave a BPMN activity as well.
In this case, at least one additional flow exiting this activity is set to a BPMN conditional sequence flow
.
*From a forking
BPMN inclusive gateway or
BPMN exclusive gateway , a
BPMN sequence flow -▶ should necessarily be endowed with a conditional expression that has no graphical counterpart.
A BPMN conditional sequence flow
may act as a substitute for a BPMN inclusive gateway or
a BPMN exclusive gateway .
According to the BPMN official doc. (p. 32),
a conditional flow
should only be used when leaving a BPMN activity* (OCEB 2 Certification Guide, Second ed., p. 106).
This means that, in a unexpected sense, this activity's exit is constrained by a conditional expression that is symbolized by the white diamond.
*Note that several BPMN conditional sequence flows
being true when leaving
a BPMN activity create as many as execution tokens: some parallelism in other words!
Contrary to a a BPMN exclusive gateway ,
mutual exclusion is not compulsory.
&
BPMN conditional sequence flow
In the Shipment Process of a Hardware Retailer case study (PDF, p. 3), the flow labeled Always
implicitly has true as underlying condition. To that extent, the flow labeled extra insurance required towards Take out extra insurance is optional.
Would it be correct (as done below) to change this flow to a BPMN default sequence flow ?
FORK and JOINBy construction, a BPMN gateway can fork either an incoming flow into multiple outgoing flows or join multiple incoming flows into an outgoing flow. Best practices associated with such an approach are exposed in a document accessible from here…
It is important to notice that a JOIN gateway may be used to merge flows,
which have not necessarily been split by a similar FORK gateway
(sample here…).
FORK and JOIN make little sense
for a BPMN event-based gateway
.
⤳ best practice
JOIN? Why not…
FORK and JOIN ⤳ non-conformance
&
BPMN exclusive gateway
⤳ best practice
⤳ JOIN without FORK
Download bpmn.io .bpmn file
FORK and JOIN ⤳ execution consistency issues*
*Execution imposes well-formed models (a.k.a. “workflow patterns”).
Note that the following model does not actually foster well-formedness (the expected “closing” gateway should be
exclusive
instead of
inclusive
).
FORK and JOIN ⤳ probable execution inconsistency
FORK and JOIN ⤳ dead lock*
*Design error risks (example here…)
come from “larger” models: a JOIN imposed by a FORK
is located at a distant place.
JOIN for BPMN exclusive event-based gateway
⤳ best practice
Fundamentally, a BPMN association ⇢ links a
BPMN data object 
to a BPMN activity, BPMN event or BPMN gateway
(OCEB 2 Certification Guide, Second ed., p. 142).
A BPMN association ⇢ may also connect a
BPMN data object with a
BPMN sequence flow -▶.
In this case, the BPMN association ⇢ loses its direction (i.e., no ending arrow: ⁞).
BPMN
supports data and data flow descriptions is a limited way.
The notion of BPMN association ⇢
allows the connection of data as inputs and/or outputs* of
a BPMN activity, BPMN event or BPMN gateway.
A key issue is the fact that a BPMN activity having an inbound BPMN data object
cannot be executed until data are available.
Further detail on the use of BPMN data object and
BPMN association ⇢ may be found here…
(data remain outside processes' execution scope)
*Optionally, states of data objects may be noted between square brackets, e.g., [Confirmed], to establish data objects' status before (as inputs) or after (as outputs)
execution.
(input and output)
versus
BPMN input data object
versus output data object
⤳ state
A decision includes a decision table whose expressions are based on Friendly Enough Expression Language -FEEL-.
The concept of DMN Business Knowledge Model is controversial
(see also here…)
in the sense that a DMN Business Knowledge Model (e.g., Determine programming language)
is nothing else than a small-size decision.
A DMN Business Source (e.g., Android dev. security best practices)
has no impact on the inference of a decision. It just states a context in which inference occurs.
{"?" : "Franck René Pierre Barbier"}
count(split(?,"\\s"))
4
{"?" : "Franck René Pierre Barbier"}
contains(?,"Franck")
true
*Using FEEL online here…
Unique: XOR semantics ⤏ rule overlapping raises problem
First (from top to bottom): XOR semantics ⤏ rule overlapping does not raise problem
Priority: XOR semantics ⤏ rule overlapping does not raise problem provided that priorities have distinct values
Any: XOR semantics ⤏ rule overlapping does not raise problem provided that inferred rules must lead to the same result