BPMN

Introduction

The Business Process Modeling Notation (BPMN) is a standardized graphical notation for drawing business processes in a workflow. BPMN was developed by Business Process Management Initiative (BPMI), and is now being maintained by the Object Management Group since the two organizations merged in 2005. The intent was to identify the best practices of existing approaches and to combine them into a new, generally accepted language.

Since 2.0 there are 4 diagram types:

• Business Process Diagram (no or only one pool)
• Collaboration Diagram (pools and message flows)
• Choreography Diagram (contains choreography activities)
• Conversation Diagram (message between participants)

A goal for the development of BPMN is that the notation be simple and adoptable by business analysts. Also, there is a potentially conflicting requirement that BPMN provide the power to depict complex business processes and map to BPM execution languages. To help understand how BPMN can manage both requirements, the list of BPMN graphic elements is presented in two groups. First, there is the list of core elements that will support the requirement of a simple notation. Second, there is the entire list of elements, including the core elements, which will help support requirement of a powerful notation to handle more advanced modeling situations.

If a process description is detailed enough (including the execution semantics) it is a executable process. A public process contains only the activities and events which are relevant regarding the messages between partners. It is therefore not executable. The private process contains all the neccessary details.

Versions

The differences betwenn the version 1.0 to 2.0 are described here

• 1.0 2006
  • Die BPMN wurde 2002 durch Stephen A. White, Mitarbeiter von IBM, erarbeitet und durch die Business Process Management Initiative (BPMI) veröffentlicht.
• 1.1 Overview BPMN 1.1 changes
  • signal event
  • multiple instance marker not a pause symbol anymore
  • optical difference between throwing and catching events
  • event bases gateway and complex gateway => no star, but pentagon
• 2.0 Overview BPMN 2.0 changes
  • activity categories
  • non-interrupting boundary events
  • artifact shapes
  • default pool and default lane, even if not visible
  • data associations
  • data store
  • escalation end event
  • event sub-process
  • choerographies
  • collaborations
  • conversations

Missing Functionalities

The modeling of the following will not be a part of BPMN:

• Organizational structures and resources
• Functional breakdowns
• Data and information models
• Strategy
• Business Rules

Notation

Colours have no meaning, but can be used.

Diagrams

• Business Process Diagram (no or only one pool)
• Collaboration Diagram (usually two or more Pools and the Message Flow)
• Choreography Diagram (contains choreography activities)
• Conversation Diagram

Choreography

A choreography focuses on the exchange of information (Messages) between these Participants. BPMN Choreographies also have activities that are ordered by Sequence Flows. These “activities” consist of one or more interactions between Participants. These interactions are often described as being message exchange patterns (MEPs). A MEP is the atomic unit (Activity) of a Choreography. Choreographies exist outside of or in between Pools.

Choreographies can have the following elements:

• Choreograph Task
  • Loop
  • Multi-Instance
• Sub-Choreography
• Call Choreography
• Global Choreograph Task
• Sequence Flow
• Event
• Gateway
• Message
• Swimlane

The graphical elements are devided into fore categories (Overview):

• Swimlanes
  • Pools
  • Lanes
• Flow Objects
  • events
  • activities
  • gateways
• Connecting Objects
  • sequence flow
  • message flow
  • association

• Artifacts
  • data objects
  • groups
  • annotations

Swimlanes

Pools

Ein Pool ist ein Behälter für einen vollständig abgeschlossenen Prozess. Die Aktivitätenabfolge kann eine Poolgrenze nicht überschreiten, sondern nur innerhalb des Pools modelliert werden. Die Pools interagieren über den Austausch von Nachrichten. Ein Pool kann ein Unternehmen, eine Organisationseinheit, eine Person oder ein Computersystem sein. Ein black-box pool in contrast to a white box pool doesn't show any activities and messages go from or to the pool border. Silver empfiehlt einen Pool pro Prozess zu verwenden und einen white-box pool wie den Prozess zu benennen. Ein collaboration diagram beschreibt das Zusammenwirken von Prozessen in unterschiedlichen Pools.

Pools können entlang ihrer Ausdehnung wiederum in Lanes unterteilt werden, wobei ein Pool mindestens eine Lane enthalten muss. Die Frage, ob Pool oder Lane scheint nicht eindeutig zu beantworten sein. Kriterien könnten sein:

• ist Prozessinformation z.B. Status notwendig, dann Lanes
• ist Änderbarkeit oder Transparenz notwendig, dann Pool
• Prozess- und Bearbeitungsübergänge, dann Pool

Lanes

Eine Lane repräsentiert jeweils eine ausführende Einheit (Rolle, Funktion, Position). Möglich ist auch eine Lane pro System (alternativ Kennzeichnung der Activities durch eine System-spezifisches Icon). Nach 2.0 repräsentiert eine lane abstrakt gesprochen eine category, eine Menge von lanes ein category set. Für einen Prozess kann es mehrere category sets geben, die jeweils verschiedene Sichten auf den Prozess wiederspiegeln. Eine Lane hat keine Semantik?

Flow Objects

All Flow Objects that do not have an incoming Sequence Flow (i.e., are not a target of a Sequence Flow) shall be instantiated when the Process is instantiated.

Activities

Overview in BPMN Activities:

Activites can be atomic or non-atomic (compound).

• Task
• Sub-Process
• Call Activity

Activity markers are:

• Loop marker (reference to LoopCharacteristics is set and not NULL)
• Multi-instance (Parallel or sequential Multiple Execution Marker)
• Compensation Marker

If the Activity does not have an incoming Sequence Flow, then the Activity MUST be instantiated when the Process is instantiated.

If the Activity has multiple incoming Sequence Flows, then this is considered uncontrolled flow. This means that when a token arrives from one of the Paths, the Activity will be instantiated. It will not wait for the arrival of tokens from the other paths. If another token arrives from the same path or another path, then a separate instance of the Activity will be created.

Multiple Outgoing Sequence Flows can be used (see figure top-right). This represents uncontrolled flow.

If an Activity has no incoming Sequence Flows, the Activity will be instantiated when the containing Process or Sub-Process is instantiated. Exceptions to this are Compensation activities, Link intermediate event, Event Sub-Process

An Loop Activity has an additional attribute loopCounter which is set by the process engine.

The Multi-Instance Activity is somehow a specialization of a Loop Activity because of the BPMN spec class diagramm.

Compensation is concerned with undoing steps that were already successfully completed, because their results and possibly side effects are no longer desired and need to be reversed. To be compensated, an Activity MUST have a boundary Compensation Event or contain a Compensation Event Sub-Process.

Task

• is atomic
• starts immediately after the predecessor activity, this is at least from the modeling view also true for user tasks*
• can have markers:
  • Loop
  • Multi-Instance
  • Compensation
  • Loop and Compensation
  • Multi-Instance and Compensation
• task type can be represented by an icon. Task types are:
  • Abstract Task
  • Send
  • Receive
  • User
  • Manual
  • Business rule
  • Service
    • should be used for synchronous calls
  • Script

Send Task

• A Send Task is a simple Task that is designed to send a Message to an external Participant. Once the Message has been sent, the Task is completed.

Receive Task

• A Receive Task is a simple Task that is designed to wait for a Message to arrive from an external Participant. Once the Message has been received, the Task is completed.
• Can start a process, but must not have any incoming sequence flow in this case.

User Task

• A User Task is executed by and managed by a business process runtime. Attributes concerning the human involvement, like people assignments and UI rendering can be specified in great detail.
• A User Task is a typical “workflow” Task where a human performer performs the Task with the assistance of a software application and is scheduled through a task list manager of some sort.

Manual Task

• A Manual Task is a Task that is expected to be performed without the aid of any business process execution engine or any application. An example of this could be a telephone technician installing a telephone at a customer location.
• A Manual Task is neither executed by nor managed by a business process runtime.

Business Rule Task

• A Business Rule Task provides a mechanism for the Process to provide input to a Business Rules Engine and to get the output of calculations that the Business Rules Engine might provide.

Service Task

• A Service Task is a Task that uses some sort of service, which could be a Web service or an automated application.

Script Task

• A Script Task is executed by a business process engine. The modeler or implementer defines a script in a language that the engine can interpret. When the Task is ready to start, the engine will execute the script. When the script is completed, the Task will also be completed.
• has exactly one input set and at most one output set

Sub-Process

• Sub-Types are:
  • Ad-Hoc Sub-Process
  • Event Sub-Process
  • Transaction Sub-Process
• Markers are:
  • Loop
  • Multi-instance
  • Compensation
  • Ad-Hoc
  • Compensation and Ad-Hoc
• must start with at least one undefined start event, but more than one are confusing
• if a pool is used the name must be the same as the parent process, if there is no pool there is an implicit one of the parent process
• can also shown in a BPD inline/expanded
• can be an embedded subprocess or an global subprocess
• may contain lanes
• completes when all tokens have reached an End Event
• the exception flow happens immediately, triggering the next downstream, the sequence flow (normal flow) does not get executed

Ad-hoc Process

An Ad-Hoc Sub-Process or Process contains a number of embedded inner Activities and is intended to be executed with a more flexible. The Ad-Hoc Sub-Process contains only Activities, Sequence Flows, Gateways, and Intermediate Events. An Ad-Hoc Sub-Process MAY also contain Data Objects and Data Associations. The Activities within the Ad-Hoc Sub-Process are not REQUIRED to have incoming and outgoing Sequence Flows. However, it is possible to specify Sequence Flows between some of the contained Activities.

Event Sub-Process

• allow to handle an Event within the context of a given Sub-Processes or Process
• is a specialized Sub-Process that is used within a Process (or Sub-Process)
• when the triggeredbyEvent attribute of Sub-Process is true
• has no in-coming and out-going sequence flows
• MAY or MAY NOT occur while the parent Process is active, but it is possible that it will occur many times
• An Event Sub-Process MUST have one and only one Start Event
• they cannot have attached boundary Events
• becomes initiated, and thus Enabled and Running, through the Activity to which it is attached
• There are two possible consequences to the parent Process when an Event Sub-Process is triggered:
  • the parent Process can be interrupted (cancels execution of the enclosing Sub-Process, if the isInterrupting attribute of its Start Event is set)
  • the parent Process can continue its work (not interrupted) (enclosed runs parallel)
• If the parent Activity enters the state Completing, it remains in that state until all contained active Event Sub-Processes have completed
• there are special Event Sub-Processes
  • Compensation Sub-Process

Compensation Sub-Process

• A Compensation Event Sub-Process can recursively trigger compensation for Activities contained in its parent (see OMG spec example)

Call-Activity

• is a wrapper for a globally defined Process or Task that is reused in the current process.
• the called process has to have at least one None start event
• in BPMN 1.2 it was called re-usable Sub-Process
• Each time the Start Event is triggered while the parent Process is active, then the Event Sub-Process will start

Events

Overview in BPMN Events

BPMN does not require to model events, but if there is a start event there has to be an end event and the other way round. This applies to different levels, so a surounding process may have a start, but a enclosed sub-process may not have a start event. Start event must not have an incoming sequence flow.

If the event has multiple incoming sequence flows, then this is considered uncontrolled flow. This means that when a token arrives from one of the paths, the event will be enabled (to catch or throw). It will not wait for the arrival of tokens from the other paths. If another token arrives from the same path or another path, then a separate instance of the Event will be created.

There are three types:

• Start Events (thin line)
• Intermediate Events (double line)
• End Events (thick line)

and two flavors:

• throwing (e.g. all end events are throwing)
• catching (e.g. all start event are catching)

Start Events

• There are six different top-level start events:
  • None/undefined/unspecified start event
  • Message Start Event
  • Timer start event
  • Signal Start Event
  • Conditional Start Event
  • Multiple Start Event
  • (Parallel start event that triggers when all in signals in any must be received, since 2.0 see questions)
• There are three additional Event Sub-Process Start Events
  • Escalation Start Event
  • Error Start Event
  • Compensation Start Event
• Start events are always catching.
• There can be more than one start event. For each event a separate process instance is started. There can also be none start event, but it's not recommended.
• There should be only one undefined start event.

None Start Event

• The None/undefined/unspecified start event represents normally the manual process start by an user

Compensation Start Event

• The Compensation Start Event MAY NOT be used for a top-level Process

Timer Start Event

• A specific time-date or a specific cycle (e.g., every Monday at 9am) can be set that will trigger the start of the Process.

Intermediate Events

• Intermediate can be split in catching und sending/throwing.
• Catching/receiving intermediate events are waiting until the event arrives, throwing events are throwing and continuing
• there are no throwing timer events, just catching
• Intermediate events at an activity borders are catching events, listening for the trigger and called boundary events
• boundary events can be interrupting (solid line) or non-interrupting (dashed line). The interrupting event stops the activity immediately
  • Error, Compensation and Cancel Event are always interrupting (non-interrupting make no sense)
  • Compensation is only called, if activity is completed
• boundary events are listening as long the activity is running
• None intermediate events can e.g. be used to model state transitions of objects
• there are 11 intermediate events:
  • None/undefined
  • timer
  • message
  • rule/condition
  • error
  • signal
  • link
  • multiple consequences
  • compensating
  • escalation
  • cancel

Timer Intermediate Event

• at boundary in can be a stop-watch which starts when the activity starts or a alarm at a specific date/time

Link Events

• conncecting sequence flow on different pages via a link id

End Events

• end events signifies the end of a path in a process or subprocess
• end events are always throwing.
• there can be more end events.
• a process instance lives until the last token arrived at an end event or a process terminating end event is reached.
• there six different end events:
  • None/undefined
  • message end event
  • signal end event
  • error end event
  • escalation end event
  • cancel end event
  • multiple consequences end event
  • terminating end event

Signal End Event

• for loose coupling (publisher subscribe)

Error End Event

• reaching in a process or subprocess immediately ends that process level, even if path are active
• the result can only be catched by an (nearest enclosing) intermediate error event attached to the subprocess boundary

Escalation End Event

• like error end event, but process or subprocess is not aborted if there are still active path, so it triggers an additional activity

Cancel End Event

• another special end event, it's only used in transactional subprocess
• it interrupts the process or subprocess like the error end event

Terminating End Event

• ends the process level, even if there running paths
• doesn't propagate a result signal
• if it ends a subprocess, the next process level continues the normal flow

Gateways

• Symbols see BPMN Gateways
• Gateways have 'routing rules' (to distinguish them from 'business rules', which have a more general scope). The routing rules are hardcoded in the process model, business rules are defined independently e.g. in a separate database
• Gateways can have multiple outgoing paths
• Default outgoing path is always the only outgoing path, because it is only used when no condition fits
• the merging gateways has to be the same as the splitting gateway

XOR or Data-based Exclusive Gateway

• also called 'split and merge'
• exactly one outgoing path gets the token
• graphical X can be ommitted
• issues:
  • only one outgoing path gets the token, but what if condition leads to two, who will be the first and only (evaluation number)
  • better to define a default path if condition leads to no path
• if the condition leads to no or more than one outgoing paths is a modelling error, if the process is executed such that none of the conditional Expressions evaluates to true, a runtime exception occurs
• merge if one incoming branch (it does not block additional tokens that come after the first one)

Parallel Gateway

• split to all out pathes
• other names: parallel join, AND-join, synchronizing join
• merge only, when all ingoing paths have the token
• join may only be used to merge path that are unconditionally parallel
• doesn't have to be merged, can end in separate end events. In that case process or subprocess isn't finished until all end events are reached.

Inclusive Gateway

• one or more outgoing path gets the token
• other name: OR
• merge only, when all paths which got the token have the token
• issues:
  • depending on the complexity like loops before the merge it is hard to tell (and implement by a process engine) how many tokens should be waited for

Complex Gateway

• merge by rules

Event-based exclusive Gateway

• selects exactly one outgoing path based on the incoming event
• any other later event is ignored
• Event-Based Gateways are configured by having outgoing Sequence Flows target an Intermediate Event

or a Receive Task in any combination

Connecting Objects

Sequence Flow

• may not go out of a pool

Message Flow

• message means communication between a process activity or event and some entity outside the process
• message in reality can be phone call, fax or even face-to-face
• message flows are only allowed between different pools
• tasks can only be completed when the the message to this task has arrived

Associations

• no flow information
• from a sequence flow or message flow to data object it's non-directional, when linked to an activity or event it is directional

Data Objects

Data Objects provide information about what activities require to be performed and/or what they produce, Data Objects can represent a singular object or a collection of objects. The lifecycle of a Data Object is tied to the lifecycle of its parent Process or Sub-Process. When a Process or Sub-Process is instantiated, all Data Objects contained within it are also instantiated.

Data Input and Data Output provide the same information for Processes.

A Data Association uses the same notation as a directed Association to connect Data Objects to Activities. Data Associations are used to move data between Data Objects

A DataStore provides a mechanism for Activities to retrieve or update stored information that will persist beyond the scope of the Process.

Modeling Conventions

• use of gateways
• implicit or explicit start events
• implicit or explicit end events
• avoid multiple start events

Questions

• is a sub-process a type of activity or a task marker (OMG spec seems clear that it is a type of activity)
• send task semantics (z.B. in Method & Style page 62, http://www.processmodeling.info/posts/highlights-from-bpmn-2-0-activity-types/) vs. message event
• mehrere end events in subprocesses
• semantics of zwischenevents
• is there a parallel start in BPMN 2.0 as mentioned by Method & Style page 76
• what do multiple unspecified start events mean
• when a token will be go on if a multi-instance task is used and multiple instances are created
• intermediate events in sub-processes work only if sub-process has the token?
• Ad-Hoc Sub-Process
• multiple start events
• choegraphy, collaboration, conversation
• can a message association start in any task, although it is not a send task
• deadlock risk if message order between pools is errorneously changed
• what starts a process instance if there is None Start Event and the first tasks is a receiving task
• conditional event
• can a Event Sub-Process within a Sub-Process be triggered if the enclosing Sub-Process is already completed
• there is intermediate throwing compensation event, but it is said that the compensation is not started before the activity to be compensated is completed

Workflow Patterns

Workflow patterns are here, the first version contained 22 patterns, the revised version 42. Some patterns are a specialization or a composition of another. Graphical Examples can be found here.

Control-Flow Patterns

Basic Control-Flow Patterns

Nr.	Workflow Pattern	Description	BPMN Modelling
WCP1	Sequence		Sequence Flow
WCP2	Parallel Split		Parallel Gateway or multiple flows out of an activity
WCP3	Synchronization		Parallel Gateway
WCP4	Exclusive Choice		Data-based Exclusive Gateway
WCP5	Simple Merge		Data-based Exclusive Gateway or multiple flows in one activity

Advanced Branching and Synchronization Patterns

Nr.	Workflow Pattern	Description	BPMN Modelling
WCP6	Multi Choice		Inclusive Gateway or multiple flows out of an activity with gateway and condition
WCP7	(Structured) Synchronizing Merge		Inclusive Gateway fork and Inclusive Gateway merge
WCP8	Multi Merge		Inclusive Gateway fork and Data-based Exclusive Gateway merge
WCP9	(Structured) Discriminator	merge of parallel split only let the first (or concurrent token) through and blocks delayed token of other pathes	pattern description and BPMN spec indidcate Complex Gateway
WCP28	Blocking Discriminator	blocks parallel split for token behind the first token until the merge has performed	BPMN spec indidcates Complex Gateway
WCP29	Cancelling Discriminator	concurrent tokens of a parallel split are merged, merge cancels all other delayed parallel tasks
WCP30	Structured Partial Join	n of m parallel splits are merged, delayed tokens will be not be forwarded by the merge	pattern description and BPMN spec indidcate Complex Gateway
WCP31	Blocking Partial Join	n of m parallel splits are merged, blocks parallel split for token behind the first token until the merge has performed	BPMN spec indidcates Complex Gatewayor see this pattern example
WCP32	Cancelling Partial Join	n of m parallel splits are merged, merge cancels all other delayed parallel tasks	see this pattern example with signal event
WCP33	Generalized AND-Join	merge handling multiple tokens in the same instance, merge if all path of the merge have an active token
WCP37	Local Synchronizing Merge	example for a merge of non block-oriented process flow	according to BPMN specification Inclusive Gateway
WCP38	General Synchronizing Merge	example for a merge of non block-oriented process flow with loops	according to BPMN specification Inclusive Gateway
WCP41	Thread Merge	merges subsequent tokens in one path to one token
WCP42	Thread Split	splits one token to n subsequent tokens in one path	pattern example indicates multi-instance marker

Multi Instances Patterns

Nr.	Workflow Pattern	Description	BPMN Modelling
WCP12	Multiple Instances without Synchronization
WCP13	Multiple Instances with a priori Design-Time Knowledge		likely Multi-Instance Activity
WCP14	Multiple Instances with a Priori Run-Time Knowledge		likely Multi-Instance Activity
WCP15	Multiple Instances without a priori Run-Time Knowledge
WCP34	Static Partial Join for Multiple Instances	n of m multiple instance have to be finalized to forward the token, rest has only be finished if the token arrives again at the multi-instance task	likely Multi-Instance Activity
WCP35	Cancelling Partial Join for Multiple Instances	n of m multiple instance have to be finalized to forward the token, rest will be cancelled
WCP36	Dynamic Partial Join for Multiple Instances		likely Multi-Instance Activity

State Based Pattern

Nr.	Workflow Pattern	Description	BPMN Modelling
WCP16	Deferred Choice		Event-based exlusive Gateway
WCP17	Interleaved Parallel Routing	process part consists of multiple task which can be performed in any order but only one at the same time	BPMN spec indidcates Ad-Hoc Activity
WCP18	Milestone	parts of a process flow are enabled if a specific state (milestone) of the process is reached like a specific task was executed
WCP19	Critical Section	like in programming only one process branch may be in this section, others are blocked
WCP40	Interleaved Routing	tasks of a set can be executed in any order, but not parallel and just once	partly by Ad-Hoc Sub-Process, but no ensurance of only one execution

Iteration Pattern

Nr.	Workflow Pattern	Description	BPMN Modelling
WCP21			BPMN spec indicates Loop Activity

Resources

1. My own diagrams file:///C:\Uwes\Documents\Software_Development\Modeling\BusinessProcessModeling\BPM.vsd saved to C:\Uwes\xampp\htdocs\VisioExports\BPM.htm
2. http://camunda.org/bpmn/reference/ good reference for BPMN 2.0
3. C:\Uwes\Documents\Software_Development\Modeling\BusinessProcessModeling\BPMN_2.0.vss
4. Short, good Introduction C:\Uwes\Documents\Software_Development\Modeling\BusinessProcessModeling\Introduction_to_BPMN.pdf
5. Poster mit Elementen C:\Uwes\Documents\Software_Development\Modeling\BusinessProcessModeling\BPMN2_0_Poster_DE.pdf
6. BPMN Wikipedia http://de.wikipedia.org/wiki/Business_Process_Modeling_Notation Wikipedia
7. file:///C:\Uwes\Documents\Software_Development\Modeling\BusinessProcessModeling\BPMNByExample.pdf