Prof. Dr. Thomas Allweyer

Fachhochschule (University of Applied Sciences) Kaiserslautern, Germany thomas@allweyer.de

Title of the original version:

BPMN 2.0 Business Process Model and Notation. Einführung in den Standard für die Geschäftsprozessmodellierung.

2nd edition. BoD, Norderstedt 2009.

English version: Thomas Allweyer and Diana Allweyer

Bibliographische Information der Deutschen Nationalbibliothek:

Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliographie. Detaillierte bibliographische Daten sind im Internet über http://dnb.d-nb.de abrufbar.

All brand names, company names, and product names in this book are trademarks or registered trademarks or trade names of their respective holders.

The information in this book serves informational purposes only. The author assumes no responsibility for errors or omissions in this document and does not warrant the accuracy or completeness of any information, text, graphics, links, or other items.

This book is provided “as is” without warranty of any kind, either express or implied. The author shall have no liability for damages of any kind that may result from the use of this information.

©2010 Thomas Allweyer

Herstellung und Verlag: Books on Demand GmbH, Norderstedt

ISBN: 978-3-8448-8259-9

Contents

1  BPMN – A Standard for Business Process Modeling9

1-1  Why a Notation?

1-2  Development of BPMN

1-3  Innovations of BPMN 2.0

1-4  Business Models and Executable Models

1-5  About this Book

2  BPMN by Example

2-1  A First BPMN Model

2-2  BPMN Constructs Used

2-3  Sequence Flow Logic

2-4  Presentation Options

2-5  Appending Additional Information

3  Gateways: Splits and Merges

3-1  Exklusive Gateway

3-2  Parallel Gateway

3-3  Different Process Instances at a Parallel Join

3-4  Inclusive Gateway

3-5  Complex Gateway

4  Splitting and Merging without Gateways

4-1  Splitting without Gateways

4-2  Merging without Gateways

4-3  Modeling with or without Gateways?

5  Collaborations

5-1  Example of a Collaboration

5-2  Modeling Message Flows

5-3  Message Flows to Pools without Displayed Processes

5-4  Private and Public Processes

5-5  Multi-Instance Participants

5-6  Use of Collaborations and Sequence Flows

5-7  Modeling of Message Content

6  Events

6-1  Example for the Use of Events

6-2  Start Events

6-3  End Events

6-4  Intermediate Events

6-5  Event-Based Decisions

7  Activities

7-1  Sub-Processes

7-2  Loops and Multi-Instance Activities

7-3  Ad-hoc Sub-Processes

7-4  Types of Tasks

7-5  Call of Processes and Global Tasks

7-6  Examples of Sub-Processes and Called Processes

8  Handling of Exceptions

8-1  Interrupting Intermediate Events

8-2  Non-Interrupting Intermediate Events

8-3  Handling of Errors

8-4  Escalation Events

8-5  Event Sub-Processes

9  Transactions and Compensations

9-1  Modeling of Transactions

9-2  Direct Call of Compensations

9-3  Event Sub-Processes for Compensations

9-4  Use of Exceptions, Transactions and Compensations

10  Data Objects in Processes

10-1  Modeling Data Flow

10-2  Multiple Data Objects

10-3  Data and Events

10-4  Data Store

10-5  Passing Data to Called Activities

10-6  Use of Data Objects

11  Choreographies

11-1  Choreography Diagrams

11-2  Choreography within Collaboration

11-3  Choreography Sub-Processes

11-4  Gateways in Choreographies

11-5  Events in Choreographies

11-6  Calling Choreographies and Global Choreography Tasks

11-7  Use of Choreographies and Collaborations

12  Conversations

12-1  Conversation Diagram

12-2  Message Correlation

12-3  Hierarchies of Conversations

12-4  Calling Global Communications and Conversations

12-5  Use of Conversation Diagrams

13  Artifacts and Extensions of BPMN

13-1  Artifacts

13-2  Ways of Extending BPMN

A Bibliography

B BPMN in the Internet

Index

1   BPMN - A Standard for Business Process Modeling

1.1   Why a Notation?

In order to manage business processes, they have to be described and documented. There are various possibilities to do so. The easiest way is the usage of textual or tabular descriptions. Flow chart diagrams are quite often created by means of presentation and graphics software. These diagrams mostly consist of small boxes and arrows, not following a defined method.

Unfortunately, this does not meet the requirements of exactly representing extensive processes with all relevant aspects, such as splitting rules, events, organizational units, data flow, etc. For this, appropriate notations are required. A notation for graphic business process modeling defines for example the symbols for the various process elements, their correct meaning, as well as their possible combinations.

Thus, a notation is a standardized language for the description of business processes. Everybody, who is familiar with this language, is able to understand models created by someone else. Furthermore, processes can be systematically analyzed, and their dynamic behavior can be simulated based on a standardized representation.

The subject of “Governance, Risk, and Compliance” (GRC), which is getting increasingly important, also requires a standardized and complete documentation of adequate processes that makes sure that any legal and industry-specific demands with respect to risk management, quality management, and the compliance with safety rules, etc., are met.

Since models provide a basis for the development of information systems for executing and supporting business processes, they need a standardized structure, and have to contain all information relevant for system development.

System-supported processes are more and more controlled by business process management systems (BPMS). These contain process engines which directly control the workflows by means of appropriate process models or formal process descriptions. For this purpose the models have to meet very strict demands, because they are not converted into a computer program by a human being, but directly processed by a machine.

In the course of time, several notations for process modeling emerged. These were quite often proprietary notations of special modeling tools or workflow management systems. By now, standards for executable process descriptions have been established, as for example XPDL (XML Process Definition Language) [Workflow Management Coalition 2008], and BPEL (Business Process Execution Language) [OASIS 2007], with BPEL as the leading standard. But XPDL and BPEL are no graphic notations, and the main range of application is the definition of automatic processes. Details of the various standards for executable processes are given in [Havey 2005] and [Weske 2007].

In the area of business-oriented process modeling, the notation of the event-driven process chain (EPC) is frequently used. The EPC was mainly disseminated by IDS Scheer’s modeling tool ARIS, and as a notation in many SAP implementation projects. However, EPC is not a standard, and it is supported only by a few modeling tools of other vendors.

Other standards, such as the activity diagrams of the Unified Modeling Language (UML), did not become accepted for business process modeling in practice. Their use basically remained restricted to the area of object-oriented software design, where UML is the accepted standard.

It seems that with BPMN (Business Process Model and Notation) for the first time a standard for process modeling is becoming accepted on a broad basis. The website www.bpmn.org contains a list with more than 60 tools which support BPMN modeling. An increasing number of websites, weblogs and publications demonstrate the growing interest in this notation (e.g. [Briol 2008], [Debevoise and Geneva 2008], [White and Miers 2008], [Silver 2009]). Even a novel on process modeling with BPMN has been published [Grosskopf et al. 2009]. A selection of interesting internet sources can be found in the annex of this book.

Several large European organizations are providing their process management teams with BPMN training, and they are rolling out BPMN as their organization-wide modeling standard. In the e-government standards of Switzerland, for example, the use of BPMN is recommended as a common notation [Lienhard et al. 2008].

1.2   Development of BPMN

Originally, BPMN was developed by the Business Process Management Initiative (BPMI), a consortium which consisted mainly of software companies. In the beginning, the purpose was to provide a graphical notation for process descriptions expressed in BPML (Business Process Modeling Language). Comparable to BPEL, BPML was used for specifying process descriptions which could be executed by a BPMS. BPML is not being developed further anymore; it has been given up in favor of BPEL.

The first version of the BPMN specification was developed by a team lead by Stephen A. White from IBM. It was published in 2004. In the meantime, BPMI has become a part of the Object Management Group (OMG). This organization is known for several software standards, such as the aforementioned UML (Unified Modeling Language).

In 2006, BPMN version 1.0 was officially accepted as an OMG standard. In 2008, version 1.1 followed. It contains some changes in the graphical representation. These must be taken into account, since several modeling tools still contain version 1.0. An overview of changes from version 1.0 to 1.1 can be found in [Decker and Schreiter 2008]. The latest officially adopted version is 1.2 [Object Management Group 2008]. It only contains a few editorial corrections and clarifications, the contents as such have not changed from version 1.1.

Interesting news will only be brought by the upcoming version 2.0, the draft of which has already been accepted by the Architecture Board of the OMG [Object Management Group 2009]. This draft is currently being fine-tuned by a workgroup which eliminates faults and problems and makes slight changes prior to the specifination’s approval, presumably in the second half of 2010. Since any fundamental changes are not expected any more, the first vendors of modeling tools have already started with the implementation of BPNM 2.0. Latest publications, too, are already referring to the new version.

1.3   Innovations of BPMN 2.0

Fortunately, the notation elements of BPMN 1.2 (and thus those of version 1.1, too) have not significantly been changed in the upcoming version. The graphic notation has been extended by various constructs and by a few new model types. Thus, existing models based on BPMN 1.2 are upwards compatible, which means they do generally also correspond to the version 2.0.

Those readers, who are already familiar with the version 1.2, can find below a short overview of the most important extensions of the graphic notation in version 2.0. In the following chapters they will be explained in detail, together with the unchanged parts of BPMN. The pages, on which the alterations are described, are given in parentheses.

Version 2.0 contains the following extensions of the existing diagram types for process and collaboration modeling:

 •   New event types: Parallel multiple events (p. 63), and escalations (p.107).

 •   Parallel event-based gateway to initiate a process (p. 78).

 •   Intermediate events attached to activities, which start an exception flow, but do not interrupt the particular activity (p. 101).

 •   Event sub-processes that are only carried out when defined events occur, and which run in parallel to the surrounding process, or interrupt it (p. 109).

 •   Extended options for the modeling of data in processes, for example data storage (p. 123) and data objects representing lists (p. 124).

 •   Upgrades of collaboration modeling as for example multi-instance participants (p. 54), and the representation of messages by envelope symbols (p. 57).

 •   Symbols for the different types of tasks (p. 91).

 •   New ways of modeling how to call activities that are defined somewhere else (p. 91).

 •   Different marking of multi-instance activities, depending on their execution in parallel or in sequence (p. 88).

Two completely new diagram types are added:

 •   Choreography diagram: Modeling of the data exchange between different partners, similar as in collaborations. However, each data exchange is modeled as an activity, so that on this level it is possible to visualize splits, loops, etc. (p. 128).

 •   Conversation diagram: A conversation diagram is an overview of several partners and their communication links (p. 138).

Although the innovations mentioned above are very prominent in BPMN 2.0, the majority of the alterations took place behind the scenes of the graphic model representation.

BPMN 2.0 received for the first time a formal definition in the form of a metamodel. The specifications of the previous versions only contained verbal descriptions of the graphic notation elements and modeling rules. The new version’s specification document has got comprehensive UML class diagrams that graphically show the features of the different BPMN constructs and their relationships. Such a metamodel is more accurate and definite than strictly verbal descriptions. The metamodel also has got additional language constructs that cannot be represented in graphic models. Such constructs are required, for example, by process engines to capture the necessary additional information for process execution.

The typical modeler does not need to work with the metamodel. Normally, he will use a modeling tool that only allows the creation of models complying with the specification, and thus with the metamodel. Therefore, it is rather the vendors of modeling tools, process engines, and similar software, who have to deal with the metamodel.

The metamodel was also the basis for the development of an exchange format for BPMN-models. Up to now it was almost impossible to transfer BPMN models from one tool into another. Some tools have got import and export interfaces for the exchange of BPMN models by means of the XPDL format [Shapiro 2008], but the use of XPDL for this purpose is not widely accepted yet. Furthermore, XPDL has not been implemented uniformly by all vendors, so that in practice there are quite often problems with model exchange.

BPMN 2.0 now provides its own standardized exchange format. It can only be hoped that the tool vendors will support this standard format. Then it will finally be possible to exchange BPMN models not only between different modeling tools, but also between a modeling tool and a BPMS, for example.

BPMN’s definition of executable processes has also been enhanced. On the one hand, many details essential for executing a process did not have appropriate elements and attributes in the past. On the other hand, there was large room of interpretation how to concretely execute a specific model by a process engine. BPMN 2.0 has been expanded accordingly, and an explicit “execution semantics” was defined, i.e. the interpretation and execution of definite BPMN-models has been precisely described. The new BPMN specification does also have rules for transforming BPMN models into an executable BPEL format, but nevertheless it should be possible to directly execute detailed BPMN models. Possibly, there will be future business process management systems that directly execute BPMN structures without having to transform them into BPEL or another format first.

Until now it was not regulated which requirements a software tool has to fulfill in order to support BPMN modeling. Thus, a software vendor can claim the implementtation of BPMN in his product, although it might contain only a very small part of the language. In order to remedy this, there are now criteria to decide whether a software tool is BPMN compliant or not.

The different types of software tools in the scope of BPMN required the definition of various types of BPMN conformance. Pure modeling tools may be process modeling conformant or choreography modeling conformant. Process engines should comprise process execution conformance or BPEL process execution conformance. In future, these criteria could be decisive in the choice of software. Since many software vendors are certainly interested in reaching BPMN conformance, these criteria should also lead to a comprehensive implementation of BPMN in a large number of tools.

Since BPMN was complemented with the metamodel, the name was changed as well. The abbreviation BPMN does not stand for “Business Process Modeling Notation” any more, but for “Business Process Model and Notation”. This expresses that it is more than just a notation.

Although the contents of BPMN 2.0 are mostly defined, there still might be slight changes prior to its adoption. Current information on this subject will be published on the website www.bpmn-introduction.com.

1.4   Business Models and Executable Models

The origin of BPMN was in the field of process descriptions that can be performed by the process engine of a workflow or business process management system (BPMS). But the developers of BPMN claim that with this notation it is possible to create technical as well as business-level models. BPMN is supposed to be a common language of both, business experts and IT experts.

Queensland University conducted a survey of about 600 BPMN users which affirmed that BPMN is being used for business modeling as well as for the modeling of executable processes: Half of the interviewees stated to create mainly business-oriented process models, the other half was rather dealing with technical models [Recker 2008, p. 2]. According to a survey in Europe, BPMN was most frequently used for pure process documentation rather than for workflow modeling, whereas in future it is expected to be increasingly applied in the field of workflow management and service-oriented architectures (SOA) [Franck and Henninger 2008, p. 8].

Although having a common notation, business models and technical models are quite different in practice. The main focus of business models is on the comprehension of the basic process flow. Thus, the usage of too many details is avoided. Conditions of a decision are rather expressed in plain text than in exact logical terms. Exceptions and rare cases are quite often not modeled in detail, but explained by notes and descriptions.

The source of some BPMN constructs is quite clearly the field of executable process specifications. BPMN contains among others special loop constructs, exception handling, and transactions. Programmers and IT-specialists are familiar with these subjects. Business process modelers normally omit such items. In accordance to this, typical business models only comprise a restricted part of the whole notation (see [zur Muehlen and Recker 2008]).

Some BPMN experts consider that these rather technical constructs should also be used in business models, in order to be able to show business-relevant exceptions and their handling in a process: “The familiar 80-20 rule says that 80% of the costs, delays, and errors come from 20% of the instances – the exceptions. So it should be up to the business to specify – in a non- technical way – how any type of exception should be handled: a customer cancels or changes the order, an item is out of stock, or timeout occurs.” [Silver 2007].

Those who want to apply BPMN for business process modeling should decide in advance which constructs should be used and how certain cases should be represented. It makes sense to stipulate such decisions in the form of modeling conventions. Should the processes modeled on a business level then be automated by a process engine, the way of transforming business models into models of executable processes has to be specified, i.e. how the necessary additions, reorganization, and detailing are to be carried out.

As already mentioned, BPMN 2.0 defines execution semantics for the process models. This should reduce many problems related to modeling of executable processes. The execution semantics are also helpful for transforming BPMN models into executable process descriptions, such as BPEL. Since the internal structure of BPEL is rather different from that of BPMN, such a transformation is still not easy. The BPMN specification itself contains an annex with a proposal for mapping BPMN models to BPEL; and there are also several further publications about this subject, e.g. [White 2005], [Ouyang et al. 2006]. In principle it is now also possible to execute BPMN models directly. However, even with the defined execution semantics there are still many problems in practice [cf. Freund et al. 2010, p. 187 ff.].

A powerful process engine should be able to support typical situations which occur in processes. These include e.g. splits and parallel flows, but also complex cases, such as merging several independent process instances into a new instance. The so-called “workflow patterns” are a collection of such typical structures [Russell et al. 2006]. How to model the different workflow patterns in BPMN is discussed in [Briol 2008], [Großkopf 2007] and [Wohed et al. 2006].

1.5   About this Book

This book provides an introduction to the notation of BPMN 2.0. Starting with a small example process, the basic BPMN elements for modeling simple flows are discussed. Step-by-step the different BPMN concepts are introduced and explained using examples. The examples are generally intelligible business-domain models, so that the reader does not need to have any specific IT know-how. There are only a few examples actually referring to process execution by a BPMS which are required for understanding some of BPMN’s more technical features.

Since the main focus is on the application of the notation for business-oriented process modeling, the BPMN metamodel is not part of this book, nor is the execution semantics discussed.

This book presents the entire notation. Although as described above, not for every modeling purpose all BPMN elements will be required, modeling experts still should be familiar with the entire BPMN. Only then they can reasonably select what is required and useful for their own modeling activities.

It was taken care that the discussion of the various BPMN concepts conforms to the official BPMN specification, as much as possible. Sometimes it was necessary to interpret the descriptions from the specification to some degree. Therefore, the explanations in this book always represent the author’s understanding. The author is always happy to receive feedback concerning mistakes and suggestions for improvement.

The book is an introduction to the BPMN standard. Thus, it does not discuss topics outside the standard, such as how to apply the notation in the best way, which modeling conventions should be followed, how specific tools are to be applied, etc. There are entirely different ways of using BPMN, as well as different modeling procedures, and best practices for “good modeling”. These topics remain for other publications. Some suggestions can be found in [Silver 2009] and [Freund et al. 2010].

The book’s website can be reached at www.bpmn-introduction.com. It contains up-to-date additions, information about BPMN’s further development, as well as additional links to BPMN-related content.

2   BPMN by Example

2.1   A First BPMN Model

As a starting point, a simple BPMN process model is considered. The model of posting a job in figure 1 can be directly understood by most people who previously have been concerned with any kind of process modeling. The way of modeling is similar to well known flow charts and activity diagrams.

Figure 1: A simple BPMN model

A business department and the human resources department are involved in the process “Post a Job”. The process starts when an employee is required. The business department reports this job opening. Then the human resources department writes a job posting. The business department reviews this job posting.

At this point, there are two possibilities: Either the job posting is okay, or it is not okay. If it is not okay, it is reworked by the human resources department. This is once more followed by the business department reviewing the job posting. Again, the result can be okay or not okay. Thus, it can happen that the job posting needs to be reviewed multiple times. If it is okay, it is published by the human resources department, and the end of the process is reached.

In reality, the process for creating and publishing a job posting can be much more complex and extensive. The presented example is – like all examples in this book – a simplification in order to have small and easily understandable models which can be used for explaining the different BPMN elements.

2.2   BPMN Constructs Used

Below each element from the model in figure 1 is explained more closely.

The entire process is contained in a pool. This is a general kind of container for a complete process. In the example above, the pool is labeled with the name of the contained process.

Every process is situated within a pool. If the pool is not important for understanding the process, it is not required to draw it in the diagram. In a process diagram which does not show a pool, the entire process is contained in an invisible, implicit pool.

Pools are especially interesting when several pools are used in order to model a collaboration, i.e. the interplay of several partners’ processes. Each partner’s process is then shown in a separate pool. This will be described in chapter 5.

The pool from figure 1 is partitioned into two lanes. A lane can be used for various purposes, e.g. for assigning organizational units, as in the example, or for representing different components within a technical system. In the example, the lanes show wich of the process’s activities are performed by the business department and which by the human resource department.

Pools and lanes are also called “swimlanes”. They resemble the partitioning of swimming pools into lanes. Every participant of a competition swims only in his own lane.

The process itself begins with the start event “Employee required”. Processes usually have such a start event. Its symbol is a simple circle. In most cases it makes sense to use only one start event, not several ones.

A rounded rectangle represents an activity. In an activity something gets done. This is expressed by the activities’ names, such as “Report Job Opening” or “Review Job Posting”.

The connecting arrows are used for modeling the sequence flow. They represent the sequence in which the different events, activities, and further elements are traversed. Often this is called control flow, but in BPMN there is a second type of flow, the message flow, which influences the control of a process as well, and is therefore some kind of control flow, too. For that reason, the term “sequence flow” is used. For distinguishing it from other kinds of flow, it is important to draw sequence flows with solid lines and filled arrowheads.

The process “Post a Job” contains a split: The activity “Review job posting” is followed by a gateway. A blank diamond shape stands for an exclusive gateway. This means that out of several outgoing sequence flows, exactly one must be selected. Every time the right gateway in the job posting-process is reached, a decision must be taken. Either the sequence flow to the right is followed, leading to the activity “Publish Job Posting”, or the one to the left is selected, triggering the activity “Rework Job Posting”. It is not possible to follow both paths simultaneously.

The logic of such a decision is also called “exclusive OR”, abbreviated “XOR”. The conditions on the outgoing paths determine which path is selected. If a modeling tool is used and the process has to be executed or simulated by a software program, then it is usually possible to formally define exact conditions. Such formal descriptions, which may be expressed in a programming language, can be stored in special attributes of the sequence flows.

If, on the other hand, the purpose of a model is to explain a process to other people, then it is advisable to write informal, but understandable, statements directly into the diagram, next to the sequence flows. The meaning of “okay” and “not okay” after the activity called “Review Job Posting” is clear to humans – a program could not make use of it.

Gateways are also used for merging alternative paths. In the sample process, the gateway on the left of the activity “Review Job Posting” merges the two incoming sequence flows. Again, this is an exclusive gateway. It expects that either the activity “Write Job Posting” or “Rework Job Posting” is carried out before the gateway is reached – but not both at the same time. It should be taken care to use a gateway either for splitting or for joining, but not for a combination of both.

The last element in the example process is the end event. Like the start event it has a circle as symbol – but with a thick border.

2.3   Sequence Flow Logic

The flow logic of the job posting process above is rather easy to understand. In more complex models it is sometimes not clear how the modeled structure exactly is to be interpreted. Therefore it is helpful if the meaning of the sequence flow’s elements is defined in an unambiguous way.

The logic of a process diagram’s sequence flow can be explained by “tokens”. Just as in a board game tokens are moved over the board according to the game’s rules, one can imagine moving tokens through a process model according to BPMN’s rules.

Every time the process is started, the start event creates a token (cf. figure 2). Since the job posting process is carried out more than once, many tokens can be created in the course of time. Thereby it can happen that the process for one job posting is not yet finished, when the process for posting another job starts. As it moves through the process, each token is independent from the other tokens’ movements.

Figure 2: A start event creates a token

The token that has been created by the start event moves through the sequence flow to the first activity. This activity receives a token, performs its task (in this case it reports a job opening), and then releases it to the outgoing sequence flow (cf. figure 3).

Figure 3: An activity receives a token and forwards it after completion

The following activity forwards the token. It then arrives at the merging exclusive gateway. The task of this gateway is simple: It just takes a token that arrives via any incoming sequence flow and moves it to the outgoing sequence flow. This is shown in figure 4. In case A, a token arrives from the left, in case B from below. In both cases the token is routed to the outgoing sequence flow to the right.

Figure 4: Routing of a token by a merging exclusive gateway

The task of the splitting exclusive gateway is more interesting. It takes one arriving token and decides according to the conditions, to which sequence flow it should be moved. In case A in figure 5, the condition “okay” is true, i.e. the preceding review activity has produced a positive result. In this case, the token is moved to the right. Otherwise, if the condition “not okay” is true, the token is moved to the downwards sequence flow (case B).

The modeler must define the conditions in such a way that always exactly one of the conditions is true. The BPMN specification does not state how to define conditions and how to check which conditions are true. Since the considered process is not executed by software, the rather simple statements used here are sufficient. Otherwise, it would be necessary to define the conditions according to the requirements and rules of the software tool.

The token may travel several times through the loop for reworking the job posting. Finally it arrives at the end event. This simply removes any arriving token and thus finishes the entire process (figure 6).

Figure 5: Routing of a token by a splitting exclusive gateway

The sequence flow of every process diagram can be simulated in this way with the help of tokens. This allows for analyzing whether the flow logic of a process has been modeled correctly.

It should be noted that a token does not represent such a thing as a data object or a document. In the case of the job posting process, it could be imagined to have a document “job posting” flowing through the process. This document could contain all required data, such as the result of the activity “Review Job Posting”. At the splitting gateway, the decision could then be based on this attribute value. However, the BPMN sequence flow is constrained to the pure order of execution. The tokens therefore do not carry any information, other than a unique identifier for distinguishing the tokens from each other. For data objects there are separate BPMN constructs which will be presented in chapter 10.

2.4   Presentation Options

Usually pools are drawn horizontally. The preferred direction of sequence flow is then from left to right. On the other hand, it is also possible to use vertical pools and to draw the sequence flow from top to bottom, as in the example in figure 7.

It makes sense to decide for only one of these possibilities – horizontal or vertical. Nevertheless there are modeling tools which only support horizontal modeling.

Figure 6: An end event removes an arriving token

Figure 7: Vertical swimlanes and nested lanes

Figure 7 also shows an example of nested lanes. The lane labeled “Sales” is partitioned into the two lanes “Sales Force” and “Order Processing”. In principle it is possible to partition these lanes again, etc., although this only makes sense up to a certain level of depth.

It is not prescribed where to place the names of pools and lanes. Typical are the variants selected for figure 1 and figure 7. Here the names are placed on the left of the pools or lanes, or at the top for the vertical style, respectively. The name of a pool is separated by a line. The names of the lanes, however, are placed directly within the lanes. A separation line is only used for a lane that is partitioned into further sub-lanes.

Lanes can also be arranged as a matrix. The procurement process in figure 8 runs through a business department and the procurement department, both of which span a branch office and the headquarters. When a demand occurs in a branch’s business department, this department reports the demand. In the next step, the procurement is approved by the same department in the headquarters. The central part of the procurement department then closes a contract with a supplier, followed by the branch’s purchasing department carrying out the purchase locally.

Although the BPMN specification explicitly describes the possibility of such a matrix presentation, it is hardly ever applied, so far. Probably not many people are aware of this structure, and nor do common BPMN modeling tools support it. Nevertheless, in many cases the matrix structure would provide good visualization means.

Figure 8: Lanes arranged in a matrix

Lanes can not only be used for organizational units or roles. They can be applied for categorizing a process’s activities according to any kind of criteria. In figure 9, the job posting process from the beginning is partitioned not anymore according to organizational units, but according to the information systems used.

In the BPMN specification – like in this book – all elements are printed in black and white. However, it is also allowed to color the models as desired. Colors can be used for creating models that are optically more appealing. Moreover, colors can be applied in order to mark elements according to certain criteria. As an example, very important elements can be highlighted, or critical elements can be colored red.

Other graphical extensions are also possible, e.g. different kinds of activities can be marked with catchy symbols. Any changes are allowed that do not change the standard symbols essence. Thus it would not be permitted to use a circle as a symbol for an activity, since it would not be recognizable as an activity any more. In contrast, if the rounded rectangle would be complemented with an additional icon, every BPMN expert still would recognize that the symbol denotes an activity.

Figure 9: Lanes representing the involved information systems

2.5   Appending Additional Information

A BPMN model’s elements are not only graphical symbols. They can be appended with additional information, such as simple attributes or additional elements which are not shown in the diagram. The BPMN metamodel defines for all types of elements several possible types of additional information. To a large extent this information is rather technical, and it is mainly needed for process execution by a process engine. For example, it is possible to add formal expressions to sequence flows in order to define conditions for selecting an outgoing sequence flow. This enables the process engine to evaluate the conditions and pick the correct exit of the gateway.

In figure 10, such conditions are shown as annotations at the outgoing sequence flows of a gateway. In BPMN, an annotation is preceded by an opening square bracket which is connected to the referred element by a dotted line. When using a modeling tool, attribute values and other additional information are usually not shown in the diagram. Instead it may be possible to open a dialog for each element in which such information can be displayed and edited.

Figure 10: BPMN elements can be provided with additional information

Although many other modeling notations comprise attributes for business related information, such attributes cannot be found in the BPMN specification. Attributes for times, cost rates, capacities, etc. are not defined. However, it is possible to define individual extensions for BPMN elements. On the other hand, invidually defined extensions are not standardized. Therefore it is difficult to compare models containing such extensions. The features of modeling tools also may restrict the possibilities for defining one’s own extensions.

3   Gateways: Splits and Merges

Gateways are used for splitting and joining sequence flows. In addition to exclusive gateways already mentioned in chapter 2, further gateway types exist: the parallel gateway for modelling several parallel paths, the inclusive gateway chosing one or more paths, and the complex gateway which is used for splits and joins according to complex rules.

3.1   Exklusive Gateway

The exclusive gateway is used for modelling alternative paths. It is applied either as a split, or a merge. As shown in figure 11, there are two symbols for representing an exclusive gateway: a blank diamond shape, or a diamond shape with a large “X”. It is reasonable to consistently use only one of these variants. In this book the empty diamond shape is used.

Figure 11: Two different symbols for the exclusive gateway

It is not forbidden to have a gateway with both multiple inputs and multiple outputs, but such a combination of a split and a merge might lead to misinterpretation. Therefore, this is not recommended. It is better to separate splits and merges (cf. figure. 12). This also applies to the other gateway types represented below, not only to the exclusive gateway.

Figure 12: A single gateway should not be used simultaneously for merging and splitting

Furthermore it should be considered that a gateway represents only logic, i.e. no activity is carried out, and no time passes while running through a gateway. This applies to any kind of gateway. If an activity is modeled that should take a decision, it is represented as an activity followed by an exclusive gateway (cf. figure 13). Another possibility to model this case is shown in chapter 4.1.

Figure 13: A gateway only represents logic, but not an action

A splitting exclusive gateway may have multiple exits between which a decision has to be taken. The conditions are noted either in plain text at the exiting sequence flows, or they are stored in attributes in the form of logic expressions. The latter can be evaluated by process engines.

Many flowcharts use a representation as in figure 14, where the question is located in the gateway symbol, and the sequence flows only carry the answers “yes” and “no”. The BPMN specification does not explicitly mention this representation. But since the specification contains some figures with this kind of modeling, it might be at least applied as concise representation in business models. If the text is too long or the symbol with “X” is used, the question can also be noted next to the gateway symbol.

Figure 14: Question in gateway symbol

As already mentioned, the XOR logic of this gateway type requires exactly one condition to be true. If in figure 15 the condition of the bottom sequence flow was “amount < 200 €” instead of “amount < 100 €”, this rule would be violated, because the bottom exit as well as the second exit from the bottom would have to be selected for amounts between 100 € and 200 €.

Figure 15: A gateway can have any number of exits

One of the exits can also be defined as default exit. The default exit can only be selected if no condition from the remaining exits is true. The default is marked with a small diagonal slash. Thus, the example in figure 15 can also be modeled as in figure 16.

Figure 16: The bottom exit is marked as default exit

If an exclusive gateway as in figure 17 is used for merging; it must be ensured that every time only one entrance receives a token. This can be achieved by modeling the preceding split with an exclusive gateway, too.

Figure 17: Merging exclusive gateway

The gateway presented selects the exit by evaluating data. Thus, it is called “databased exclusive gateway”. There is also a so-called “event-based exclusive gateway”, which will be presented in chapter 6.

3.2   Parallel Gateway

By means of a parallel gateway, a sequence flow can be split into two or more parallel paths. This corresponds to a logical “AND”. Parallel paths are also joined by a parallel gateway. A parallel gateway is represented by a diamond shape carrying a plus sign.

Figure 18: Usage of parallel gateways

In figure 18, a job posting is written, first. Then, the job posting should be published internally as well as externally. Thus, the activities “Publish Job Posting Internally” and “Publish Job Posting Externally” both have to be carried out. Nevertheless, a special order is not prescribed, so that the job posting can be published internally first and then externally, or vice versa – or the two activities can be carried out simultaneously.

The logic of a parallel gateway can also be visualized by the flow of tokens. If a token reaches a splitting parallel gateway, it will be duplicated. Every outgoing sequence flow generates a token (cf. figure 19).

Figure 19: A splitting parallel gateway duplicates the tokens

Figure 20 represents the logic of a joining parallel gateway. When a token arrives via one of the incoming sequence flows, it is not directly passed on (left). Instead it is waited until at each entrance a token has arrived (center). Only then the tokens of all entrances are processed. They are joined again to one token which is then emitted by the gateway’s only exit.

Figure 20: A joining parallel gateway waits for all arriving tokens and merges them into one token

3.3   Different Process Instances at a Parallel Join

Using the example from figure 18, it is easy to understand the concept of different process instances. Each activation of a process is represented by a new process instance. The model from figure 18 is a process definition. Here it is defined how a job posting is created in general.

If a job posting is created for a specific open position, e.g. for a purchasing agent, this single execution of the general process is a process instance.

This can be related to the idea of the token flow: Each time a start event produces a new token, a new process instance is created. Thus, at the beginning a token represents a process instance. If a token is duplicated by a parallel gateway, the resulting two or more tokens still belong to the same process instance. They are a kind of partial tokens of the original token. A joining parallel gateway fuses them together again to the original token.

At the joining parallel gateway it is not sufficient that each entrance receives an arbitrary token. Instead the tokens must be partial tokens that belong together. This is important if several process instances are executed simultaneously. In the mentioned example, several job postings may be created at the same time.

Figure 21: A first process instance is started

In figure 21, a token T1 is created (top). This is duplicated at the parallel gateway. The resulting tokens are labeled T1.1 and T1.2 (center). Now the job posting is published externally. The internal publication is not yet done. Thus, token T1.2 resides at the joining parallel gateway. Here the process must wait until token T1.1 has arrived, as well (bottom).

In this situation, a second instance of the same process is created, because a second job posting is required. This is shown in figure 22. A second token T2 is produced. This token is also duplicated at the splitting parallel gateway; the tokens T2.1 and T2.2 are created (center). The second job posting is first published internally, the external publication takes longer. At that time, the first job posting – for whatever reasons – has still not been published internally. Therefore token 1.1 still is at the entrance of the activity “Publish Job Posting Internally”. Token T2.1 in contrast has reached the joining parallel gateway (bottom).

Figure 22: A second process instance is created

Now there are tokens at both gateway entrances. Nevertheless, these two tokens are not joined and passed on, since these partial tokens belong to different process instances. In this example they are related to different job postings.

Figure 23: The process will only be continued when all tokens of a process instance have arrived

Figure 23 shows the next step: The first job posting has finally been published internally, i.e. token T1.1 moves to the parallel gateway. Now both partial tokens T1.1 and T1.2 of process instance T1 are in front of the parallel gateway (top). They are joined together to token T1 which is then forwarded to the end event (bottom). Token T2.1 still waits for token T2.2, until these two partial tokens are also joined together and moved on.

3.4   Inclusive Gateway

An inclusive gateway selects or merges one or more paths. In figure 24, media need to be selected for publishing a job posting. The company’s homepage, a newspaper, and an internet job portal can be selected. Any combination with at least one of these options is possible. If no medium was selected, the posting would not be published at all. An inclusive gateway therefore represents the logic of an (inclusive) OR.

Figure 24: At a splitting inclusive gateway, one or more sequence flows are selected

A merging inclusive gateway waits for all those related tokens that still can arrive according to the previous sequence flow logic. If only one sequence flow is selected in a splitting inclusive gateway, i.e. for example either the homepage or the newspaper, only one token can arrive at the merging gateway. Thus, when the token has arrived, it will be immediately passed (figure 25). In this case, the merging inclusive gateway behaves like an exclusive gateway which also passes on one single token after its arrival.

Figure 25: Inclusive gateway – one path selected

If, however, two or three sequence flows are selected at the splitting point, the behavior of an exclusive gateway would be unsuitable, because it would generate a new token each time one token arrives, so that these tokens would not be merged, but two or three tokens would be passed on, one after the other.

If in a splitting inclusive gateway all sequence flows are selected, the merging inclusive gateway has to behave like a parallel gateway, because it must only then pass a token, when all tokens have arrived. In the second and third picture of figure 26, only one and two tokens have arrived at the merging point. The gateway waits for the arrival of the third and last token. Only then it will consume these three tokens, emitting a new token.

Figure 26: Inclusive gateway – all three paths selected

But if only one or two sequence flows are selected at the split, a parallel gateway would lead to a blockade at the merging point, because it only switches when all three tokens have arrived. This, however, will never be the case, because only one or two tokens have been launched.

Figure 27: Inclusive gateway – two out of three paths selected

Figure 27 shows a case in which two sequence flows have been selected. Here, the inclusive gateway switches when both tokens have arrived. Thus, the inclusive gateway does always know how many and which sequence flows have been selected. So it knows which tokens are to be expected before it can finally launch its token.

The example in figure 28 is slightly different. Here, one of the sequence flows from the splitting inclusive gateway leads to an end event. Consequently, the token in question does not arrive at the merging gateway. This model is correct, anyway. A merging inclusive gateway is waiting for all tokens that belong together and might reach it. Since one token in the top branch is absorbed by the end event, and thus cannot reach the merging point, the merging inclusive gateway will not wait for it.

Figure 28: Not all tokens can arrive at the merging inclusive gateway

If only information is requested in the inquiry, it will be sent and the process is finished. If an offer or personal advice or both are requested, the respective activity is carried out, and the merging inclusive gateway waits for the one or two tokens. If in parallel to the offer and/or personal advice, additional information is requested, the merge will remain unchanged. Since there is no path between information request and the merging point, the gateway is only waiting for the one or two tokens of the paths below.

As in the exclusive gateway, outgoing sequence flows of the splitting inclusive gateway are provided with conditions. In contrast to exclusive gateways not exactly one condition must apply, but at least one. Two or more conditions can also apply at the same time.

Therefore, an inclusive gateway can, in principle, also be used for the merging of sequence flows originating from splitting exclusive or parallel gateways. But this is not a good modeling style. For alternative or parallel sequence flows the respective gateway should be used.

It is possible to use an inclusive gateway for merging sequence flows that were created by a combination of various gateways. Of course, the combination of exclusive and parallel gateways in figure 29 can also be used in reverse order for merging. The usage of an inclusive gateway makes the presentation slightly more compact. The preferred variant depends on the modeling style.

Figure 29: Inclusive gateway for merging sequence flows from a combination of gateways

As in the exclusive gateway, the inclusive gateway’s exit can also be marked with a small diagonal slash as default sequence flow (cf. figure 30). It will be selected automatically, if no condition of the other sequence flows is true. This ensures the actual selection of at least one sequence flow.

In contrast to the other sequence flows, the default sequence flow can not be selected in combination with other sequence flows, because the default is only being selected, if none of the other conditions applies. Thus, in figure 30 either any single sequence flow can be selected, or the two sequence flows above are selected. But it is not possible to select the sequence flow on the bottom in combination with one or two sequence flows on top. This logic is appropriate to the matter displayed. Either the job application is complete. Then the applicant will be invited. Or certificates, missing information, or both have to be requested. If something has to be requested, the applicant will not be invited at the same time.

Figure 30: Default sequence flow at an inclusive gateway

Figure 31: Modeling without default sequence flow

This example could also have been modeled without a default sequence flow, but with a preceding exclusive gateway, as in figure 31. This kind of presentation, however, is more complex and thus more difficult to understand. Furthermore, the modeled decisions surely do not correspond to the decision succession in practice. It is not reasonable to decide first, whether the application is complete (one had to prove that neither certificates, nor important information are missing), and in case it is not complete, to decide again which of the two contents are missing. Instead, it would be reasonable to take only one decision, as descriptively shown in figure 30 by means of a default sequence flow.

3.5   Complex Gateway

In figure 32, the sequence flow of an application process is split into three parallel flows by a parallel gateway. A reference for the applicant is requested in each of the three branches, two references of different employers, and one of a university professor. In fact, only two references are required. But, just to be on the safe side, three references are asked for because the receipt of an answer sometimes takes a little bit longer. As soon as two references have arrived, the process is continued. The last incoming reference will be ignored, which means the respective token will be consumed without passing another token.

Such a complex logic can not be reasonably depicted by the gateways presented above. Therefore, a complex gateway with a star symbol is used. A complex gateway may comprise any arbitrary rules for processing the arriving tokens. In figure 32, the applied rule is represented in the form of an annotation. If software tools are used for modeling, such rules are quite often also stored in an attribute of the complex gateway. Complex gateways can not only be used for merging, but also for splitting sequence flows.

Figure 32: Merging complex gateway

In general, complex gateways play a relatively small role among the BPMN elements. But for very complex sequence flow rules, complex gateways might be quite helpful. A comprehensibly phrased complex gateway improves the model’s readability and should be preferred to a complicated combination of a number of gateways.

4   Splitting and Merging without Gateways

Each of the activities in the examples above had exactly one incoming and one outgoing sequence flow. Splitting and merging of sequence flows was performed by gateways. But it is quite often possible to lead several sequence flows directly into an activity, or to lead several sequence flows out of an activity. This enables the gateways to be replaced, leading to a concise representation.

4.1   Splitting without Gateways

Figure 33 shows two possibilities of modeling an inclusive split: On top, the already known representation with an inclusive gateway; in the presentation below, the preceding activity itself has got various exits. The sequence flows leaving the activity “Select Media for Job Posting” are so-called “conditional sequence flows”. They are marked with small condition diamonds at the beginning, which means that they must be provided with conditions. The completion of an activity activates those sequence flows that have true conditions.

Since several conditions can be true at the same time, several sequence flows can be activated simultaneously. The modeler has to express the condition in such a way, that at least one condition applies. Thus, the logic is exactly the same as in an inclusive gateway.

Figure 33: Inclusive decision with gateway and without gateway

Condition diamonds are only placed at an activity’s exit. If an inclusive gateway is used, the exits are automatically conditional sequence flows, thus making a further marking unnecessary.

An exclusive splitting gateway can be represented in the same way by conditional sequence flows leading out of an activity. Figure 34 shows the same exclusive split with and without a gateway. The difference to an inclusive split is that the conditions must be defined in such a way that always exactly one condition is true.

Figure 34: Exclusive decision with gateway and without gateway

In the second case, however, the modeler is not restricted to using mutually exclusive conditions – other than in the first case with the exclusive gateway. In the upper part of figure 34, a change of the second condition “Up to 500km” into “Up to 600km” would be a modeling mistake, because both conditions would apply for distances between 500 and 600 kilometers, so that the two sequence flows would not be exclusive any more.

This would be absolutely correct in the second case of figure 34, where the exclusive split would become an inclusive one. In the end, conditional sequence flows after activities always represent the logic of inclusive gateways. Inclusive gateways may also have mutually exclusive conditions, thus creating exclusive splits. In this case, however, the split’s exclusiveness in the model can not be recognized so clearly, because the conditions have to be analyzed, first. The graphic model would lose in expressiveness; modeling faults would be easily overlooked. This also applies to the modeling with conditional sequence flows, because the very equivalent to exclusive gateways does not exist.

Figure 35: Default sequence flow at a gateway and at an activity

When activities are followed by conditional sequence flows, one of the sequence flows can be marked as default flow. It will be chosen automatically, if no condition of the other sequence flows applies (cf. figure 35).

If two or more normal sequence flows without condition diamonds are leaving an activity, they will all be activated as soon as the activity has been finished, thus generating a token for each exit. Therefore, it is equivalent to the usage of parallel gateways. Figure 36 shows the same parallel split with and without a gateway.

Normal and conditional sequence flows can also leave an activity together. Then, each sequence flow without condition diamond generates a token – the others only if their conditions are true. In this case, however, none of the exits should be marked as default flow, because it would never be selected, since there are other exits that always generate a token.

Figure 36: Parallel split with gateway and without gateway

4.2   Merging without Gateways

Merging alternative paths can also be modeled wihout gateways. In the bottom picture of figure 37, the splitting as well as the merging exclusive gateways have been replaced. In this case, the alternative sequence flows directly go into the next activity. Each single token arriving at an activity, via any entry, will be directly processed by this activity. The activity will not wait for any other tokens, and the tokens will not be merged. This behavior is appropriate for merging exclusive sequence flows where only one token can arrive.

Figure 37: Merging exclusive paths with gateway and without gateway

Of course, splits and merges with and without gateways can be combined with each other. It is possible, for example, to have several conditional sequence flows leaving an activity, and to merge them later on with an exclusive gateway (cf. figure 38, top). It must be taken care, that the conditions of the conditional sequence flows are mutually exclusive, so that actually only one token can arrive at the exclusive gateway. In the same way, sequence flows originating from a splitting exclusive gateway can be merged without a gateway (cf. figure 38, bottom).

Figure 38: Combinations of splits and merges with gateway and without gateway

The joining of non-exclusive paths, however, cannot be modeled without a gateway. The model in figure 39 is not correct. When the activity “Write Job Posting” is finished, it emits two related tokens, one to each of the outgoing sequence flows.

Figure 39: Non-exclusive paths cannot be merged without a gateway

The incoming sequence flows of the activity “Select Applicant”, on the other hand, behave as described above: Each time a token arrives, the activity “Select Applicant” is carried out. Thus, this activity is performed twice: Once for the token from the upper sequence flow, and once for the token from the lower sequence flow.

The resulting behavior is shown in figure 40. Here, the models at the top and at the bottom represent the same thing: The activity “Select Applicant” will be performed twice – when the activity “Publish Job Posting Internally” is finished, and when the parallel actvitiy “Publish Job Posting Externally” is finished. Thus, this model does not correspond to a merging parallel or inclusive gateway. Such a gateway would wait for both related tokens and join them into a single token, so that the following activity “Select Applicant” would be performed only once.

Figure 40: If several non-exclusive paths end in one activity, this activity is carried out several times

In special cases, the behavior according to figure 40 may be desired. In this case, the model at the top may be chosen as a simple representation. Here, each token flows independently to the end event. Other than in the model at the bottom, it would not be possible to rejoin the two related tokens again. Therefore, there will not be many cases for applying this model structure.

At a normal join of parallel paths, the different tokens are rejoined into one token. Regardless whether the parallel paths have been created by a parallel gateway or by multiple exits of an activity, they must be joined by a parallel or an inclusive gateway (cf. figure 41). For easier comprehension, the parallel gateway should be preferred, because it clearly indicates that each gateway entrance must receive a token.

Figure 41: Correct merging of non-exclusive paths

Non-exclusive paths can also be created by inclusive splits. These can be modeled not only with splitting inclusive gateways, but also with an activity and several outgoing conditional sequence flows, if the conditions are not mutually exclusive.

The inclusive paths in figure 42 cannot be merged without a gateway (unless multiple activations of the following activity are desired, as described above). Here again, more than one token can arrive. In this case, only a merging inclusive gateway can be used.

The behavior of multiple sequence flows going into an activity is not symmetrical to that of multiple sequence flows coming out of an activity. Multiple outgoing sequence flows without conditions form parallel paths, several related tokens are emitted (figure 43, left). This corresponds to a parallel gateway. However, multiple incoming sequence flows must be exclusive, i.e. only one token must arrive. This corresponds to an exclusive gateway.

Figure 42: The merging of inclusive paths requires an inclusive gateway

Figure 43: Multipe exits from one activity define parallel paths; multiple incoming flows are used for merging exclusive paths

This asymmetry is not intuitive; the model in figure 39 looks rather plausible for anyone who is not a BPMN expert. The different meanings of the split and the merge need to be considered in order to avoid modeling mistakes.

4.3   Modeling with or without Gateways?

Since there are two ways for modeling splits and merges, a modeler must decide which style to use: with or without gateways?

It is not possible to model entirely without gateways. On the hand, non-exlusive paths usually need to be joined by gateways. On the other hand, a gateway is also required if a split directly follows another gateway or an event. Merging exclusive paths also require a gateway, if another gateway or an event follows (cf. figure 44). A gateway with several inputs and several outputs at the same time may cause misunderstandings and should therefore be avoided.

If gateways are omitted as far as possible, more compact and smaller models can be created. For some cases, the modeling of splits with an activity and conditional sequence flows may also be considered as a more natural way of modeling. If a decision is made in the activity, such as in figure 45, it seems obvious to lead the different paths directly out of the activity. If the split is modeled with a gateway, it is optically separated from the deciding activity. In this case, the deciding activity provides a result, which will be evaluated afterwards for selecting one or more sequence flows.

Figure 44: When branching after or merging before an event or another gateway, it is not possible to omit the gateway

Figure 45: Different possibilities of modeling decisions

In the case of an automated process, the process engine calls a function. It receives back a value from that function, and then it selects the correct sequence flow. Here, the separation of activity and split is suitable, because the process engine is a controlling unit which executes the process logic independently from the called functions. If no process engine is used, however, the deciding activity often is closely connected with the process control. The activity may directly trigger the following activity, or the decider forwards the process documents to different persons, based on the result of his decision.

If the purpose of the preceding activity is not to make a decision, but to calculate a price, for example, a gateway is more suitable. The activity provides a result (e.g. a price). The following gateway can then select a sequence flow based on that price. The conditions (e.g. exceeding a certain amount) are entirely independent of the previous activity (cf. figure 46). After a decision activity, on the other hand, the conditions at the outgoing sequence flows usually correspond to the possible results of the decision (e.g. “approval” or “rejection”).

Figure 46: The activity “Calculate Price” provides a result which is then evaluated at the gateway

The distinction between deciding activities and other activities is purely based on the modeled content, and it can be discussed whether it is useful. BPMN does not make such a distinction. It is a matter of the modeling style whether to make that distinction and model the splits in different ways or not. If required, it can be specified in a modeling convention.

Since it is not possible to omit gateways completely, there are often asymmetrical model structures when modeling splits and merges directly at the activitites. Especially non-exclusive paths must always be merged with a gateway, as it is shown in figure 41. Sometimes, exclusive splits also must be modeled with a gateway, e.g., when the split directly follows an event or another gateway (cf. figure 47).

Figure 47: Decision and merge in a symmetrical way, both without gateway (top). In the second case, this is not possible since the decision is preceded by another gateway instead of another activity.

The corresponding splits and merges are easier to detect if the same gateway types are used symmetrically. Especially in more complex cases with several combined gateways, the symmetrical use of gateways helps understanding the flow logic (cf. figures 48 and 49).

Moreover, the different gateway types are more expressive. If an exclusive gateway is used, it is clear that in every case exactly one sequence flow will be selected. If the conditions at the sequence flows are not mutually exclusive, this is a clear modeling mistake. It is also a mistake if there are cases in which no condition becomes true.

Figure 48: A more complex example in which gateways have been omitted as far as possible

Figure 49: It is easier to understand the logic of the sequence flow, if the gateways are used in a symmetrical way

If an exclusive split is modeled with conditional sequence flows after an activity, it is hard to recognize that always exactly one path is being selected. It can only be detected by analyzing the conditions at each sequence flow. If the modeler made a mistake and created conditions which are not exclusive in every case, this semantic mistake is harder to detect, because there is no violation of the BPMN rules.

The model on the right side of figure 50 obviously contains a mistake: For children between 12 and 14 years, both conditions are true. This is not allowed for an exclusive gateway. In the case shown on the left, this is not forbidden, so this model is formally correct. The modeled content, of course, still does not make sense.

Figure 50: More expressive modeling with a gateway: In the right model, the use of overlapping conditions is a modeling mistake

In the end, every modeler has to decide how to handle the different possibilities for modeling splits and merges. Modeling conventions should be used for achieving a uniform modeling style in a project or an enterprise.

5   Collaborations

Other than most graphical process notations, BPMN provides special means for modeling collaborations. A collaboration is the synchronized interaction of two or more processes without a central control. The processes communicate by exchanging messages.

Such an interaction is also called “choreography”. In version 2.0 of BPMN, a new diagram type was introduced, the “choreography diagram”. Such diagrams also show the interaction of several partners, but in a different way. In order to distinguish the different ways of presenting interactions, the modeling style introduced in this chapter will always be referred to as “collaboration”. Choreography diagrams will be presented in chapter 11.

Collaboration diagrams are especially useful for documenting the co-operation of several companies. The purchasing process of a customer and the order fulfillment process of a supplier are two independent processes. However, they are connected. In the purchasing process, an order is sent which triggers the supplier’s order fulfillment process. Then this process sends an order confirmation as a reply, etc.

Collaborations are modeled with two or more pools. Each pool contains a separate process. Between the processes, message flows are modeled. A pool does not need to represent a company, but it can also stand for a computer program or a technical system, for example. Therefore, not all collaborations represent interactions between enterprises. It is also possible to model something like a collaboration in which several independent computer programs exchange data.

5.1   Example of a Collaboration

Figure 51 shows an example of a model with a collaboration. It presents the interaction of an applicant and an enterprise in the process of a job application.

Separate pools are used for applicant and enterprise. By this, it is expressed that both participants of the collaboration are independent of each other. The applicant cannot influence the enterprise’s way of processing a job application, nor can the enterprise determine what the applicant does concerning the application. And, of course, there is no central authority that would define and control the entire process that spans the two participants.

Figure 51: Example of a collaboration diagram

Therefore, each pool contains a complete process with a start event and an end event, with actitivities and the sequence flow. However, the two processes are not entirely independent, because messages are interchanged. As a part of the activity “Write Job Application”, the applicant sends a message to the enterprise, containing his application. The enterprise takes this message in the activity “Receive Application”. The following activity “Confirm Receipt” sends a message with a confirmation of receipt to the applicant.

On the applicant’s side, the writing of an application is followed by the activity “Receive Confirmation of Receipt”. This activity has an incoming message flow, i.e. it can only be completed when the message with the confirmation has been received.

As long as no confirmation of receipt has arrived, the applicant’s process does not continue. This behavior is unfavorable, because it may happen that an invitation to an interview arrives without a prior confirmation of receipt. The process cannot react to that invitation, because it still waits for the confirmation of receipt. A better process would handle this possibility correctly, and also other alternatives, such as a rejection by the enterprise, would be considered. These cases have not been included in figure 51, in order to keep the model simple.

In the job posting process in chapter 2, the pool was labelled with the name of the process (figure 1 on p. 16). In figure 51, the labels do not contain the process names, but the partners’ roles. This is typical for collaboration diagrams. In this example, both partners, applicant and enterprise, are displayed in the same way. The diagram could have been created both from the applicant’s perspective and from the enterprise’s perspective.

In practice, collaboration diagrams are often created by only one of the partners. In this case, the own pool can be labelled with the name of the process. The other pools are labelled with the partners’ roles. In that way it is clear which process is shown in the model, and also which partners are involved. If the above collaboration diagram is created by the enterprise, it may label its own pool with the process name “Recruit Employee” (figure 52).

Figure 52: The company’s own pool (bottom) is labeled with the name of the process

Often, the own process is contained in an implicit pool which is not displayed in the diagram (cf. figure 53). A collaboration diagram may contain not more than one implicit pool.

5.2   Modeling Message Flows

A message flow can represent any kind of information exchange, for example a phone call or the sending of an e-mail, a fax, or a letter. Messages can also be connected to physical objects, e.g. a delivery of goods can be modeled as a message flow in a collaboration. Of course, every kind of electronic data exchange can be shown as message flow, such as downloading a file or the call of another system’s function, e.g. via a web service.

Figure 53: The company’s own process is contained in an implicit pool which is not shown

In contrast to the solid lines of the sequence flows, message flows are drawn with dashed lines. The start is marked with a little circle, the inside of the arrowhead is blank. In BPMN, message flows are only used for the communication of independent processes, which are in different pools. Thus, message flows are only allowed between different pools, but not within one pool (figure 54).

Figure 54: Message flows are only allowed between pools, not within a pool

Sequence flows, on the other hand are used for modeling the flow of an independent process within one pool. Therefore, sequence flows must not cross borders of pools (figure 55).

Lanes are subdivisions of pools. From the perspective of the BPMN specification, lanes rather provide supplementary information to a model, i.e. they do not influence the logic of the sequence flow. Therefore, sequence flows can cross the borders between lanes. Message flows between different lanes within the same pool are not allowed, because start and end of a message flow must be in different pools (figure 56).

Figure 55: Sequence flows are only allowed within a pool, not between pools

Figure 56: Sequence flows can cross the borders of lanes within a pool. The message flow on the right is still within one pool.

Correct message flows, i.e. message flows between different pools, can cross the borders between lanes without any problems. Examples are shown in figure 57.

Figure 57: Message flows can cross the borders of lanes, but they must end in another pool

5.3   Message Flows to Pools without Displayed Processes

The collaboration in figure 51 shows the internal processes of both partners involved. In many cases, however, only the internal processes of the own enterprise are known, but not a partner’s processes. Only the messages are known which have to be exchanged with that partner during the process.

In such a case, this partner’s pool is drawn without the process. The message flows then simply start and end at the borders of the pool (figure 58).

If only the exchanged messages and their order are relevant, both pools can be drawn without their processes, as in figure 59. In that way, the exchange protocol of the collaboration can be documented. The partners need to agree on the content of this protocol, so that the entire scenario will work. In this model, both pools are labeled with the names of the partners, since in contrast to figure 58 this model does not represent the specific view of one partner.

Figure 58: Message flow to a pool without modeling its internal details

If an applicant asks the enterprise how a job application is handled, the content of figure 59 will be explained to him: First he needs to send an application, then he gets a confirmation of receipt, etc. Thus, the message exchange protocol of the job application process represents the enterprise’s interface to the applicant.

However, in that way no complex dependencies can be modeled regarding message exchange. It is not possible to model, for example, that after the confirmation of receipt, the applicant will either receive and invitation or a rejection. Nor can the fact be expressed that the questions and answers of the interview will only be exchanged after an invitation has been sent. Such dependencies can be modeled in choreography diagrams (cf. chapter 11).

Figure 59: A model containing only message flows

Figure 60: Example of a private process

5.4   Private and Public Processes

In collaborations it often makes sense not only to provide the partner with a black box representation of the own process, but to disclose the process details as far as it is necessary for the co-operation. Thus, the partner can view the process and, for example, realize that a certain message is only sent under certain conditions.

A process may contain details which are not relevant for the partner, or which the company wants to keep secret. This can be achieved by providing a simplified view of the process to the partner. Such a simplified external view is also called “public process”. Consequently, an internal process with all its details is called “private process”.

Figure 60 shows an example of a private process. It presents in detail, how an advertising agency produces an advertisement, and which messages it exchanges in doing so. This process contains a number of activities and loops which are not interesting for the customer, such as archiving, reviewing, and reworking.

The exchanged messages, on the other hand, are interesting for the customer. However, if the model contained only the pure message exchange without the process, the customer would not see, that after the feedback to the proof, another proof may be sent, for which a feedback is required again, etc.

The public process in figure 61 does not present the details that are irrelevant for the customer. It only contains those activities that influence the collaboration. It is therefore the customer’s view of the process from figure 60.

There are no defined rules for creating a public process out of a private process, or vice versa. It is only required that the external behavior concerning the message exchange must be the same.

Figure 61: The public process related to the private process of figure 60

Typical actions during the transition from a private process to a public process include the combination of several elements into aggregated activities, as well as the removal of elements not required. In the above example, several elements have been removed from the public process: The two parallel loops for ensuring the quality of the text and the layout, as well as the activity “Archive Advertisement”.

According to the BPMN 2.0 specification, an extended process “supports” a simpler process, if the entire process logic of the simple process is completely contained in the extended process. In this case, the simple (i.e. the supported) process can be replaced without any problems by the extended (i.e. the supporting) one. This is also true for private and public processes. The private process from figure 60 can be used instead of the public process from figure 61 without changing the externally visible process logic. With regard to content, of course, there is a difference, because the resulting advertisement will be different, e.g. when the text is proof-read and corrected.

5.5   Multi-Instance Participants

In the previous examples, every pool represented exactly one participant. How can the interaction with a group of partners be modeled? If a company sends an inquiry to ten suppliers, it would be rather laborious to model ten pools. What is more, the exact number of partners is different in every process instance, and not yet known at modeling time.

In the example for hiring an employee (figure 51), the interaction of the enterprise with only one applicant was modeled. In practice there are usually several applicants, one of whom is selected. Therefore, in figure 62 the applicant’s pool is marked with three lines as multi-instance participant. It stands for a group of applicants.

The messages are exchanged with each individual participant. For this, two loops have been included into the enterprise’s process. In each cycle, the messages are exchanged with another applicant – until there is no applicant left. Each applicant’s process is the same, shown in the pool on top.

Figure 62: Collaboration with multi-instance participant

Some interesting steps from the original hiring process are missing in the presented collaboration, especially the sending of the contract to the selected applicant. Consequently, the other applicants receive a rejection. The applicant’s process then needs to react differently to different message flows. Either the signed contract is sent back, or the process is finished without further activities. Suitable modeling constructs for such a case are presented in the following chapter.

As shown in figure 63, the pool of a multi-instance participant can also be drawn as a black box.

Figure 63: Multi-instance participants with black box pool

5.6   Use of Collaborations and Sequence Flows

It is obvious that collaboration diagrams are useful for modeling the interactions of several companies. However, pools need not necessarily represent companies. Instead they can also stand for divisions or technical systems. A process that spans several units is usually modeled in one pool with several lanes, but it is also possible to model it with several pools. Each division then has its own pool, and the divsions’ processes use message flows for communicating.

In which cases should a modeler use several distinct pools and message flows? Which cases, on the other hand, are better represented by a single pool with several lanes?

The deciding criterion for using a pool is, whether the process is defined or controlled entirely within that pool. For a process that is excecuted by a process engine of a workflow or business process management system, this is easy to decide. The sequence that is controlled by the process engine should be within one pool. If the process interacts with another, separately controlled process, this other process is in another pool. The communication between them is modeled with message flows. Everything that is inside one pool is controlled by the process engine as a central unit. Several different processes within one process engine are also shown in separate pools, if during execution they run in the form of separately controlled process instances which only communicate by exchanging data.

A process which is not – or only partially – executed by a process engine usually does not have such a central unit that controls every step in the process. However, for such a process it is still possible to identify a surroundig entity which provides a scope for defining and controlling the process, typically an enterprise or an organizational unit.

If a company defines processes that span several divisions, it is suitable to use one company pool with a lane for each division. On the other hand, there may be companies in which all divisions define their own independent processes, and they only agree on the information to be exchanged. In this case, it is also possible to model separate pools for the divisions, connected via message flows. However, this is inconsistent with the process management idea, according to which entire end-to-end processes should be analyzed and improved, rather than small processes within single divisions. If unchangeable interfaces between divisions are defined at the beginning, process improvements across divisional borders are almost completely prevented.

Within inter-company processes, usually each participating company retains the sovereignty of its own internal process. Therefore, using a collaboration diagram seems obvious.

On the other hand, there are also cases in which it makes sense to model an intercompany process completely with sequence flows inside one pool. In such a case, the pool represents the network of co-operating partners. This is reasonable when there is a very close co-operation, and the partners define the entire processes together. Examples for such close co-operations are the integration of suppliers in the automotive industry, enterprise consortia, and virtual enterprises. Since the partners work together in creating the process, they have joint process sovereignty.

If the partners define their processes independently of each other, this may lead to the following situation. A supplier performs a quality control before shipping goods. When the customer receives the goods, he performs a quality control for the same goods again. If only the collaboration and each partner’s individual process is analyzed, it cannot be detected that the same activity is performed twice. If the partners agree to jointly optimize the entire process, a model with one pool and sequence flows clearly shows the duplicate work. In the optimized process, only one partner performs the quality control. This, of course, is only possible if the customer can rely on the supplier.

In a second step, the partial processes of each partner need to be detailed and supported by information systems. For this step, modeling different pools and message flows may be appropriate again.

So there is no general answer to the question whether to use one pool with sequence flows, or several pools with message flows. For different situations and modeling purposes, this question will be answered differently.

5.7   Modeling of Message Content

Message flows, of course, carry content, such as documents, data sets or even physical objects. In the previous examples, the type of message content was indicated by the names of the message flows. However, BPMN distinguishes between the message flow and the message itself, i.e. the transmitted content. For business-oriented models, this differentiation is not that significant. For executable models, however, it may be important. The message flow involves the transmission and the receipt of defined messages. The message itself may contain a data structure, or the like, which may be stored or provided to a service.

Messages are displayed as envelope symbols. These can be placed right on the message flow, or they can be connected to the message flow by a dotted association (figure 64). There are blank envelope symbols, as well as shaded symbols. A shaded symbols usually stands for a message that is sent as an answer to a previous message. Blank symbols mark messages that initiate a message exchange. The benefit of these different colors becomes clear in the context of choreography diagrams (chapter 11). In a pure collaboration diagram, blank envelope symbols are sufficient. Alternatively, the message flows can be drawn entirely without envelopes. Modeling teams should decide for one style and use it consistently.

Figure 64: Use of envelope icons for message content

6   Events

An event is used to express that something has happened. It indicates a point in time. In contrast to an activity it therefore does not have any duration. When modeling an event, two aspects are considered: The cause or trigger of the event, and its effect in the process.

Examples of typical triggers for events:

•   A message arrives, e.g. an e-mail or a letter.

•   A certain point in time is reached.

Such an event and its effects are well-known to everyone whose alarm-clock rings at a preset time.

•   A certain time span ends.

As opposed to an absolute point in time, the relative time span after another event or after the end of a preceding activity is considered. As an example, a kitchen timer is preset to a certain baking time when a cake is put into the oven. The timer’s signal indicates the event “baking time completed”. It is followed by other activities for preparing the cake.

•   A condition becomes true.

Such a condition could be “the outdoor temperature is at least 30°C”. When reaching this temperature it may be necessary to activate an air conditioner. Another example is the specification of “stop loss” limits for stock accounts. In order to avoid significant losses, a certain minimum price can be defined for each stock. If the stock price falls below this limit, the bank automatically sells this stock.

•   An error occurs.

For example, the outage of a system may require certain process-steps in order to be restored. Sometimes, it is also necessary to find workarounds that enable important tasks to be performed without the system. Incoming orders may be temporarily recorded by hand. Later, when the outage is over, they are entered into the system.

Further examples of errors may result from incomplete or inconsistent data, or a message that cannot be delivered.

The examples in the previous chapters already contained start and end events. However, events can also play a role within a process. Then they are modeled as intermediate events. Figure 65 shows the symbols of different event types: The start event is represented by a circle with a single line. The intermediate event’s circle is drawn with two lines. In the end event’s symbol, the space between the two lines is filled so that it has a thick border.

Figure 65: Types of events: start, intermediate, end

If required, the presented basic symbols can be complemented with icons for different kinds of triggers, such as messages or timers.

6.1   Example for the Use of Events

In figure 67, the different usages of events are shown using the example of a job application. This collaboration will be explained in several steps. The fragment in figure 66 shows the beginning of the process with a start event. The trigger of this event is not determined further. As a rule, such a process is started by a process participant, in this case the applicant.

Figure 66: Start of the applicant’s process (fragment from figure 67)

After the activity “Write Job Application”, the intermediate event “Application sent” occurs. It is marked as a throwing message intermediate event, and it has an outgoing message flow “Application”. This event is followed by another event, the catching message intermediate event “Confirmation received” with an incoming message flow “Confirmation of Receipt”. This event only occurs when a confirmation of receipt actually has arrived. Until this moment, the process waits at this position, i.e. there is a token in front of the event. This token only moves on after the required message has been received.

Figure 67: Example for the use of events

What happens in this collaboration in the other partner’s pool, i.e. in the enterprise? As the detail in figure 68 shows, the entire process is triggered by a catching message start event. Every time an application is received, a new process instance is created. In this instance, the first step is to write a confirmation of receipt. The intermediate event “Confirmation sent” follows. The process continues without interruption, and the activity “Review Application” is performed.

Figure 68: Start of the enterprise’s process (fragment from figure 67)

Sending the message “Confirmation of Receipt” has a direct effect to the applicant’s process. In this process, the intermediate event “Confirmation received” has been waiting for this message. Now, the sequence flow in the applicant’s process can be continued.

Here, the model has a disadvantage: If the applicant does not receive a confirmation of receipt, his process cannot be continued. If the enterprise would change its process and send an invitation to an interview without a previous confirmation of receipt, the applicant’s process would not be able to handle it.

The second part of the enterprise’s process is shown in figure 69. After “Review Application”, the flow is split by an exclusive gateway. If the applicant is not suitable, the process finishes at the end event “Rejection sent”. This is a throwing message event. Thus, when the process is finished, the message “Rejection” is sent.

Figure 69: Second part of the enterprise’s process (fragment from figure 67)

If the applicant is interesting, however, he is invited to an interview. The message flow with the invitation triggers the intermediate event “Invitation sent”. It is followed by the catching message intermediate event “Date confirmation received”. Here, the process waits for a message.

At the next intermediate event, the timer event “Time for interview”, the process waits again, until that time is reached. Then the activity “Carry out Interview” is performed. At this point, the process ends at an untyped end event. Unlike the event “Rejection sent”, it only indicates the end of the process and does not send a message.

Since there is an exclusive gateway in figure 69, the enterprise either sends an invitation or a rejection. The applicant’s process must react to these two alternatives. In the process fragment shown in figure 70, an event-based exclusive gateway is used for this.

Figure 70: Second part of the applicant’s process (fragment from figure 67)

At such a gateway, the intermediate event that occurs first, determines the path to take. If a rejection is received first, the lower path is selected, and the process finishes at an untyped end event. But if an invitation is received, the first event to occur is “Invitation received”, and the upper path is selected. In this path, the interview date is confirmed which results in the throwing message intermediate event “Date confirmation sent”. Then the applicant waits until it is time for the interview – just like the enterprise in its process. Finally, he takes part in the interview, and the process finishes at an untyped end event.

6.2   Start Events

The most common start event is probably the untyped event (without an icon in the circle). For this event type, the trigger is not exactly known, or it is not important. Often it can also be concluded from the context. The above described job application process is most likely triggered by the applicant.

A start event is quite often triggered from the outside of the process. Workflow management systems usually display a list of processes which can be started by a user, depending on the user’s role and rights. He selects the desired process from that list and starts it. By this, the start event is triggered within the process.

A process can also be a sub-process of another process (cf. chapter 7.1). As soon as the parent process activates the sub-process, the start event of the sub-process is automatically triggered.

Besides the untyped start event, especially timer start events and catching message start events are used in many BPMN models. When the registration deadline for a conference is reached, the conference organizers may start a process with further planning activities (figure 71, center). The processing of an order, on the other hand, is started when an order has been received (figure 71, right).

Figure 71: Types of start event triggers: None, timer, message

Figure 72 shows additional types of start events which are less frequently used. The conditional event (top, left) starts a process when the related condition becomes true. For example, a process for providing additional resources (e.g. employees or computing capacity) may be started when the utilization of the current resources exceeds 90%.

The start event at the top right is triggered by the reception of a signal. In contrast to a message which is always sent to a specific receiver, a signal is broadcasted everywhere. The signal for starting a process may originate from the same pool, or from a different pool and another process. Such a signal could be sent for announcing that a certain computer system is not avaible (“Online-system down”). This might require a reaction of several processes to this signal. In the example shown above, a process is started for manually processing the data.

Figure 72: Further triggers for start events. Top: Conditional, signal. Bottom: Multiple, parallel multiple

Finally, there are two symbols for start events with multiple triggers (figure 72, bottom). The multiple event is marked with a hexagon. It combines several events. If one of them occurs, the process is started. In the shown example, a cleaning activity is started when either the cleaning interval has been reached, or a contamination has been detected. In contrast to this, in a parallel multiple event, all of the combined events must have occurred. A take-off procedure can only be started as soon as the permission has been given and the engines have been checked. As long as only one of these two events has occurred, the process will wait for the second event, before commencing.

On the other hand, it is also possible to model several start events separately. In this case, the process is triggered when one of this events occur. The process in figure 73 starts when a request for a report is received, but also at the end of the month. If it is started by a request for a report, an individual reporting period is set, before a report is created. At the end of the month, however, the report is immediately created. Should both events happen to occur at the same time, still two independent process instances would be started.

Figure 73: Several start events

In this case it would not be possible to use a multiple start event instead of the two explicitly modeled events, because the activity “Set Individual Reporting Period” is only performed when the process is started by one specific event. If both events would be followed directly by the gateway, instead, they could be replaced by a multiple start event, and the gateway would not be required.

If a process has several start events, not more than one of them should be an untyped event, i.e. a circle without an icon. If a process is started from the outside, e.g. by a process engine or a participant, the process starts at its untyped start event. If there are several of them, it is not clear, at which of these untyped start events the process should commence.

Figure 74: An untyped start event and a message start event as alternative triggers of a process

If there are several start events with a defined type (e.g. timer or message), it can always be determined which of them has occurred, and hence it is clear where the process starts.

If a process has both an untyped start event and one or more start events with specific types, it will be started at the untyped event, if the process is triggered from outside. Alternatively, the occurrence of one of the other events (such as an incoming message) can also cause the start of the process. The process in figure 74 may be started from the outside, e.g. by a user which selects and activates the process in a workflow system. In this case, the process starts with the untyped start event, and the first activity is “Enter Order Manually”. However, the process can also be started by the reception of an electronic order, and thus by the catching message start event.

It could be imagined to use several untyped start events and to distinguish them by different names. However, BPMN does not specify any means for selecting an untyped event based on its name. Such a feature could be useful for connecting processes: A named end event of one process could automatically trigger another process’s start event with the same name. Although such a connection via event names is not explicitly mentioned in the specification, there are examples of corresponding catching and throwing events which can easily be identified by a common name. Since BPMN does not rule out the use of several untyped start events, an individual modeling convention could be defined for connecting end events and start events via their names. On the other hand, other BPMN modelers may interpret such models in a different way, and modeling tools may not support this modeling convention.

Figure 75: Connecting processes via start and end events with the same name

Figure 76: Use of an exclusive gateway as an alternative to figure 75

In figure 75, the process “Introduce into New Position” should be started when “Recruit Employee” is finished, but also when “Job Change” is finished. The first activity to be performed depends on the preceding process. The connection is indicated by the names of the start events. The start events are annotated with the names of the preceding processes, so that these can be found more easily.

It is not only possible to distinguish the different cases by using different untyped start events, but also by a single untyped start event, followed by an exlusive gateway (figure 76).

In both cases, the sequence of the processes must be modeled explicitly. They are connected as sub-processes in a higher-level process, as shown in figure 77. The plus sign means that there is a detailed process for this activity. Sub-processes are explained in chapter 7.

Sometimes it is suggested to connect processes via signal events or message flows. None of these solutions, however, is perfect. A signal is not only sent to a specific process, but it is broadcasted to all processes. This is not intended here, because only one subsequent process should be started. In this respect, a message flow should be preferred, because a message flow runs to one specific process. However, this would imply that the two processes are independent of each other, not being sub-processes of an overall end-to-end process.

Figure 77: A higher level process connecting the different processes

Figure 78: A process without start events

It is also possible to model processes entirely without start events. In this case, every activity without incoming sequence flow has an implicit start event.

When such a proces is started, all these activities with implicit start events are activated in parallel. In figure 78, at the beginning a computer and software are acquired in parallel. The two resulting tokens are joined together in the parallel gateway, before the computer is set up. The model fragment in figure 78 is therefore equivalent to the one in figure 79. Here, only one token is created by the explicit start event. This token is duplicated at the splitting parallel gateway, so that the activities “Acquire Computer” and “Acquire Software” are also performed in parallel.

Figure 79: The process from figure 78 with an explicit start event

Other elements which usually have an incoming sequence flow also contain an implicit start event, if the incoming sequence flow is missing. As an example, the splitting gateway in figure 80 contains such an implicit start event.

Figure 80: Gateways can also have implicit start events

A modeler must decide whether to use implicit or explicit start events. If there is at least one explicit start event in a process, there must not be any activites or gateways without incoming sequence flow. In most cases it is advisable to use explicit start event.

6.3   End Events

An end event is displayed with a thick border, as already mentioned. Besides the untyped end event, which simply removes an incoming token (figure 81, left), there are also special types for end events. In the center of figure 81 there is an end event that not only consumes an incoming token, but also sends a message.

Figure 81: Types of end event results: None, message, terminate

In contrast to the catching message start event, the envelope symbol of the throwing message end event is filled. This principle is also valid for other types of events: The symbols of throwing events are always filled, the corresponding catching events contain the same symbols, but they are blank.

The end event on the right is a terminate event. Like an untyped end event it deletes a token when it arrives. However, it not only deletes this single token, but it also terminates the entire process, i.e. any other tokens in the entire process are also removed at the same time.

The benefit of this event becomes clear when looking at a process with several end events. On the one hand, a process can have several exclusive end events. In figure 82, an application is either sent by post or by e-mail. Hence, only one of the two end events can be reached. If one of these end events has occurred, the entire process is finished, because there is not any remaining token left.

Figure 82: Several end events, only one of which will be reached in a single process instance

Figure 83: Several end events, which will all be reached in a single process instance

In figure 83, on the other hand, the two activities “Create Graphics” and “Write Text” are performed in parallel. The start event creates a token, and the parallel gateway duplicates it. Each of the two resulting tokens flows through one of the two parallel paths. Therefore, both end events occur. Each of them deletes one token.

Both activities do not necessarily run simultaneously, and they may have different durations. Thus, the two end events usually occur one after the other. If the end event “Graphics created” occurs first, it deletes one token. The process is not yet finished, since there is still the second token on its way. Only when the last token has been deleted, the entire process is finished.

In some cases, however, it is desired to terminate the entire process as soon as one end event is reached. An example can be found in figure 84. Here, again, the parallel gateway emits two tokens via the parallel sequence flows. The skills and experiences of a job applicant are checked, and his formal qualification is checked in parallel, too. If the results of both checks are positive, the two tokens flow through the exclusive gateways to the joining parallel gateway. Here they are joined together to one token which eventually reaches the untyped end event “Application accepted”.

If one of the checks has a negative result, the respective token flows through the other exit of the exclusive gateway to the end event “Application rejected”. Since it is a terminate event, the other token is also deleted, and the process is immediately finished.

Figure 84: A terminate end event immediately finishes the entire process

In the case of one negative result, the result of the other check is irrelevant, because the application will be rejected anyway. Thus, the process can be immediately terminated. If untyped end events would be used, the other token would still move on. If, for example, the skills and experiences are not sufficient, and the check of the formal qualification has not been carried out yet, this second activity will not even need to be started. This is achieved by the terminate event which deletes the second token, as well.

Replacing the terminate end events by untyped end events would cause a problem, if the result of one of the checks would be positive and the other negative. The token coming from the negative check would reach the end event “Application rejected”. The token from the positive check, on the other hand, would flow to the joining parallel gateway. Since the second token already has been deleted and cannot arrive anymore, the token would be stuck at the parallel gateway, and the process could not be finished. This problem is avoided by using terminate events.

Further types of end events are the throwing of a signal and the multiple end event (figure 85). As already mentioned, signals do not have a specific receiver, they can be received anywhere in the same process, as well as in other processes. In the presented example, the event sends the signal that a new software version has been released. Different processes can react to that signal, e.g. the sales process or a process for installing new software. For the software releasing process, however, it is not relevant which other processes need that information. Therefore, a signal is sent to everyone.

Figure 85: Further types of end event results: Signal and multiple

A multiple end event is used when the end of a process has several consequences. When the end event is reached, all the combined partial events occur. In the example, several messages are sent.

Just like start events, explicit end events can also be omitted. In this case, all activities, gateways, etc. without outgoing sequence flows have implicit end events. These have the same behavior as normal untyped end events. The models from figure 82 and 83 can also be modeled as in figure 86.

Figure 86: Activities without outgoing sequence flows have implicit end events

For implicit end events the same rule is valid as for implicit start events: A process may either have only implicit or only explicit end events. A mixture of both is not allowed. This applies also to start and end events: If there are explicit start events in a process, the end events must be explicit, as well. Accordingly, implicit start events require implicit end events, and vice versa.

In chapters 8 and 9, further types of end events will be introduced which are required for sub-processes and for modeling compensations and transactions.

6.4   Intermediate Events

An intermediate event can be used at any arbitrary position within a process. It has an incoming and an outgoing sequence flow. Its symbol is a circle with a double-line border.

Usually, intermediate events are only modeled when

1.   an event that is relevant to others is triggered within a process (e.g. a message or a signal is sent),

2.   there is a reaction to an event within a process (e.g. when a message is received or a certain point in time is reached).

Start events can only be “catching”, i.e. they can receive something or react to a trigger. End events, on the other hand, can only be “throwing”, i.e. they can send or trigger something. In contrast to this, intermediate events can either be catching or throwing events.

Figure 87 shows examples of a catching and of a throwing intermediate event. The throwing message intermediate event contains a filled envelope symbol. In this example, the intermediate event “Invitation sent” is triggered by the completion of the preceding activity “Write Invitation”. When this event occurs, the message “Invitation” is sent. At the same time, the sequence flow is continued, and the following activity “Prepare Meeting” is triggered.

Figure 87: Message intermediate events: Throwing (left) and catching (right)

It would also be possible to omit the intermediate event. The message flow would then originate directly from the activity “Write Invitation”. When the sending of the message is modeled as an event between the two activities, it becomes clear that the message is sent when the preceding activity is completed, rather than at an arbitrary point of time during the execution of “Write Invitation”.

The catching message intermediate event is represented by a blank envelope symbol (figure 87, right). It reacts to a message that arrives via the incoming message flow. When the activity “Book Invoice” is finished, a token flows to the intermediate event “Payment received”. Here it waits for the reception of the message “Payment”. As long as the payment is not received, the token remains at this position. The intermediate event only occurs when the payment arrives. Then the token flows on and triggers the activity “Book Payment”.

Of course, the received payment must be related to the invoice that has been sent by the same process instance. Since there are many instances of this process in parallel, many different invoices have been sent, and many payments are received. These payments need to be assigned to the related process instances. If this is done by a person, he will identify the correct invoice based on the invoice number that is referred to in the payment information.

If a process engine automatically assigns a received message to the related process instance, this is called “correlation”.

Figure 88 shows a timer intermediate event with a clock symbol. After a token arrives at such an event, it waits until a definite time. Typically it is not a previously determined absolute point in time, but the end of a certain time span. In figure 88, a cake is put into the oven. The activity “Take out Cake” starts after having waited for one hour.

Figure 88: Timer intermediate event

Figure 89: Conditional intermediate event

A condition becoming true can also trigger an intermediate event. In figure 89, first the oven is turned on. The process then waits until the temperature exceeds 180°C, before the cake is put into the oven.

Intermediate events can also send and receive signals. This is indicated by a filled triangle or a blank triangle, respectively. In the top process in figure 90, a throwing intermediate event signals that a new software version is available. After that, the process continues without interruption with the activity “Inventory New Version of Software”. In the process at the bottom, a defective software application is shut down. Then the process waits for the signal “New version of software available”. Only when this signal arrives, the activity “Download and Install New Version” can be carried out.

Figure 90: Signal intermediate event: Throwing (top) and catching (bottom)

Sometimes it is necessary to distribute a large model to several pages. In this case, it is helpful to use links to other pages. They enable the user to follow the sequence flow when it is continued on another page. Such off-page connectors are represented by “link” intermediate events. They are marked with arrows.

Figure 91 shows an outgoing link “B” at the end of a page. It refers to the incoming link of the same name on the next page. This means that a sequence flow runs from Activity X to Activity Y.

Figure 91: Link intermediate event connecting to another page

It is also possible to model a link to another position on the same page. This is especially useful for replacing a long sequence flow connection around many other model elements. The model becomes clearer when such a long connection is replaced by a throwing and a catching link event.

Figure 92: Normal loop

The backwards looping sequence flow from figure 92 can also be drawn as in figure 93. Here, the sequence flow is forwarded from the right, outgoing link “A” to the left, incoming link “A”.

Figure 93: Modeling a loop with incoming and outgoing link

Intermediate events can also be marked with a multiple symbol, if there are several alternative triggers or several consequences of the event. Again, there are catching and throwing events. The latter has a filled symbol (figure 94). The catching version of this event is used for modeling that a token needs to wait at this position until one of the partial events has occurred. At the throwing multiple intermediate event, all of the combined consequences occur at the same time, as it is already known from the throwing multiple end event.

Figure 94: Multiple intermediate event (catching and throwing)

Figure 95: Parallel multiple intermediate event

There is also a parallel multiple intermediate event (figure 95). In contrast to a normal multiple event, all combined events (e.g. the reception of several different messages) must have occurred, before a waiting token is moved on.

Finally, there is also the untyped version of the intermediate event, without a symbol inside the double-bordered circle. Other than start and end events, untyped intermediate events are rarely used. In principle it is possible to simply model that a certain state has been reached within a process. The event “Order entered” in figure 96 indicates that the order that is being processed has changed its state to “entered”. In this example, this information is rather trivial. What is more, the untyped intermediate event does neither have any effect on this process, nor on other processes. Therefore, this event is normally not modeled.

Figure 96: Untyped intermediate event

Occasionally, however, it does make sense to model such untyped events. Sometimes it is useful to analyze the different possible states of an object. This can be done with a UML statechart diagram, for example. With untyped intermediate events it can then be modeled where in a process each state is reached.

Figure 97: Untyped intermediate events used for denoting the entries of object states

Figure 97 contains the different states of a document. The events always indicate the entry into a new state. In contrast to an event without duration, a state lasts some time. A different way of representing states of data objects will be shown in chapter 10.

6.5   Event-Based Decisions

In chapter 3.1, exclusive gateways have been discussed. Such a gateway selects exactly one out of several sequence flows. The presented gateways are data-based gateways, i.e. the decision is made on the basis of provided data.

Figure 98 shows an example that has already been presented. Here, the value of a data element “distance” is used for evaluating the conditions at the sequence flows. If this value is greater than 500km, the upper path is selected, otherwise the bottom path. Such kinds of data are relevant for the control flow, but they need not to be modeled in BPMN (although modeling of data objects is possible, as shown in chapter 10). It is always assumed that within a process it is possible to access all data from everywhere.

Figure 98: Data-based decision

BPMN provides a second type of exclusive gateway, the event-based gateway. This gateway also selects one of several paths, but the decision is based on which event occurs. In figure 99, an invitation to an interview is sent first. At the gateway, one of the three outgoing sequence flows is selected. In each of these sequence flows, the next element is a catching intermediate event. The event that occurs first decides which path to take.

If a confirmation is received, the interview is prepared. If a rejection is received, the documents are sent back. If, however, 14 days have elapsed without one of the other two events occurring, the applicant is called and reminded. Only that event is considered that occurs first. If the event “Confirmation received” occurs within 14 days, the event “14 days elapsed” does not have any effect anymore.

In contrast to a data-based exclusive gateway, the exits of an event-based exclusive gateway have no conditions. Instead, the first element in each outgoing sequence flow must be a catching intermediate event. This is required for selecting a sequence flow.

Figure 99: Event-based decision

In the case of a catching message intermediate event, however, BPMN also provides another possibility. Since messages can also be received by activities, such an event can also be replaces by an activity. It must be an activity that does nothing else but receiving the message. Otherwise, if the message was received later during the activity, the activity would have to be triggered before it is known whether the related message arrives first. An activity that only receives a message is classified as a “receive” activity (cf. chapter 7.4). It is marked with an envelope symbol in the left upper corner. The model fragment from figure 99 thus can be modeled as in figure 100. However, the logic of the decision is more clearly visible if events are used.

Sequence flows which have been split by an event-based exclusive gateway can be merged by an ordinary exclusive gateway. At a split it does not matter whether the selection of a sequence flow was based on data or on events. It is only important that every time a token arrives only via exactly one sequence flow. In principle, the merge could also be expressed by an event-based exclusive gateway symbol, but the logic is exactly the same as that of a normal merging exclusive gateway.

In chapter 6.2 a process has been modeled that can be started in different ways. These were represented by several start events. Sometimes this is alternatively modeled as in

Figure 100: Event-based decision with message-receiving activities

Figure 101: Event-based gateway for starting a process

figure 101. Since the event-based gateway does not have an incoming sequence flow, it contains an implicit start event. Thus, the process starts and immediately waits for the first intermediate event. In fact, the process is started by the intermediate event. When using this kind of modeling, the use of several start events is avoided. Models with more than one start events may lead to misinterpretations. The meaning of the model in figure 101 is the same as in figure 73 (p. 64).

There is another alternative for starting a process: The event-based parallel gateway. Here, all events after the gateway must occur at the beginning. The first event causes a process instance to be created. After that, the process waits for the other events before it is continued. The same behavior can also be modeled with a parallel multiple start event. The model in figure 102 is therefore equivalent to the one in the lower right corner of figure 72 (p. 63).

Figure 102: Event-based parallel gateway for starting a process

7   Activities

7.1   Sub-Processes

BPMN models can contain two types of activities: Tasks and Sub-Processes. Tasks are not subdivided. Sub-processes, on the other hand, contain other detailed processes.

Figure 103: Process with sub-process “Review Application”

The process in figure 103 comprises the three tasks “Enter Application”, “Invite to Interview”, “Reject Application”, and the Sub-Process “Review Application”. The latter is marked with a little “+”-Symbol. The fact that “Enter Application” is a task does not mean that it cannot be further subdivided, but simply that this has not been done in this model.

Figure 104 shows the details of the sub-process “Review Application”. When in the parent process a token arrives at this activity, the sub-process’s start event is triggered, i.e. it creates a token. The token flows through the sub-process just like through any other normal process. At some point it reaches one of the two end events. By this, the sub-process is finished, and in the parent process, a token is emitted to the outgoing sequence flow.

Figure 104: Sub-process “Review Application”

In the parent process it does not matter which of the two events has been reached. It is only required that the sub-process has been finished completely before a token is passed on.

In the example, however, it is important with regard to contents which end event has been reached, because the following gateway distinguishes whether the result of the review has been positive or negative. However, according to the BPMN syntax there is no relation between the different end events within a sub-process and the conditions at the decision in the higher-level process.

These models rather have to be interpreted in the following way. The sub-process creates data which contain the review result. These data are then available in the parent process. They will be evaluated by the gateway conditions. As already mentioned it is always assumed that all data within a process are available everywhere. This is also true for embedded sub-processes.

The parent process in the example could have an attribute “result” which can receive the values “positive” or “negative”. The annotations in figure 105 describe for each activity which value is assigned to this attribute. The conditions at the gateway in figure 103 simply evaluate the attribute value for making the decision. The conditions at the gateways in the sub-process can also make use of the result attribute.

The proposed mechanism for transmitting a sub-process’s results to a parent process is independent from the end events. Therefore, the sub-process could also be modeled as in figure 106. Here, the token always reaches the only end event, and the review result is again passed by an attribute.

Figure 105: Storing the review result in an attribute

Figure 106: Alternative modeling of the sub-process

The structure of figure 104 however is more expressive and easier to understand – especially if cumbersome annotations should be avoided. Therefore it may be a good idea to specify in a modeling convention, that the reaction to different sub-process end events should be modeled as described above.

If the process is carried out manually, there is no process engine to manage an attribute “result”. The notification of the result is either done by an involved person, or it is noted on a form accompanying the process. The principle is not changed by this manual information transfer.

For a sub-process, it is also possible to have several end events, which are all reached via parallel paths. In this case, the sub-process is only finished when all tokens in the sub-process have been swallowed by end events.

If a sub-process is finished, one token will be emitted to each of the sub-process outgoing sequence flows. In the case of a conditional flow, a token will only be emitted if the conditions are true.

It should be taken care that a sub-process does not have more than one untyped start event. Otherwise it is not clear where the sub-process starts after having been triggered by the parent process.

Besides using separate diagrams for sub-processes it is also possible to insert the details of the sub-process directly into the model of the parent process. For this, the sub-process is positioned inside the enlarged activity symbol (figure 107).

Figure 107: Expanded representation of a sub-process within a model of the parent process

Some modeling tools also allow for expanding and collapsing a sub-process, so that the context of the entire process remains visible, and the details of a sub-process can be viewed when desired. The expanded view of sub-processes is only reasonable up to a certain model size. Otherwise the diagrams get too large and complex, and it is difficult to understand them.

Sub-processes can contain other sub-processes, so that hierarchical process models can be created, consisting of any number of levels.

Like top-level processes, sub-processes can also have implicit start events and end events (cf. chapters 6.2 and 6.3). In figure 108, all three tasks are activated in parallel when the sub-process is started. As soon as all three tasks are finished, the sub-process is also finished, and a token flows from the sub-process to the end event of the parent process.

Figure 108: Sub-process with implicit start and end events

It has already been explained that the start and end events of a process must all be either explicit or implicit. A combination of explicit and implicit events is not allowed. Since every sub-process is a process of its own, the usage of explicit or implicit events can be different to that of the parent process. Therefore, the diagram in figure 108 is correct. The parent process has only explicit start and end events; the sub-process has only implicit events.

In figure 108 the three tasks in the sub-process are executed in parallel. Therefore, the same logic could also be modeled with parallel gateways, as in figure 109.

It could be argued that the modeled contents in both figures have to be sligthtly different. Tasks 2, 3 and 4 are parts of a sub-process, i.e. they are on a more detailed modeling level. Therefore, it could be assumed that these tasks themselves are more detailed tasks than task 1. In the example with parallel gateways, all activities are on the same level and therefore they should have the same level of detail.

Figure 109: Modeling the process from figure 108 with parallel gateways

This argument is true, if sub-processes are used for creating model hierarchies – from a high-level overview model to very detailed process models. However, in BPMN sub-processes are not only used for this purpose, but also for grouping several activities within a loop (cf. chapter 7.2), or for creating a scope that can be interrupted as a whole (cf. chapters 8 and 9). In these cases, the activities in a sub-process have the same level of detail as the activities of the parent process. Therefore, the sub-process in figure 108 may only be a grouping of activities, which even may have been created for achieving a more compact diagram than with parallel gateways. It is interesting that the BPMN specification states that the main reason for introducing implicit start and end events actually was this more compact way of modeling parallel activities [Object Management Group 2009, p. 153].

BPMN also provides another way of modeling start and end events of sub-processes. The events are placed on the border of the sub-process and directly connected with the sub-process’s incoming and outgoing sequence flow (figure 110).

Figure 110: Start and end events as connecting elements

In that way the resulting overall flow is shown more clearly. After the sub-process has been triggered, it is not necessary to search for its start event in order to find out where the flow continues.

This modeling style should only be used when the sub-process has exactly one start event and one end event. It could be imagined to use this structure for connecting different incoming sequence flows with different start events in the sub-process, and for connecting alternative end events with different outgoing sequence flows to the parent process. However, this does not comply with the BPMN specification.

A model with start and end events as connecting elements means exactly the same as a model containing a sub-process with normal start and end events. Thus, the models from figure 110 and figure 111 are equivalent.

Figure 111:The process from figure 110 in normal modeling style

7.2   Loops and Multi-Instance Activities

Many activities are repeated several times in a process. This can be modeled with loops. In figure 112, a purchase for all employees should be made (e.g. for newly designed business cards). At the beginning, the demand is identified. Since not all employees may be reached at once, this task is repeated until all employees have reported their demands. After that, an offer is obtained. If the offer is not satisfying, another offer is obtained. “Obtaining offer” is repeated until finally a suitable offer has been found. Only then the flow continues with “Place Order”.

Loop activities have a small circle-shaped arrow at the bottom. Sub-processes can also be marked as loops, both in the collapsed and in the expanded form. Figure 113 shows the process with the expanded loop sub-process.

Without any further information a loop would be repeated endlessly. Therefore it must be defined how often the loop should be repeated. This can be done with an exit condition. The loop is repeated continuously until the exit condition is true. In figure 112, the exit conditions are displayed as informal text as annotations. For example, the activity “Identify Demand” is repeated until the condition “All employees have reported their demands” becomes true.

Figure 112: Loop activities

Figure 113: Expanded sub-process for a loop activity

Instead of an exit condition it is also possible to define a condition for the continuation of the loop. In this case, the loop activity is repeated as long as the condition is true. Only when it is not longer true, the loop is terminated.

For an automated process which is executed by a process engine, such conditions need to be defined in a specific formal language which can be processed by the engine. BPMN provides attributes for storing such conditions. The specification proposes the XML query language XPath for specifying such conditions, but it explicitly allows other languages, as well. In most cases it depends on the process engine which formal language is used.

The definition of a loop may additionally include the minimum and the maximum number of repetitions. The modeler can also specify whether the condition should be evaluated before or after the loop is performed. If it is evaluated before each loop cycle, the exit condition may already be true at the beginning, and the loop will not be performed at all. If it is evaluated after each looping, the loop is performed once at the least.

For process models which will not be automated, it is recommended to use annotations. The conditions should be written as easily understandable textual statements.

Loops can also be modeled in an entirely different way. A splitting exclusive gateway is placed behind the activity which should be repeated. One of the sequence flows runs back to a merging gateway in front of the activity. Figure 114 shows different representations of loops: With loop activities (top) and with backwards running sequence flows, modeled with gateways (center) and with conditional sequence flows (bottom).

It is a matter of modeling style which of these alternatives is used. In business-level models, the backwards running sequence flows are often used, because the loops become more clearly visible. For automated processes loop activities are preferred, because they are easier to process. When using sequence flows for modeling loops, very complex, nested cycles may be created. These are very prone to modeling errors which may result in dead-locks.

Figure 114: Different ways of modeling loops

Another special kind of activities is the multi-instance activity. It is marked by three parallel lines at the bottom (cf. figure 115). It is used for dealing with an entire collection of objects that need to be processed. The multi-instance activity is carried out several times, once for each object of the collection.

The process in figure 115 starts with entering a delivery note. Such a delivery note usually contains several delivery items. The activity “Check Delivery Item” has to be carried out for each of these delivery items. Thus, the number of repetitions is determined by the number of delivery items. In the next step, each delivery item is compared with the corresponding order item. Therefore, the sub-process “Compare with Order Item” is also a multi-instance activity.

Figure 115: Multi-instance activities

Figure 116: Modeling of the activity “Check Delivery Item” without multi-instance activity

Multi-instance activities have attributes for specifying the elements to be processed. If formal statements are not needed, annotations can be used again, as in figure 115.

In principle it is also possible to model the same behavior with loops (loop activities or backwards running sequence flows). This is shown for the activity “Check Delivery Item” in figure 116. However, if a multi-instance activity is used, the rather trivial support tasks “Select First Delivery Item” and “Select Next Delivery Item” can be omitted.

A multi-instance activity is also different from a loop activity. For a multi-instance activity the number of repetitions is known in advance, since this is determined by the size of the collection of objects. For a loop activity, however, the exit conditions need to be tested after each repetition. Therefore, the number of repetitions does not need to be known in advance. In many cases, the exact number only turns out during execution of the loop.

In contrast to loop activities, multi-instance activities do not necessarily need to be repeated sequentially in a certain order. The different objects can be processed in any order, and also in parallel. If a sequential processing is required, the three lines of the multiple marker are drawn horizontally.

Figure 117 illustrates this with a process of a talent show in television. First, each candidate gives a performance. The group of candidates is known in advance. A loop activity would not be the right choice for this, because then after each performance it would have to be checked whether there is still another candidate who wants to perform. On the other hand, the performances must not be in parallel, because audience and jury want to watch all performances. “Peformance” is thus marked as a sequential multi-instance activity.

Figure 117: Sequential and parallel multi-instance activities

After the last performance, the sub-process “Determine Score” is started. This sub-process is also repeated sequentially for each candidate. Within the sub-process, there is another multiple-instance activity: “Vote” is executed for every jury member. In this example, they vote in parallel.

Like in the case of the parallel gateway, “parallel” does not necessarily mean “simultaneously”. There is just no sequence defined. Before “Calculate Score” can be started, all votes must have been submitted.

7.3   Ad-hoc Sub-Processes

An ad-hoc sub-process is marked with a tilde. Although the activities contained in such a sub-process are determined, the order is not known in advance, because it will only arise when the sub-process is carried out. Typical examples are creative, knowledge-intensive processes. Which activity should be performed at what time is flexibly decided by the personnel, based on the current situation. Repetitions and parallel processing are also possible.

Figure 118: Ad-hoc sub-process

Figure 118 contains the ad-hoc sub-process “Create Marketing Collateral”. The expanded presentation in figure 119 shows the activities which have to be carried out. Since for the most activities the sequence is not known in advance, no sequence flow can be shown for them. At those places where a certain order needs to be followed, a sequence flow can also be drawn within an ad-hoc sub-process. For example, the activity “Print Poster” can only be carried out when the poster has been designed. Therefore, a sequence flow was inserted between these two activities. The same is true for the activities “Create Brochure” and “Print Brochure”.

The tilde as ad-hoc marker can only be used for sub-processes, but not for tasks.

Figure 119: Expanded ad-hoc sub-process

7.4   Types of Tasks

The tasks carried out in a process can be divided into different types. The BPMN specification defines several types. These types strongly reflect the view of process automation with process engines. The following types are available:

•    Service Task

    A service task is an automated function, e.g. the call of an application function or a web service.

•    Receive Task

    A receive task receives a message. It corresponds to a catching message event.

•    Send Task

    A send task task sends a message. It corresponds to a throwing message event.

•    User Task

    A user task expects input by a user. This is a typical task type within a so-called “Human Interaction Workflow”. A user receives his due tasks in a task list from which he can select the task he wants to work on. The actual work is done by entering information into a user interface dialog.

•    Business Rule Task

    In a business rule task, one or more business rules are applied in order to produce a result or to make a decision. It is common to use a business rule management system which is called by the process engine. The business rules management system then evaluates the rules that apply to the current situation.

•    Script Task

    A script contains statements which are processed directly by the process engine.

•    Manual Task

    A manual task is carried out without IT support.

•     Abstract Task

     No type has been defined

Except for the abstract task, the different tasks are marked with icons (figure 120).

Figure 120: Icons for different types of tasks

Modelers are allowed to define additional task types and mark them with their own icons in the task symbol. However, this is not supported by every BPMN modeling tool.

7.5   Call of Processes and Global Tasks

Until now two types of activities have been used: Sub-processes and tasks. The latter are not decomposed any further. Normal sub-processes and tasks are part of the process they belong to. This means they depend on the process; and they cannot be used separately.

In many cases, however, an activity should be re-used in several processes. BPMN provides the construct of the “call activity” for this. When a call activity appears in a process, the actual activity is defined at another place, and in the process it will only be called.

Figure 121: Call of a global task from different processes

If the called activity is a task, a so-called global task will be called. A global task is defined only once, i.e. its attribute values, such as the name, the description, involved functions or web services, parameters, etc. exist only once. This task can then be called within different processes. The attributes of a global task are not defined in a graphical model, but – depending on the modeling tool – in an attribute dialog which can be opened for a call activity element.

As shown in figure 121, a call activity is drawn with a thick border. In this case, “Determine Discount” is defined as a global task. Process 1 and Process 2 each contain a call activity referring to this global task. A business rule task is used in this example. Global tasks can be of any task type, also without a specific type.

Especially for automated processes there is an important distinction between normal embedded activities and call activities. Normal activities automatically have access to any information within the process. In the example above, there could be two variables for storing the total amounts of the offer and of the order. In a normal activity, such as “Create Invoice”, these values can be directly accessed and used. If variables are defined in a process, they will be visible in all tasks and sub-processes of that process – except in call activities.

Since the activity “Determine Discount” has been defined as a global task, it cannot access the value of such a process variable. This is because the global task can be called from different processes. It is therefore required to be independent from the calling process. For exchanging information between a calling process and a called global task, interfaces must be defined. An interface determines input and output parameters. BPMN also provides constructs for parameters, but they are not graphically displayed in models.

Although the visibility of variables is rather a subject of executable process models, it should also be considered for business-oriented models whether an activity can be used several times. In the following chapter 7.6, a business example will be presented which illustrates a sub-process’s dependency from the surrounding process.

A call activity can also call another process. In figure 122, the process “Put Goods into Stock” is called from two other processes. The “+”-marker indicates that the called activity is a process. This called process, “Put Goods into Stock”, itself is a normal process. It could also be performed for itself, without being called from process 1 or process 2. Thus it is different from a sub-process which depends on the parent process. A normal sub-process cannot be called from a different process. The re-use of processes is only possible with independent processes which are included via call activities.

An expanded presentation as in figure 123 is also possible. Although it graphically appears as if “Put Goods into Stock” is a part of process 1, this process is still defined independently. An expanded presentation of process 2 would display the same details within the expanded call activity symbol. Modeling tools have the problem that changes in a called process need to be reflected in all process diagrams with an expanded call activity referring to that process. Therefore the presentation from figure 122 would be more practical in most situations.

Figure 122: Call of a process from other processes

Figure 123: Expanded view of a called process

Since a called process is an independent process, it can also contain lanes. The activities can be located in other lanes than the call activity in the calling process. This means that the lane will be changed when the called process is started, and thus e.g. the performing role. In this case, the lane containing the call activity only indicates who is responsible for calling the other process and for handing over the required information. Of course, a called process can also contain message flows to other pools.

A normal sub-process should only have one start event, which should be untyped (cf. chapter 7.1). A called process, on the other hand, can have several start events. Exactly one of them should be an untyped event.

In figure 124, the process “Put Goods into Stock” not only has an untyped start event, but also a catching message start event. When this event occurs, the process is started as an independent process, i.e. without being called from another process. When called by a call activity, the process starts with the untyped start event, just like when it is triggered from the outside, e.g. by a user of a business process management system who selects and starts the process with a mouse-click.

Figure 124: Called process with two start events (untyped and message)

Like a global task, the design of a process which may be called several times must be generally valid, so that this process is independent from the calling process. Here again, clear interfaces need to be defined.

In chapter 7.1, a sub-process “Review Application” has been discussed (p. 79 ff). It was proposed to use the attribute “result” for communicating the sub-process’s result to the parent process. This attribute must be available to both the parent process and the sub-process. It is defined for the entire job application process, and it is also visible in the sub-process “Review Application”, so that the sub-process can assign its result to that attribute. It is then available in the parent process.

This implies that the sub-process “Review Application” depends on the parent process. The dependency is caused by using the parent process’s attribute. If this sub-process was re-used anywhere in another process, it would not work, because it would have to access the attribute “result” of the job application process.

In order to become re-usable, the sub-process “Review Application” must not access any attributes from the parent process. Interfaces have to be defined so that information between parent process and child process can still be exchanged. It must be specified which values are passed to the re-usable sub-process, and which values are returned.

Programmers know this principle: Called functions or methods should not access global variables, because this would cause a high dependency. Independent functions or methods receive the required values as parameters, returning the results afterwards.

Such interfaces are usually not graphically modeled. The exact way of specifying interfaces also depends on the tool used. A possibility for visualizing input and output data will be described in chapter 10 in the context of data objects.

The described distinction between sub-processes and called processes is not only relevant for executable processes. It can also be found on a business level. If a sub-process, for example, is always carried out by the same people and only in one parent process, then the communication between these two processes will not be very difficult. Sometimes, however, a part of a process will be outsourced to a service provider or to a shared service center. They may carry out the same partial process as a service for different other processes. In such a case, the interface must also be defined, i.e. which information items, documents, etc. have to be exchanged.

7.6   Examples of Sub-Processes and Called Processes

A process is a genuine sub-process if it depends on the parent process. It may access data from the parent process, as described above, or it may depend on previous activities or decisions of the parent process. A sub-process is used for enclosing and hiding details, thus making the parent process model more concise. The contents of the sub-process nevertheless remain an inseparable part of the parent process, and they do not make any sense without the parent process.

The process for a treatment in hospital provides an example (figure 125). First, an initial examination is carried out, followed by the admission as an in-patient. If the initial examination has confirmed that there are no problems concerning an anesthesia, the process waits for the time of treatment. At this point, the patient is anesthetized and then operated. Of course, this process does not represent the real process in a hospital, in which different kinds of treatments are carried out (some with anesthesia, some without), as well as further examinations, etc. The model is only an example for illustrating sub-processes and called processes.

Figure 125: Example process of a treatment in a hospital

It may be decided to combine the activities “Anesthetize Patient” and “Operate Patient” into a sub-process. The reason is that anesthetization and operation are detailed activities that are closely related. In larger models, the creation of sub-processes would also help to reduce the complexity of the top-level model.

A close look at the new sub-process “Give Treatment” in figure 126 reveals that this sub-process must not be isolated from the context of the main process. Before the patient can be anesthetized, it must be confirmed that there are no medical objections. In the main process this has been confirmed by the initial examination (although this may be different in real hospitals). The sub-process “knows” that potential problems concerning anesthesia have already been ruled out. Therefore it is possible to anesthetize the patient without any further examination.

Figure 126: Example process with an embedded sub-process

If it was possible to re-use this sub-process in another process, it could be included into a process of an ambulatory treatment as in figure 127. The resulting overall process is incorrect and even dangerous; because even those patients would be anesthetized whose state of health does not allow this. The consequences would be fatal. Strictly speaking, the sub-process is not re-used. It is rather a copy which is not longer connected to the sub-process from figure 126. It can be modified independently from the original sub-process.

Figure 127: Incorrect re-use of the sub-process within an ambulatory treatment

The described sub-process is not re-usable because it depends on the parent process, as described above. A re-usable, callable process must be independent from the calling process. Interfaces must be defined for exchanging data.

Figure 128 shows a re-usable process for giving a treatment. The calling process needs to provide the information whether an examination has already been made. If so, the examination results are also provided.

Figure 128: Re-usable process “Give Treatment”

Based on the provided information, a missing examination is performed, and it is decided whether an anesthesia is possible. This process can be re-used without any problems. There is a specified interface, there are no further preconditions for the calling process, and the called process does not access data of the calling process – except those data that are passed explicitly. Therefore, the process can be used for both the inpatient treatment and the ambulatory treatment, without any modifications (figure 129).

Figure 129: Calling the process from figure 128

8   Handling of Exceptions

8.1   Interrupting Intermediate Events

Usually it is rather easy to model the normal process flow. Capturing and documenting special cases and exceptions is more complicated and laborious. BPMN contains several constructs especially for modeling and handling exceptions.

When an activity is carried out, sometimes an event occurs that results in an early abortion of that activity. When writing an examination it may happen that the time is over before the candidate has finished. Thus, the timer event “Time over” occurs during “Writing Examination”. This causes the activity to be aborted.

This is modeled by attaching an interrupting event to an activity, i.e. by placing it on the border’s activity (figure 130). Since the event occurs while the process is being carried out, it is an intermediate event. The activity “Write Examination” now has two outgoing sequence flows: a normal one, originating directly from the activity, and an exception flow that starts at the attached intermediate event.

Figure 130: Abort of an activity by a timer intermediate event

If the event “Time over” does not occur during the examination, the activity will be finished regularly. A token is passed via the normal sequence flow to the activity “Submit Examination Sheet”.

However, if the event does occur, the activity will be aborted, and a token will be released via the downwards outgoing exception flow. The next activity is then “Collect Examination Sheet” (carried out by the examination supervisor). No token will be passed anymore to “Submit Examination Sheet”, since the activity has been aborted. The attached event only has an effect if it occurs while the activity is being performed. If it occurs earlier or later, it will be ignored.

An interrupting event can also be attached to a sub-process. In the process shown in figure 131, the entire sub-process “Process Order” is aborted when a cancellation is received. In this case, everything that happens within the process is completely terminated. If one of the three activities is being executed at that moment, it will be aborted. Activities that have not been started yet, will not be executed anymore. When the sub-process is aborted, all tokens will be removed from within that sub-process, and a token will be emitted via the exception flow at the interrupting event.

Figure 131: Aborting a sub-process when a message is received

If the order has been completely processed, in this example no cancellations are possible anymore. If a cancellation arrives anyway, it will be ignored.

When an attached intermediate event is used, it is also possible to omit the normal outgoing sequence flow and to exit the activity only via the abortion.

In figure 132, the daily work of a security guard has been modeled. Since there is no natural ending for the activity “Guard Building”, it is always finished by the timer event “Finishing time”.

In contrast, the model in figure 133 is not that convincing. Here, the activity “Sell Pastries” will be repeated until the closing time is reached. The problem is that the activity is aborted at once when the timer event occurs. If the salesperson is just in the middle of selling some pastries, in real life he or she will complete the sale before finishing the work.

Figure 132: An activity without regular outgoing sequence flow

Figure 133: A loop activity that is aborted by an attached intermediate event

This example can be modeled in a better way according to figure 134. Here a loop with a terminating condition is used. This condition is only evaluated when each loop repetition has been finished. Therefore, a selling activity at closing time will be completed, before the process is finished.

Figure 134: Improved process

8.2   Non-Interrupting Intermediate Events

There is another variant of the attached intermediate event. In the previous models, the occurrence of the event always resulted in an abortion of the activity. Sometimes, however, it is desired to react to such an event, but still to continue the ongoing activity. In figure 135, the customer should be notified if his order has not been completed within five days, but the processing of the order must not be interrupted.

Figure 135: The attached intermediate event does not interrupt the activity

Figure 136: The non-interrupting version of the attached message event

This is indicated by drawing the intermediate event’s double border with a dashed line. If the event “5 days after order processing has begun” is reached before the activity has been finished, a newly created token will be passed via the exception flow to the task “Notify about Intermediate Status”. After this task, the token flows to the lower end event where it will be swallowed.

At the same time, the original token still remains in the activity “Process Order”. When this task is finished, the original token is moved via the regular sequence flow, and the product is shipped. The process is finished when both tokens have reached their end events.

An attached non-interrupting event simply creates an additional token if it occurs during the execution of the respective activity. If both sequence flows should be merged by a gateway, it is not possible to use an exclusive gateway, since more than one token may arrive. A parallel gateway neither would be correct since only sometimes there will be a token in the lower sequence flow. Thus, an inclusive gateway would be required.

The message event also has a non-interrupting variant. In figure 136 the reception of an inquiry concerning an order triggers the task “Answer Inquiry”. The order is further processed in parallel. Besides timer and message events, the following types of intermediate events (described in chapter 6.4) can be attached to activities: Signal events, conditional events, multiple events, and parallel multiple events (figure 137). Each of them can be used as an interrupting or a non-interrupting event, the latter with a dashed boarder. Of course, non-interrupting intermediate events not only can be attached to tasks, but also to sub-processes.

Figure 137: Types of attached intermediate events: Signal, condition, multiple, parallel multiple. On top the interrupting versions; at the bottom the non-interrupting versions.

8.3   Handling of Errors

The handling of exceptions is quite often required because of an error. For this, intermediate events of type “error” can be used. They are marked with a flash symbol. In contrast to the previous types of intermediate events, error intermediate events cannot be used within normal sequence flows. They can only be attached to activity boundaries.

Figure 138 contains a process in a laboratory. First an analysis is conducted, and then the results are evaluated. Should the analysis reveal that the equipment is defective, this would be an error which prevents normal execution of the process. For this case there is an exception flow in which the sample is sent to an external laboratory.

Figure 138: When an error occurs, an exception flow is started

The activity to be aborted by an error event may also be a sub-process. In this sub-process it is possible to model kind and origin of the respective error. Therefore the catching error event is complemented with its throwing counterpart.

Figure 139 shows a sub-process with two throwing error events. After taking a sample, the sub-process is started. First the sample is analyzed. This is usually followed by checking the result. If the result is plausible, the sub-process finishes. If the result is not plausible, this is an error, and the throwing error end event “Result not plausible” is reached. In this case, the sub-process is aborted and the thrown error is caught by the error intermediate event at the sub-process boundary. In this case, the exception flow is followed, and the activity “Arrange for External Analysis” is triggered.

Figure 139: Errors occurring in the sub-process are forwarded to the error intermediate event at the boundary

Figure 140: Different exception flows are triggered by named error events

In the sub-process, another error may occur: If during the activity “Analyze Sample” it turns out that the equipment is defective (here also modeled with a catching error event), it will be repaired. If repair has been successful, the analysis of the sample will be started again. In the case of an unsuccessful repair, the throwing error event “Equipment out of order” occurs. Again, the sub-process is aborted and the error is thrown to the intermediate error event that triggers the exception flow to the activity “Arrange for External Analysis”.

Analogous to other types of events, the filled icon stands for a throwing event, while a catching event is represented by a blank icon. Throwing error events are always end events, because they completely abort the surrounding sub-process. Catching error events, on the other hand, are always intermediate events. They can only be attached to the boundary of tasks or sub-processes.

In figure 139 there are two different throwing error events in the sub-process. Since the error intermediate event at the boundary lacks a label, it catches any kind of error from the sub-process – regardless from which error event it is thrown.

In some cases, however, it may be necessary to have different exception flows for different errors. For this, several catching error events can be attached to the sub-process boundary. If they are labeled with the names of the throwing error events, each event will only react to errors thrown by an error event of the same name.

The model in figure 140 makes use of this. If the error “Result not plausible” occurs, an external analysis should be arranged, as in the previous model. If the error “Equipment out of order” occurs instead, repair by the manufacturer should be arranged in addition to the external analysis.

If there are several error intermediate events attached to a sub-process boundary, they should be always labeled. Since an unlabeled error intermediate event always catches any type of error, it also reacts to errors with own labeled events. The resulting implicit parallel flows are difficult to understand.

8.4   Escalation Events

Escalation events are rather similar to error events. While error events are mainly used for technical problems, escalation events primarily stand for problems on a business level, e.g. if a task is not completed, a goal is not reached, or a required agreement is not achieved.

Similar to error events, throwing escalation events can be modeled in a sub-process. An escalation is caught by an escalation intermediate event with the same name, attached to the sub-process border. The intermediate event again triggers an exception flow.

Figure 141: A sub-process with escalation events

In contrast to errors which always abort the activity, escalations come in both variants: The interrupting and the non-interrupting event. Non-interrupting escalation events are regarded as the default.

The example of figure 141 starts with adding an incoming inquiry to a queue. After that, the expected duration for answering the inquiry is calculated. This expected duration depends on the length of the queue. If it turns out that the inquiry cannot be answered within the promised reaction time, a token flows to the throwing escalation end event. The escalation is caught by the non-interrupting escalation intermediate event at the sub-process’s boundary. This event then emits a token and triggers the activity “Arrange for Additional Personnel”.

Since it is a non-interrupting intermediate event, the sub-process continues in parallel. If the inquiry is the first one in the queue, an answer will be written without delay. Otherwise, if the queue already contains other inquiries, it must be waited until all of them are completed. This is indicated by the conditional event “Inquiry has reached the beginning of the queue”. When this event has occurred, the answer is written and finally sent to the customer in the main process.

Figure 142: Alternative model of the sub-process from figure 141

Figure 143: Sub-process with throwing escalation intermediate event

It may be confusing that there is an exclusive gateway for merging the two sequence flows, because they originate from an inclusive gateway. However, if the conditions at the inclusive gateway are analyzed, it turns out that in any case exactly one of these conditions becomes true. Therefore, the merging by an exclusive gateway is correct. As an alternative, the model of the sub-process could be a bit more extensive, as in figure 142, which on the other hand requires more space.

Since an escalation usually does not abort the sub-process, it is not only possible to use an end event for throwing an escalation, but also an intermediate event (figure 143).

Nevertheless, if an escalation is required to abort the entire activity, the attached intermediate event’s boundaries are drawn with solid lines (figure 144). In such a case, the throwing escalation event in the sub-process needs to be an end event. If a throwing escalation intermediate event was used, the subsequent sequence flow could never be used, because the sub-process would be aborted by the escalation.

Figure 144: Interrupting escalation intermediate event

As in the case of error intermediate events, there can be several escalation intermediate events which can be distinguished by their names.

8.5   Event Sub-Processes

In contrast to an ordinary sub-process, an event sub-process is not triggered by a sequence flow, but by an event occurring during process execution. Therefore an event sub-process does neither have any ingoing nor any outgoing sequence flows.

Figure 145 shows a simplified software development process. At the beginning the requirements are determined, followed by the development. It may involve several iterations. Each iteration is planned before the planned features are implemented. The iteration steps are repeated until the software is completed.

In most software projects, change requests arise during the development. These are handled in the event sub-process “Process Change Request”. The dotted boundary distinguishes the event sub-process from a normal sub-process. It is triggered by the event “Change request received” – but only if this occurs while the main process is running. The start event’s border is dashed, i.e. it is a non-interrupting start event. The main process is therefore continued while the event sub-process is carried out. In this special sub-process first the feasibility of the required change is checked, then the effort is estimated and a decision is made about the implementation. If the change is to be implemented, it will be documented. In the main process this documented change will be implemented in one of the following iterations.

Figure 145: Software development process with an event sub-process for processing change requests

During software development several change requests may arise. Accordingly, the event sub-process can be performed several times. Several simultaneous instances of the event sub-process are also possible.

There is also the possibility to abort the surrounding process when an event sub-process is started. In this case, the start event is drawn with the normal solid line.

Figure 146 shows the sub-process “Produce Chemicals”. This sub-process itself contains two event sub-processes. The first one, “Adjust System”, is non-interrupting, as can be seen by the dashed line of the conditional start event. The system may be adjusted several times during production. By contrast, an error of the type “Critical problem” not only starts the second event sub-process “Conduct Emergency Shut-Off”, but it also aborts the process “Produce Chemicals”. This is indicated by the fact that the start event’s border is not dashed, but solid.

Logically, the interrupting event sub-process “Conduct Emergency Shut-Off” can only be started once during the sub-process “Produce Chemicals”, because after all this process is aborted. If the event sub-process ended in a normal untyped end event, a token would be emitted to the surrounding process’s outgoing sequence flow. In this example, however, an error end event is used, which again throws an error. This error is caught by the attached error intermediate event “Emergency shut-off”, and a token is emitted to the exception flow.

A start event of type “error” can only be used in event sub-processes. There is no dashed variant of the error start event, i.e. such an event can only trigger interrupting event sub-processes.

Figure 146: Sub-process with a non-interrupting and an interrupting event sub-process

Most other event types can be used both as interrupting and non-interrupting events. Besides message events and conditional events, this is also true for timer events, signal events, multiple events, and parallel multiple events. In contrast to normal processes, the escalation event here can also be used as a starting event. The non-interrupting variants of the aforementioned events are only possible within an event sub-process, but not in a normal process. Untyped start events, on the other hand, cannot be used in event sub-processes.

In the next chapter, the compensation event will be introduced as a further event type that can also be used as a start event in an event sub-process, but only as an interrupting event.

As it is known from normal sub-processes, event sub-processes can also be drawn in a collapsed state (figure 147). Like the expanded versions they have dotted boundary lines. In addition to this, the respective start event of each process is shown in the left upper corner. This event’s boundary – solid or dashed – shows whether the surrounding process is aborted or not.

Figure 147: Collapsed event sub-process

9   Transactions and Compensations

9.1   Modeling of Transactions

The term “transaction” is used in different contexts. For example, there are business transactions, such as a money transfer from one bank account to another. In computer science, especially database transactions are well-known. The different types of transactions have in common that they are always complete units of work. A transaction can either be carried out in its entirety, or not at all. If something goes wrong, the transaction must be rolled back.

During a money transfer it might turn out that the receiver’s account number does not exist. Then the money must be transferred back. If the computer crashes while a customer data set is being saved, the database system will roll back the database to the original state before the saving operation had been started. Thus it prevents incomplete data sets causing an inconsistent state of the database.

Parts of business processes can also be treated as transactions. A typical example is the booking of a journey which involves separate bookings of flight and hotel. The booking of the entire journey is only successful if both the flight and the hotel have been booked successfully. If the hotel has been booked and it then turns out that there is no flight available anymore, the booking of the journey has not been entirely completed. In this case, the hotel booking needs to be reverted, i.e. it must be cancelled at the hotel. Since such booking procedures including inquiries and answers may take many days, business process transactions are also called long-running transactions.

For modeling transactions, the process from figure 131 on p. 100 is used again. There, the sub-process “Process Order” will be aborted when the event “Cancellation received” occurs. According to the model, a cancellation fee may be invoiced. Apart from that, the process is finished.

A closer look reveals that in fact the abortion of a sub-process entails further activities. In the sub-process, the order is checked first, then the goods are removed from stock, and finally they are packed. Depending on the point in time the cancellation arrives, it is possible that the goods have already been removed from stock or packed. In these cases, it is necessary to put the goods back into stock, or first to unpack and then put them back into stock.

Figure 148: When a cancellation message is received, the effects of the finished activities are reversed

Thus, the effects of the activities already completed must be reversed. This can be reached by defining compensating activities for the sub-process’s activities. “Check Order” does not need to be compensated. The compensating activity for “Remove Goods from Stock” is “Put Goods into Stock”. “Pack Goods” is compensated by “Unpack Goods”.

Figure 148 shows how the required compensations could be modeled with basic BPMN constructs. When the interrupting event occurs, it needs to be distinguished whether the goods have already been removed from stock. If this is not the case, nothing needs to be done.

If the goods have already been removed from stock, it must be determined whether they are already packed. In this case, the activity “Unpack Goods” will be carried out first. In both cases the goods will then be put into stock again.

The rounded rectangle with the dash-dotted line is a group. It only serves presentation purposes, such as highlighting interesting parts of a model, or grouping elements that belong together, as it is the case here. The control flow logic of the model is not influenced by a group.

This model is rather intricate. The handling of the exception is larger than the normal flow. It can be easily imagined what would happen if a sub-process contained many more activities which could be executed in various sequences. The part of the model containing the compensations would become very huge, since all possible combinations of completed activities would need to be distinguished.

Another way of modeling this case is shown in figure 149. Here the border of the sub-process “Process Order” is drawn with a double line, thus marking the sub-process as a transaction. A transaction must either be carried out completely or not at all. This means that aborting a transaction automatically reverses the effects of the activities that have already been carried out. In order to enable this, a compensation activity is assigned to each activity that requires compensation.

The activity “Put Goods into Stock”, for example, contains a rewind-symbol (two arrowheads), identifying it as a compensation activity. It compensates the activity “Remove Goods from Stock”. This assignment is modeled with a compensation association and a compensation intermediate event attached to the boundary of the activity to be compensated. Not only tasks, but also sub-processes can be marked with a rewind-symbol and be used as compensating activities.

Catching intermediate events of the compensation type are only used for this purpose. They are always attached to an activity, and they always have outgoing compensation associations running to the compensating activity. The compensation association is a dotted line with an arrow. It must not be confused with message flow.

Figure 149: Model with a transaction and compensating activities

The activity “Check Order” does not have a compensating activity, because it does not have any effects that need to be reversed. It would not make sense to “uncheck” a checked order.

If the transaction is aborted, it will be checked which activities have already been carried out. Only for these activities, the assigned compensation activities will be carried out one after another – in the reversed order of the original activities.

This means for the example process: If only the activity “Check Order” has been carried out, no compensation takes place in case of cancellation, because there is no compensation defined for this activity. If the goods have already been removed from stock, they will be put back into stock. If the goods are even packed, they will first be unpacked and then put into stock again. Thus, the flow following an abortion of the sub-process “Process Order” is exactly the same as the exception flow in figure 148 involving several gateways.

How is a transaction aborted? One possibility is to trigger the abortion from the outside. If the process is executed by a process engine, an administrator can react to an error that cannot be handled otherwise by aborting the process via the engine’s administration component.

In such a case, first the compensation activities are carried out, as described above. Then a token is passed to the modeled exception flow. For this there is a catching intermediate event attached to the transaction boundary. This intermediate event type is called “cancel” and contains a blank cross. The cancel intermediate event indicates that the sub-process is not just aborted, but the compensations will be carried out first.

In case of serious errors it may happen that it is not possible any more to abort the transaction normally, including compensations. A defect of the storage equipment may cause not only the need to abort the transaction, but it may also inhibit putting goods into storage. For such a case it is possible to add another exception flow without previous compensations. This could be modeled with a normal error intermediate event attached to the transaction boundary. However, in practice it is not feasible to model every conceivable case.

The normal abortion of a transaction can not only be triggered from the outside, but also from within the process. This is modeled by an end event of type “cancel”. Its symbol is a filled diagonal cross. If this end event is reached, the entire process will be aborted, just as when a terminate end event is reached. In the case of the cancel end event, however, the required compensations are carried out, and then the exception flow starts at the catching cancel intermediate event.

In the example, the transaction must be aborted when the event “Cancellation received” occurs. While in the model of figure 148 the catching message intermediate event is attached to the sub-process boundary, this is not possible for a transaction. A normal interrupting intermediate event would trigger the exception flow without performing the compensations, as described above.

A catching cancel intermediate event must be used instead. This is triggered when a throwing cancel end event is reached within the transaction. Therefore, two parallel paths are created by the parallel gateway. In the sequence flow at the top, the activities are performed. At the same time, the parallel sequence flow at the bottom waits for the occurrence of the intermediate event “Cancellation received”. If this intermediate event occurs, the cancel end event is reached, i.e. the transaction is aborted. Then the required compensations are carried out and the exception flow at the attached cancel intermediate event is triggered. Since the cancel event aborts the entire transaction, the path at the top is aborted, as well.

If the transaction is not aborted, the end event of the upper path finally will be reached. In this case the bottom path is still active, i.e. a token still waits for the reception of a cancellation. Therefore it would not be correct to use an untyped end event, because this would only terminate the upper path. Instead a terminate end event is used that finishes the entire transaction sub-process, including the lower path. In this case the transaction has been completed successfully, and the process continues with the normal sequence flow. The next activity to be performed is “Ship Goods”.

9.2   Direct Call of Compensations

Compensations can be modeled without transactions, as well. For this, throwing compensation end or intermediate events can be used. They contain filled rewind-symbols.

In figure 150, the process for booking and approving a business trip has been modeled. Here it is assumed that the travel will only be approved when the exact dates and prices of hotel and transport have been provided. Therefore, in this process the booking activities take place before approval.

The activities “Book Flight” and “Book Hotel” both have compensation activities assigned. However, these activities are not part of a transaction, so that the compensation cannot be triggered by aborting a transaction. They must be explicitly called.

The exclusive gateway after requesting the approval has three exits. In the first case the request is approved, and the process finishes with an untyped end event. There are no compensations required. In the second case the request is completely rejected. The sequence flow runs to a throwing compensation end event. This event does not have any label. Thus it triggers the compensation of all completed activities in reverse order. Both the flight and the hotel booking are cancelled. The activity “Request Travel Approval” does not have a compensation activity, so it is not compensated.

In the third case, the travel is approved, but it is not approved to travel by plane. Therefore, only the activity “Book Flight” must be compensated, but not the activity “Book Hotel”. This is indicated by naming the activity to be cancelled in the label of the throwing intermediate compensation event. If required it is also possible to specify several activities in the label of a throwing compensation event. In this example, however, only the compensation activity “Cancel Flight” is carried out. Afterwards a train journey is booked, and the process is finished.

Figure 150: Direct call of compensations

In this model it is not possible to book a train in the first place. This, of course, is not very reasonable, but the model should be kept rather compact in order to illustrate the essence of the BPMN structure to be illustrated, just like all examples in this introductory book.

9.3   Event Sub-Processes for Compensations

Compensations can also be handled by event sub-processes. They have a compensation start event. In contrast to other event sub-processes as discussed in chapter 8.5, they are not triggered by an event of the surrounding process. Instead they are started when a throwing compensation event of the same name occurs after that process. Thus, the event sub-process will only be performed after the surrounding process has been finished.

The border of the compensation start event is always drawn as a solid line. In normal event sub-processes this indicates that the surrounding process is aborted. Since here that process is already finished, there is no distinction between a non-interrupting and an interrupting compensation start event.

Figure 151: Event sub-process with compensation start event

In figure 151, a travel agency organizes the visit of a festival for its customers. For this, they first book the journey and then the tickets for the festival. The activity “Book Journey” has a compensation activity; the festival tickets on the other hand cannot be returned.

After organizing the festival visit, the process waits until either the deadline for cancellation is reached, or a cancellation is received from the customer. In this case, the compensation end event “Cancellation of festival visit” is reached. Now the event sub-process is started via the compensation start event with the same name as the throwing end event. In the event sub-process, the compensation for “Book Journey” is triggered. Since unfortunately the festival ticket cannot be returned, the travel agency issues a voucher of a smaller amount of money to the customer which can be used when booking the next journey.

Since in the main process the end event has already been reached, the entire process is completed with the end of the “Process Cancellation” event sub-process. It would also have been possible to trigger this sub-process by a throwing compensation intermediate event, after which the process would be continued.

Such a compensating event sub-process can be used if not only the compensation activities need to be performed in case of a cancellation, but also other activities. Although it is a bit more complicated to figure out in which case which activities have to be compensated in which order, such an event sub-process provides a sophisticated way of modeling such complex scenarios.

9.4   Use of Exceptions, Transactions and Compensations

The concepts for modeling exceptions, transactions, and compensations described in this and the previous chapter originally have been developed in software technology. They are especially interesting for modeling executable workflows. In principle it is also possible to use them in business-oriented models, since errors, exceptions, cancellations, etc. also occur in non-automated processes. The examples used for the explanations have been deliberately taken from the business-domain.

Some BPMN experts point out that many process models almost exclusively consider normal processes in which everything runs as expected. However, a large portion of problems and of the effort involved with managing business processes results from errors, exceptions and special cases. Therefore they recommend to model exception flows, as well, using the special constructs provided by BPMN (cf. e.g. [Silver 2009]).

On the other hand, in contrast to the basic BPMN elements, these constructs need a lot of explanation, and they are not easy to apply. Exact models of all exceptional cases will become very large and detailed. It needs to be decided whether they yield an appropriate benefit to the target audience and whether the required effort is justified. This depends on the modeling purpose.

In principle, some of the more technical concepts can be transferred to the business level, but this may cause additional problems and questions.

For example, compensating a booking transaction in a computer system can be achieved rather easily by creating a compensating entry into the system. The above example concerning the booking of a flight or a hotel is not that easy in practice. For example, a cancellation may be ruled out for budget tickets, or it may be possible only within a certain time span, or it may cost an additional fee. In some cases it is better to alter the person or the date of a booking instead of cancelling it entirely. Each of these cases can have different effects on a process. Just modeling a compensation activity does not accurately reflect all these cases.

It needs to be decided in advance whether, how, and how detailed such cases should be modeled. This should be documented as part of the modeling conventions.

10   Data Objects in Processes

10.1   Modeling Data Flow

When a process is carried out, it uses and creates data, information, files, documents, etc. A sequence flow from one activity to another is often accompanied by data transfer. The main purpose of message flow is also the exchange of data.

So far, when modeling sequence or message flows, data have not been considered explicitly. A sequence flow purely triggers the following activity. In respect to message flow, it is only important that a certain message is received, and thus the related event occurs. If it is required to know which particular data are exchanged, this must be modeled separately.

BPMN was initially developed as a graphical notation for executable processes. Therefore, it was implied that all activities within a process can access all data within a pool at any time [cf. Debevoise and Geneva 2008, p. 3]. If this concept is actually applied (e.g. by a process engine), it will not be necessary to model the movement of data within a process.

However, in many processes there is no common data pool, so that it does make sense to explicitly model the data transfer. And even if there is a common data pool, it may be helpful to model input and output data of the activities. In doing so, data-related dependencies can be identified. For example, when using a common data pool, it still must be ensured that a certain piece of information has already been produced before it is required.

Figure 152 shows how to model data flow within a process. For this purpose, data objects are used in the form of document symbols. A data object can represent any kind of data and information, such as an electronic data set, a file, or a physical document.

Figure 152: Modeling data flow with directed associations

Figure 153: Data objects connected to sequence flows

With directed data associations it can be modeled which activity outputs a certain data object, and which activity makes use of it. The name of a data object is often appended with the object’s current state, printed in square brackets. In the process in figure 152, the data object “Job Posting” can change its state from “to be reviewed” to “to be reworked” and “approved”.

A data association is drawn as a dotted line. It must not be confused with the dashed message flow connectors.

Data objects only exist within a process. In order to model permanent data, a data store can be used. In figure 152, the published job posting is transferred to such a data store at the very end. Thus it will be still available when the process has finished.

Most of the data flows shown in figure 152 run in parallel to sequence flows. In such cases it is also possible to simply connect the data object with the sequence flow, using an undirected association (figure 153). In this example, both models are equivalent. However, it is also possible to create a data object at a certain point and to use it much later in the process. This means that the data object is not passed with the sequence flow to the directly following activity. Such a case can only be modeled with directed associations, as in figure 154.

Figure 154: A data object that is used in a later activity

Figure 155: Alternative modeling of figure 154

Drawing many data associations throughout the entire process can result in a confusing diagram. It is therefore allowed to draw the same data object several times, as in figure 155. The two data object symbols do not represent two different data objects which happen to have the same name, but both actually reference the same object.

10.2   Multiple Data Objects

Often it is not only necessary to model single data sets, but also collections or lists. Such multiple data objects can be marked with three lines, just like multi-instance activities and multi-instance participants. In the first step of the process fragment in figure 156, the collection of received applications is reviewed. In doing so, the interesting applications are selected. These interesting applications are also a collection. In the second step, one single application is selected. As a single object, it naturally does not have a multiple-marker anymore.

Figure 156: Multiple data objects representing lists or collections

10.3   Data and Events

Data objects only exist within a process; therefore data associations cannot cross the borders of pools. Direct data exchange with other processes is modeled with message flows (see chapter 5). In order to specify that the content of a message is processed as a data object, a catching message event can have an outgoing data association. Conversely, a throwing message event can have an incoming data association. The sent message then contains the contents of that data object (figure 157).

Figure 157: Events can convert messages into data objects and vice versa

10.4   Data Store

An indirect data exchange can also be realized by one process writing into a data store, and another process reading the data from this data store. This requires that both processes can access the same data store. This is often the case if both processes belong to the same organization. In figure 158, a bill of material is created within the engineering process and written into a data store. In production planning, the bill of materials is read from the data store in order to determine the materials required.

Figure 158: Two processes accessing the same data store

10.5   Passing Data to Called Activities

If a process calls another independent process via a call activity (cf. chapter 7.5), the passing of data can also be modeled with data objects.

A data association leading into a call activity means that the data object is passed to that activity. Conversely, an outgoing data association stands for the return of a called activity’s data object to the calling process. However, it is not possible to pass any arbitrary data objects, because the process or global task to be called is defined elsewhere. This includes the definition of required data, as well produced and returned data. A global task is not modeled graphically, but for a process to be called from other processes, the required input and the provided output can be modeled.

In figure 159, the process “Appraise Insurance Claim” is called from within the process “Process Insurance Claim”. The process “Appraise Insurance Claim” at the bottom contains data object with arrows representing the process’s data input and data output. The arrow of a data output is filled, that of a data input is blank. A data input defines which data need to be provided to the process in order to work properly. Accordingly, a data output denotes which data are produced by the process and returned to the caller.

Figure 159: Modeling data input and output for called processes

If a process is integrated into another process via a call activity, it must be ensured that correct data inputs are provided. Likewise, only the defined data outputs can be received back from the call activity. In the example the insurance claim process passes an insurance claim to the called process and waits for an appraisal report which corresponds exactly to the modeled data input and output in the appraisal process. Therefore, the call will work properly.

It would be possible to model further data objects and associations in the process “Appraise Insurance Claim”. These, however, would only internally be used in the process.

If a process model contains several data inputs or outputs, the calling process must be provided with data objects suitable for all inputs, and the process will also return data objects of all data outputs. The BPMN specification also defines optional data inputs and outputs. However, this is not visible in the diagram and should be explained in an annotation, if required. Data inputs and data outputs can also be marked with three lines as multiple data objects.

10.6   Use of Data Objects

Data objects and associations, and especially the definitions of data inputs and outputs, can carry important information for process execution. For this, these elements can be connected with specific data structures, e.g. XML schema definitions. When executing a process instance, a process engine can then decide whether the required data inputs are available, and a certain activity can be triggered. Nevertheless, further detail information is required for this in addition to the model’s graphical information.

On a business level, data objects provide the means to analyze and optimize processes in respect to data creation and utilization. Process models can also be connected to data models via these elements. As an example, data models, UML class diagrams, or technical terms diagrams could be used to refine data objects in process models. In doing so, the process view could be integrated with the data view. This is important for seamless information systems development. Such an integration of different views is not part of the process modeling notation. It needs to be regulated by modeling conventions and suitable modeling tools.

11   Choreographies

Chapter 5 described how collaborations are modeled by inserting message flows between processes. In chapter 6, catching message events and event-based gateways were introduced. With these elements it is possible to specify that a process is waiting for a message, or that a certain path is selected based on which message has been received.

In many cases it is required to define the co-operation of different partners. This applies e.g. for business-to-business integration. Several partners connect their information systems in such a way that placing and fulfilling orders, as well as other business transactions, can be completely automated. In such a case, every company is responsible for its own process. It is necessary, however, that all involved partners agree on the messages to be exchanged.

In order to support this, black box pools can be used, i.e. pools without their processes displayed. Figure 160 shows the collaboration for creating an advertisement. In this diagram, the message flow between customer, advertising agency, and several designers can be seen.

Figure 160: Collaboration for creating an advertisement

The approximate temporal order can be deduced from the sequence of message flows from left to right. Nevertheless, this can be ambiguous, because no sequence flow is shown, and possible conditions and repetitions are not visible. In the example, an inquiry will usually be followed by an order, but not every case will involve change requests. If changes are requested, on the other hand, it is also possible to send more than one change request.

Presumably, only one of the two messages “Order” and “Rejection” will be sent within one process instance. Availability requests will probably be sent to several designers, but an assignment should be obviously sent to only one of these designers.

All these dependencies are not visible in the black box representation of the collaboration. One possibility for modeling the described logic is to include one or more public processes. In the example it is advantageous to model the public process of the advertising agency, since all messages of the other two partners are exchanged with the advertising agency (figure 161). If there was also a direct interaction between customer and designer, at least one additional process would be necessary.

Figure 161: Collaboration with public process of the advertising agency

From figure 161 the exact sequence of message exchanges can be deduced. It can be seen, for example, that it is possible to send several change requests, each of which is answered by the advertising agency with a new offer. It is also visible that several availability requests are sent to designers, but only one assignment. The model does not clearly show that the assignment is sent to one selected designer (and not perhaps one single assignment to all designers). For this it would be necessary either to model an additional pool for the selected designer, or to display the designer’s process, which could specify that all designers wait for the assignment for a certain time span. Only the designer who has received the assignment will send graphics. The others finish their processes.

In the presented process, many possibilities are not covered, e.g. it is assumed that the customer always reacts to an offer. Likewise, it is expected that a designer always sends graphics after having received an assignment. The case that one partner does not react within a certain period of time could be modeled with event-based gateways and timer events.

11.1   Choreography Diagrams

Choreography diagrams provide another possibility for modeling the temporal and logical sequence of message flows in the scenario described above. In these diagrams, the focus is on the message exchanges themselves. They are modeled as choreography activities.

Figure 162 contains the choreography for the example of creating an advertisement which has already been shown as collaboration. A choreography activity represents the exchange of one or more messages between two or more partners. In the simplest case it comprises sending only one message from one partner to another. An example is the choreography activity “Send Inquiry”, in which a customer sends the message “Inquiry” to an advertising agency. A choreography activity can also represent several message flows. Within “Get Approval”, first a message with an advertisement is sent from the advertising agency to the customer, and then the customer sends back a message with the approval.

Figure 162: Choreography for creating an advertisement

The presented choreography is easy to understand. First, an inquiry is sent (from the customer to the advertising agency), followed by an offer (from the advertising agency to the customer). Then there are three possibilities: Firstly, it is possible to send a change request. In this case, the choreography activity “Send Offer” will be repeated. Secondly, a rejection can be sent, and the choreography is finished. In the third case, an order is placed, followed by finding an appropriate designer. The activity “Find Designer” is carried out several times. Besides the advertising agency, each time one member of the group of designers is involved. Finally, the message exchanges “Handle Graphics Production” and “Get Approval” follow.

Each choreography activity is initiated from one of the partners by sending the first message. This initiating partner is shown in a white band at the upper or lower edge of the choreography activity symbol. The name of the other participant is placed in a shaded field at the other edge. The modeler can freely decide which partner is placed at the top and which at the bottom. If there are several choreography activities involving the same partners, the placement will usually be the same in all choreography activities. If an additional collaboration is modeled for the same scenario, it is advice-able to reflect the collaboration’s arrangement of pools. Accordingly, the choreography activities in figure 162 have the customer at the top and the advertising agency at the bottom, respectively the advertising agency at the top and the designers at the bottom.

The choreography activity “Find Designer” contains a multiple marker, i.e. it is carried out several times. Since the involved partner also has a multiple marker, the message exchange involves one single designer in each repetition. Here, the number of repetitions is known in advance. If this is not the case, the choreography activity receives the loop marker, which is already known from normal activities (figure 163).

Figure 163: A looping choreography activity

In this example there are only two partners involved in each choreography activity. For more partners, additional participant bands can be placed at the edges. Thereby always only one field is colored white, because only one of the partners initiates the message exchange by a first message. An example can be found in figure 167.

In a choreography diagram, a sequence flow is defined for the choreography activities. It is basically modeled like the sequence flow in normal processes.

However, some process modeling elements are not meaningful in choreography diagrams. Therefore they are not allowed here. For example, there are no message events within normal sequence flow, because message exchanges are contained in the choreography activities by definition. Likewise, the event-based gateway in figure 162 is not followed by events, but by choreography activities. This means that the path is selected by the choreography activity which is first started by its initiating message.

Figure 164: Choreography activities with message icons

If one wants to know which messages are exchanged in each choreography activity, small envelope symbols can be added and connected with the respective partner’s band (figure 164). The envelopes have the same colors as their partner bands. A white envelope signifies a message that initiates a choreography activity. The envelope symbols of the other messages are shaded.

11.2   Choreography within Collaboration

The choreography is closely related to the respective collaboration. If this relation should be shown, a choreography can be included into a collaboration diagram. Figure 165 shows a part of the advertisement process in which the choreography has been inserted into the collaboration diagram from figure 161.

Figure 165: Choreography within collaboration (fragment)

Since choreographies show the sequence of message exchanges, the choreography activities are placed between the pools. The related message flows run from pool to pool, as in normal collaboration diagrams. Here they run through the respective choreography activities. Thus, choreographies and collaborations are connected via the message flows.

The related partners therefore can be identified by the sources and the targets of the message flows, so the names of the partners need not to be shown in the choreography activities. They still contain the participants’ bands in order to remain clearly identifiable as choreography activities and to be distinguished from normal activities. Again, the initiating messages are blank; the others are shaded (figure 166).

Figure 166:Choreography activity with several messages, within a collaboration (fragment)

It can be helpful to include a choreography into a collaboration in order to validate that the logic of the message exchange within the own process is in accordance with the choreography.

11.3   Choreography Sub-Processes

Like normal activities, choreography activities can be organized hierarchically. Besides choreography tasks which cannot be decomposed further, there are choreography sub-processes which comprise more detailed choreographies. They are marked with a small ‘+’. In figure 167, the above choreography has been re-arranged into two sub-processes. They are shown in the collapsed state, i.e. the internal details of the sub-processes are not visible.

Figure 167: Choreography with collapsed sub-processes

“Process Order” is an example that illustrates how to draw a choreography activity with more than two participants.There is always only one white participant’s band, because only one participant initiates the choreography activity. Multiple participants’ bands are distributed in such a way that the difference of the numbers of bands at the top and of those at the bottom is not more than one. An initiating participant, with a white band, can also be placed together with one or more other participants with shaded bands, at the same edge.

For each sub-process there is a detailed choreography which can either be modeled in a separate choreography diagram, or inserted into the expanded sub-process symbol, as in figure 168. In order to make the different results of the first sub-process (“Order placed” or “Rejection sent”) visible on the upper level, an exclusive gateway is used. It selects the sequence flow according to the sub-process’s result.

Figure 168: Expanded choreography sub-process

Like normal sub-processes, choreography sub-processes can also be aborted by catching intermediate events which are attached to their boundaries (cf. chapter 8.1). It is also possible to model event sub-processes in choreographies (cf. chapter 8.5).

11.4   Gateways in Choreographies

Besides the event-based exclusive gateway it is also possible to use the normal, data-based gateways in a choreography. In figure 167, an exclusive gateway has been used. Inclusive, parallel, and complex gateways can also occur in a choreography.

The conditions at a gateway can only refer to contents of messages that have been exchanged earlier in the process. It is not possible to include other data for the decision. After all, a choreography only reflects the logic of the involved partners’ processes. Actually the decisions are taken in these partners’ processes. Based on the result of a decision, different messages are sent. In the example, the decision is indeed only based on the exchanged messages. “Order placed” will be true if a message with an order has been exchanged. The condition “Rejection sent” will be fulfilled if a message with a rejection has been sent instead.

The data required for a decision must also be known to those partners who initiate the choreography activities directly after the gateway. Otherwise they would not know whether they have to send a message.

As in normal processes, a default exit of an inclusive or an exclusive gateway can be defined by marking the outgoing sequence flow with a diagonal slash. For a choreography activity it is also possible to have outgoing conditional sequence flows.

11.5   Events in Choreographies

In principle it is possible to use not only untyped start and end events in choreographies, but also events with specific types of triggers, and intermediate events.

Triggers for start events can be signals, timer and multiple. Multiple start events are only allowed to combine signals and timers. Each participant can receive a broadcasted signal, and each can determine when a timer event occurs. Thus, all participants know about the occurrence of such an event, so that they can commence their common activities. Conditional events are also permitted, but only in event sub-processes. Signals, timer events, and multiple events may also be used for triggering an event sub-process.

There are only two possible end events: The untyped event and the terminate event. When using a terminate event, it is important that all participants are informed about the termination during the preceding choreography-activity. Otherwise the participants in parallel paths would not know about the termination and that they must not continue.

Normal sequence flows of a choreography can contain intermediate events of the following types: None, timer, conditional, link, signal, and multiple. When using a conditional intermediate event, it must be ensured that each participant has all information which is necessary to determine whether this event has occurred. Message events are not allowed, since message flows are already covered by choreography activities.

In order to abort a choreography activity, a catching intermediate event can be attached to its boundary. For this purpose, timer and conditional events, as well as signals and multiple events can be used. Thereby it must be ensured that all concerned participants learn about the occurrence of the respective event. It is also possible to attach message, cancel, or compensation events; however they must be attached to the band of that participant that receives the event. For an attached message intermediate event, the message must be sent by another participant who is also involved in the same choreography activity.

The BPMN 2.0 specification draft, on which this book is based, does not yet exhaustively describe the subject of events and event sub-processes in choreographies. There are no examples for the use of events, other than untyped start and end events. And it is not specified whether the non-interrupting versions of events can also be used in choreographies. Therefore, minor changes and clarifications can be expected for this topic in the final specification.

11.6   Calling Choreographies and Global Choreography Tasks

In chapter 7.5 the concept of the call activity was explained, which can be used for calling a global task or a process defined elsewhere.

The same concept is also available for choreographies. The border of a choreography activity which is used for a call is drawn with a thick line (figure 169). It can either call a global choreography task (left) or another choreography. A global choreography task is defined once and can be re-used in several choreographies. The call of another, independent choreography can either be shown in a collapsed (center) or expanded call activity (right).

Figure 169: Calls of global choreography tasks (left) and choreographies – collapsed (center) and expanded (right)

11.7   Use of Choreographies and Collaborations

As explained at the beginning of the chapter, the contents of a choreography can also be expressed by a collaboration. However, there are some reasons for using choreographies:

 •   In a choreography, the representation of message exchanges is independent from the partners’ processes. This is a better basis for agreements and contracts between partners. Based on a choreography, the required process interfaces of the partners can be developed. Thus it provides a starting point for designing or adapting each partner’s individual process so that the agreed cooperation is correctly supported.

 •   The sequence of message exchanges including splits, etc. becomes more clearly visible. In a collaboration, this information is not explicit, but it needs to be derived from one of the involved partner’s processes.

 •   Especially for large scenarios, the representation as a choreography is more compact and clear than a collaboration with at least one public process.

 •   Choreographies can be decomposed with choreography sub-processes. This also supports a compact and understandable presentation.

 •   If a complex scenario is modeled only with collaborations, it will be difficult to verify whether the processes’ behaviors match. Deadlocks may occur, e.g. if two processes both wait for a message from each other. Choreography diagrams can be more easily analyzed in respect to the feasibility of the message exchanges.

Especially for complex business-to-business scenarios, choreography diagrams can be interesting, e.g. in the context of electronic market places or for developing industry standards and guidelines for handling certain business transactions between partners.

However, if a company develops its internal processes and wants to show the message exchange with partners, usually a collaboration diagram will be the first choice.

12   Conversations

12.1   Conversation Diagram

A conversation diagram provides an overview of which partners of a certain domain co-operate on which tasks. In figure 170, three conversations can be seen. When processing an order for an advertisement, one customer works together with one advertising agency and several designers. On the other hand, a customer and an advertising agency can jointly run an advertising campaign. For this, they co-operate with several media. A designer can also be part of another inter-company activity: Together with a publisher he handles orders for illustrations.

Figure 170: Conversation diagram

In the end, such a conversation is realized by a series of message flows. The details can be modeled e.g. in a choreography diagram or a collaboration diagram. As an example, the message flow of the conversation “Process Order for Advertisement” is described by the collaboration diagram in figure 161, as well as by the choreography diagram in figure 162. However, it is not required for a collaboration or choreography diagram to specify exactly one conversation. It is also possible to combine the message flows from two or more conversations in one diagram.

12.2   Message Correlation

The contents of the message flows within one conversation are always related to each other. For example, all messages that are exchanged within one instance of the conversation “Process Order for Advertisement” relate to the same advertisement order. It is therefore possible to use the order ID for the correlation, i.e. the assignment of messages to a process instance. If a customer receives an advertisement for approval, he can determine the corresponding order – and thus the process instance – based on the order ID. All messages of a conversation have a common correlation.

A simple conversation which is not broken down into other conversations is called communication. Therefore, the lines are called communication links (the specification draft at some places also calls them conversation links). A conversation has always communication links to two or more participants.

If the end of a communication link is forked, multiple partners of the same type can be part of the communication, otherwise exactly one. “Process Order for Advertisement” has exactly one customer and one advertising agency as participants, but multiple designers. Therefore, the designer’s pool contains a multiple marker. However, having only the multiple marker in the pool is not sufficient. The conversation “Handle order for an illustration”, for example, has only one designer as participant. Therefore, the respective end of the communication link is not forked.

12.3   Hierarchies of Conversations

Besides communications, it is also possible to use sub-conversations. Similar to sub-processes they are marked with a ‘+’-sign. The details of a sub-conversation can be described in another conversation diagram. The diagram of a sub-conversation can only contain those participants who are linked to the sub-conversation within the parent diagram.

Figure 171: Conversation diagram for sub-conversation “Process Order for Advertisement”

Figure 171 shows the detailed conversation diagram for the sub-conversation “Process Order for Advertisement” As can be seen from this diagram, it is also possible to draw message flows directly into the conversation diagram. Other than collaboration diagrams, conversation diagrams are not allowed to show processes in the pools or choreographies between the pools.

The diagram contains those message flows that are related to the same order. To be more precise, they relate to the same inquiry. At the beginning, an order has not been placed yet, and not every inquiry turns into an order. Therefore, the common reference point is the inquiry.

Besides the explicitly displayed message flows between customer and advertising agency, the diagram also contains the communication “Assignment of Graphics Design”. All message flows of this communication are also related to the same inquiry, but this information is not sufficient for the advertising agency in order to assign all incoming messages correctly. This is due to the fact that availability requests are sent to several designers. The advertising agency has to correctly assign each incoming availability notice to the correct availability request. Thus, additional information is required for correlating these messages, e.g. the IDs of the availability requests. Therefore it is possible to define a separate communication for the message flows between advertising agency and designer.

The message exchanges of this communication can also be modeled in a collaboration diagram (figure 172) or in a choreography diagram (figure 173). Of course, it is also possible to show the message flows of the entire sub-conversation within a single diagram (figures 161 and 162 in the previous chapter).

Like sub-processes, sub-conversations can also be expanded, i.e. the hexagon is enlarged, and the detailed conversation is shown in its interior. However, it is graphically not easy to include, for example, the contents of figure 171 into an expanded sub-conversation in figure 170. Unfortunately, the BPMN specification draft does not contain any examples for expanded sub-conversations either.

Figure 172: Collaboration diagram for communication “Assignment of Graphics Design”

Figure 173: Choreography diagram for communication “Assignment of Graphics Design”

12.4   Calling Global Communications and Conversations

Similar to processes and choreographies it is possible within conversation diagrams to call conversations which have been defined elsewhere. The target of such a call can either be a global communication, or a global conversation. A global communication is defined independently from the conversation diagram from which it is called. A global conversation is specified by its own, independent conversation diagram. The border of a calling conversation is drawn with a thick line (figure 174).

Figure 174: Call of a global conversation (left) and of a global communication (right)

Since a called conversation is defined elsewhere, it may be necessary to map its participants and correlation information to the participants and correlation information of the conversation diagram from which it is called. This, however, is mainly a topic for automating inter-company processes. In business-oriented diagrams, such mappings can be deduced from the context, or they are explained by annotations.

12.5   Use of Conversation Diagrams

For most BPMN modelers, the exact definition of correlations and thus the modeling of conversations will not be a primary concern. In the context of SOA platforms and process engines for supporting complex inter-company processes between several partners, on the other hand, this topic can be quite important. For such problems, conversations can provide a useful view on the entire scenario.

In many other cases detailed correlation mechanisms are not of interest, but a conversation diagram can still be useful for a first overview of a network of partners. It can be seen which partners communicate with each other about which topics and business transactions. The details can then be modeled in choreography diagrams and collaboration diagrams.

13   Artifacts and Extensions of BPMN

13.1   Artifacts

BPMN models are focused on sequence and message flows, and on exchanged data. If other aspects relevant to a business process need to be mapped, it is possible to use artifacts.

So far, the BPMN specification has defined three standard types of artifacts: Annotations, groups, and associations. In addition to these, modelers and tool vendors are free to define their own artifacts, thus complementing BPMN with required constructs.

Annotations and groups have already been used in several examples, e.g. in figure 10 on p. 23 and figure 148 on p. 114.

Figure 175: Annotation

An annotation is used for adding explanations, remarks, etc. to a certain model element. Thus, annotations increase the understanding of a model. They do not have any effect on the control flow logic of the model.

On the other hand, annotations can also be used for documenting exit conditions of a loop, for example (cf. p. 85, figure 112). The exit conditions themselves naturally do have an effect on the control flow logic of the process. In BPMN, however, the exit conditions etc. are rather defined by attribute values of the respective modeling elements. The presentation in the model by annotations is only for documentation purposes. Usually they are not evaluated, e.g. by process engines.

An annotation is represented by an opening square bracket. It can be connected with any element in a BPMN model via a dotted association, e.g. for adding a comment or explanation to this element.

Associations must be distinguished from sequence and message flows. The representation by a dotted line is the same as that of a data association. The BPMN specification indeed differentiates between associations and data associations, but this difference is mainly relevant in the context of process execution. If the direction is relevant, an association can also be drawn with an arrow. Such a directed association is used for assigning a compensation activity to another activity (cf. p. 116, figure 149).

Figure 176: Group

A group is drawn as a rounded rectangle. Its border consists of a line with dots and dashes (figure 176). The dots and dashes must be clearly visible. Otherwise it could be confused with a sub-process.

Like all artifacts, a group is purely a graphical object without any relevance for the logic of a BPMN diagram. Therefore it is possible to use it without any restrictions, for highlighting interesting parts of a model, or for grouping elements which are related to each other. It is also allowed to draw groups across the borders of pools and lanes. As a purely graphical element, a group cannot be the source or the target of a sequence or message flow. Flows can rather cross group borders as desired.

13.2   Ways of Extending BPMN

As already mentioned, any BPMN construct can be graphically changed and adapted, as long as the original BPMN shape is still clearly recognizable and cannot be confused with other types of elements. For example, it is possible to use different colors and fonts. When using colors it must be considered that some information is denoted by different shadings. In choreography activities initiating partners are differentiated from the other partners by white and grey bands. When using other colors, the difference must be made clear by lighter and darker coloring.

It is also critical to change line styles and widths, since these usually have a meaning. For example, an end event must have a clearly thicker border than a start or intermediate event. Solid, dashed, and dotted lines must also be clearly visible, in order to distinguish between sequence flows, message flows, and associations. The solid borders of sub-processes and the dot and dash borders of groups must be preserved, as well.

The graphical symbols of modeling elements can be modified. However, the BPMN basic symbols must remain recognizable. An activity can be appended with an additional icon, but it must still be represented by a rounded rectangle. Likewise, the envelope symbol of a message event must not be replaced by an entirely different symbol. It must also remain visible whether the symbol in an event is filled or blank, because this depicts the difference between throwing and catching events.

Furthermore, for BPMN elements additional attributes can be defined. This is especially interesting, because the pre-defined attributes are mainly used for execution by a process engine. More business-related attributes, such as cost rates, can be added via BPMN’s extension mechanism.

Eventually it is also possible to define additional artifacts and connect them to the existing BPMN elements via associations. Maybe it is required to show which services are provided by an activity, or which software application or which machine is used for it. In many cases, the use of lanes for assigning organizational units or performing roles will not be sufficient. As an example, activities can be performed jointly by several people, or it needs to be differentiated between a role which is responsible for an activity and one which performs this activity.

The BPMN standard does not yet provide specific constructs for integrating such elements from other views of an enterprise model. By using self-defined artifacts it is easy to create this connection. BPMN explicitly allows for connecting artifacts with objects from other types of models, such as organizational charts or UML diagrams. When using a modeling tool, it needs to be checked whether it already contains such extensions. Alternatively it may allow for the definition of individual artifacts.

The described possibilities for extending BPMN are such that everybody who knows the BPMN standard can understand an extended BPMN model without any problems. Only the additional information contained in the individual extensions will not be clear to him without additional explanation.

However, if many individual extensions are used, it may be the case that a large portion of relevant information is contained in these extensions. In this case, many advantages of using a standard get lost, such as the common understanding and the exchangeability with other tools.

A   Bibliography

Briol P (2008) BPMN – the Business Process Modeling Notation, Pocket Handbook. Lulu, Morrisville

Debevoise T, Geneva R (2008) The MicroGuide to Process Modeling in BPMN. BookSurge, Charleston

Decker G, Schreiter T (2008) OMG releases BPMN 1.1 – What’s changed? http://www.inubit.com/bpmn

Franck A, Henninger T (2008) BPMN 2008. Ergebnisse einer Umfrage zum aktuellen Stand der praktischen Nutzung der BPMN im deutschsprachigen Raum. Camunda, Berlin. http://www.bpm-guide.de/wp-content/uploads/2008/10/BPMN-2008.pdf

Freund J, Rücker B, Henninger T (2010) Praxishandbuch BPMN. Hanser, München

Grosskopf A, Decker G, Weske M (2009) The Process. Business Modeling Using BPMN. Meghan-Kiffer, Tampa

Großkopf A (2007) xBPMN. Formal Control Flow Specification of a BPMN-based Process Execution Language. Master’s Thesis. Hasso Plattner-Institut, Universität Potsdam. http://www.myhpi.de/~alexander.grosskopf/xBPMN_thesis.pdf

Havey M (2005) Essential Business Process Modeling. O’Reilly, Sebastopol

Lienhard H, Meister B, Schaffroth M (2008) Geschäftsprozesse modellieren mit BPMN. eCH074. Version 1.0. Verein eCH, Zürich. http://www.ech.ch/vechweb/page?p=dossier&documentNumber=eCH-0074&documentVersion=1.00

OASIS (2007) Web Services Business Process Execution Language Version 2.0. OASIS Standard. http://docs.oasis-open.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.pdf

Object Management Group (2008) Business Process Model and Notation (BPMN). Version 1.2. http://www.omg.org/spec/BPMN/1.2

Object Management Group (2009) Business Process Model and Notation (BPMN) Specification. Version 2.0 – Beta 1. http://www.omg.org/spec/BPMN/2.0

Ouyang C, van der Aalst W, Dumas M, ter Hofstede A (2006) From Business Process Models to Process-oriented Software Systems: The BPMN to BPEL Way. Queensland University of Technology.

http://eprints.qut.edu.au/archive/00005266/01/5266.pdf

Recker J (2008) BPMN Modeling – Who, Where, How and Why. BPTrends.

http://www.businessprocesstrends.com/publicationfiles/05-08-ART-BPMN%20Survey-Recker-JR%20final.pdf

Russell N, ter Hofstede A, van der Aalst W, Mulyar N (2006): Workflow Control Patterns: A Revised View. BPM Center.

http://www.workflowpatterns.com/documentation/documents/BPM-06-22.pdf

Shapiro R (2008) XPDL 2.1 Integrating Process Interchange & BPMN. Whitepaper. Workflow Management Coalition.

https://portal.validar.com/SitePortal/2wA4NW/Link.html

Silver B (2007) BPMN and the Business Process Expert.

https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/10852310-ac6a-2a10-02be-d83f4d2dd647

Silver B (2009) BPMN Method and Style. Cody-Cassidy Press, Aptos

Weske M (2007) Business Process Management. Concepts, Languages, Architectures. Springer, Berlin Heidelberg

White S (2005) Using BPMN to Model a BPEL Process.

http://www.bpmn.org/Documents/Mapping_BPMN_to_BPEL_Example.pdf

White S, Miers D (2008) BPMN Modeling and Reference Guide: Understanding and Using BPMN. Future Strategies, Lighthouse Point

Wohed P, van der Aalst W, Dumas M, ter Hofstede A, Russell N (2006) Pattern-based Analysis of BPMN - An Extensive Evaluation of the Control-flow, the Data and the Resource Perspectives (revised version). BPM Center.

http://www.workflowpatterns.com/documentation/documents/BPM-06-17.pdf

Workflow Management Coalition (2008) Process Definition Interface – XML Process Definition Language. Document Number WFMC-TC-1025. Version 2.1a..

http://www.wfmc.org/index.php?option=com_docman&task=doc_download&Itemid=72&gid=132

zur Muehlen M, Recker, J (2008) How Much Language is Enough? Theoretical and Practical Use of the Business Process Modeling Notation. In Proceedings of the 20th International Conference on Advanced Information Systems Engineering. Montpellier, France..

http://eprints.qut.edu.au/archive/00012916/01/12916.pdf

B   BPMN in the Internet

BPMN Community

Discussions, tutorials, best practices, and reference processes. The open source modeler Oryx is integrated in the platform, so that community members can jointly create and discuss models.

http://www.bpmn-community.org

BPMN Corner

Website of the Business Process Technology research group at the Hasso-Plattner-Institute in Potsdam. Here BPMN stencils for Microsoft Visio can be found, as well as the free modeling tool Oryx, and several publications.

http://bpt.hpi.uni-potsdam.de/Public/BPMNCorner

BPMN.info

Weblog about BPMN.

http://www.bpmn.info

BPMN Poster

A poster with a BPMN 2.0 overview. Available in English, German, French, Spanish, Russian, and Swedish.

http://www.bpmb.de/index.php/BPMNPoster

BPMN.org

OMG’s BPMN website. Besides the official BPMN 1.2 specification and the BPMN 2.0 draft, there are some introductory articles and a list of tools that support BPMN.

http://www.bpmn.org

bpmresearch

Information about BPMN and other BPM-Standards by Michael zur Muehlen, Assistant Professor at the Stevens Institute of Technology in Hoboken, New Jersey. The site contains numerous articles and presentations, as well as links to various BPMN stencils for Microsoft Visio.

http://www.bpm-research.com

BPMS Watch

Bruce Silver’s weblog on business process management systems with many blog entries about BPMN und its further development.

http://www.brsilver.com/wordpress

Dive Into BPM

Here, the various BPMN elements are explained with animations (version 1.1), as well as the modeling of workflow patterns in BPMN.

http://www.diveintobpm.org

Frank Michael Kraft’s Blog

Frank Michael Kraft from SAP is actively involved in the BPMN development.

http://www.bpmnforum.net

Process Modeling with BPMN – Article Series

This series of six articles by Bruce Silver gives a first introduction into BPMN (Version 1.1).

https://www.sdn.sap.com/irj/sdn/wiki?path=/display/BPX/Process+Modeling+with+BPMN+-+Article+Series

Workflow Patterns

Homepage of the Workflow Patterns Initiative co-ordinated by Professor Wil van der Aalst (Eindhoven University of Technology) and Professor Arthur te Hofstede (Queensland University of Technology). Here, descriptions of the different workflow patterns can be found, and also articles on their modeling in BPMN.

http://www.workflowpatterns.com

Groups in Social Networks

There are several groups on BPMN in LinkedIn, XING, and Google Groups.

Index

Abstract task 91

Activity 17, 18, 43, 79

Activity diagram 16

Ad-hoc marker 89

Ad-hoc sub-process 89

Agreement 137

Alternative paths 24

AND 27

Annotation 23, 81, 86, 142

ARIS 10

Artifact 142, 144

Association 57, 142, 144

Attached event 99

Attached interrupting intermediate event 99

Attached non-interrupting event 102

Attribute 23, 80, 95, 142, 143

Black box 53, 55

Black box pool 128

BPEL See Business Process Execution Language

BPEL process execution conformance 13

BPMI See Business Process Management Initiative

BPML See Business Process Modeling Language

BPMN See Business Process Model and Notation

BPMN 1.0 11

BPMN 1.1 11

BPMN 1.2 11

BPMN 2.0 11, 13, 14, 15

BPMN 2.0 specification 136

BPMN conformance 13

BPMN specification 10, 15

BPMS See Business process management system

Business model 13

Business process 9

Business Process Execution Language, BPEL 9, 10, 13, 14

Business Process Management Initiative, BPMI 10

Business process management system, BPMS 9, 10, 13, 55

Business Process Model and Notation, BPMN 10, 13, 14

Business process modeling 9, 14

Business Process Modeling Language, BPML 10

Business Process Modeling Notation 13

Business rule management system 91

Business rule task 90, 92

Business-to-business 137

Business-to-business integration 128

Call activity 91, 93, 125, 136, 137

Called process 95, 97

Cancel end event 117

Cancel intermediate event 117

Cancellation 121

Catching error event 103, 106

Catching escalation event 106

Catching event 68

Catching intermediate event 71, 76, 135

Catching message event 124

Catching message intermediate event 59, 62, 72, 77

Catching message start event 61, 63, 94

Choreography 46, 130, 132, 134, 136, 137

Choreography activity 130, 131, 132, 133

Choreography diagram 46, 130, 131, 134, 137, 138

Choreography modeling conformance 13

Choreography sub-process 133, 137

Choreography task 133

Class diagram 127

Collaboration 46, 48, 55, 59, 128, 131, 132, 137

Collaboration diagram 47, 55, 56, 57, 133, 138

Collapsed event sub-process 111

Collapsed sub-process 83

Collection 88, 124

Color 143

Communication 139, 140

Communication link 139

Compensating activity 115

Compensation 113, 115, 118, 121

Compensation activity 117, 118, 119

Compensation association 115

Compensation event 111, 118

Compensation intermediate event 115

Compensation start event 119

Complex gateway 24, 34

Compliance 9

Condition 17, 23, 26, 32, 37, 43, 58, 80, 86, 135, 142

Conditional event 63

Conditional flow 81

Conditional intermediate event 73

Conditional sequence flow 36, 38, 135

Contract 137

Control flow 17

Conversation 138, 139, 141

Conversation diagram 138, 139, 141

Conversation link 139

Correlation 72, 139, 141

Data 57, 80

Data association 123, 124, 125, 127

Data flow 122

Data input 126, 127

Data object 76, 122, 124, 125, 127

Data output 126, 127

Data pool 122

Data store 123, 125

Data structure 57

Data transfer 122

Data view 127

Data-based exclusive gateway 26

Data-based gateway 76

Deadlock 137

Decision 17, 25, 42, 80, 135

Default 26, 33, 38, 135

Document 57

E-government 10

Embedded activity 92

End event 18, 19, 58, 68, 80, 84

End-to-end process 56

Enterprise model 144

Envelope symbol 57, 132

EPC See Event-driven process chain

Error 58, 103, 106

Error event 103

Error intermediate event 117

Error start event 110

Escalation 109

Escalation event 106

Escalation intermediate event 106

Event 58, 135

Event sub-process 109, 111, 119

Event-based decision 76

Event-based exclusive gateway 62, 76

Event-based gateway 131

Event-based parallel gateway 78

Event-driven process chain, EPC 10

Exception 14, 99, 115, 121

Exception flow 99, 106, 115, 121

Exchange format 12

Exchange protocol 50

Exclusive gateway 17, 19, 24, 37, 61, 76

Exclusive OR 17

Exclusive split 37

Executable model 13, 57

Executable process 10, 13, 14

Executable workflow 121

Execution semantics 13, 14

Exit condition 85

Expanded event sub-process 111

Expanded sub-process 83

Explicit end event 70

Explicit start event 68

Extension 23, 142, 143

Flow chart 9, 16

Flow logic 20

Font 143

Gateway 17, 24, 42, 80, 135

Global choreography task 136

Global communication 141

Global conversation 141

Global task 92, 95

Global variable 95

Governance, Risk, and Compliance, GRC 9

Graphics software 9

GRC See Governance, Risk, and Compliance

Group 115, 142, 143

Hierarchical process model 83

Higher-level process 80

Icon 143

Implicit end event 70, 83

Implicit pool 17, 48

Implicit start event 67, 71, 78, 83

Inclusive gateway 24, 30, 36

Inclusive OR 31

Inclusive split 36

Information system 9, 56

Input data 122

Inter-company process 56, 141

Interface 56, 95, 97

Intermediate error event 106

Intermediate event 58, 59, 61, 62, 71, 78

Interrupting escalation event 107

Interrupting event 99

Interrupting intermediate event 99

Join 24

Lane 17, 49, 55, 94

Line style 143

Link intermediate event 73

List 124

Long-running transaction 113

Loop 19, 84, 85, 88, 142

Loop activity 85

Loop marker 131

Machine 144

Manual task 91

Matrix 21

Merge 24, 36, 39, 42, 77

Message 46, 47, 53, 57

Message content 57

Message correlation 138

Message exchange 51, 57, 130, 133, 137

Message flow 46, 48, 49, 55, 57, 59, 122, 133, 138, 140

Metamodel 12, 13

Model 9

Model hierarchy 84

Modeling convention 14, 43, 121, 127

Modeling style 43

Modeling tool 9, 23, 127, 144

Multi-instance activity 85, 87, 88

Multi-instance participant 54

Multiple data object 124, 126

Multiple end event 70

Multiple event 64

Multiple intermediate event 74

Multiple marker 131, 139

Multiple start event 64

Nested lanes 21

Non-interrupting escalation event 107

Non-interrupting intermediate event 101

Non-interrupting start event 109

Notation 9

Object Management Group, OMG 10

Object-oriented software design 10

Off-page connector 73

OMG See Object Management Group

OR 31

Organizational chart 144

Organizational unit 17, 144

Output data 122

Parallel gateway 24, 27, 38, 69, 83

Parallel multiple event 64

Parallel multiple intermediate event 75

Parallel multiple start event 78

Parallel paths 27

Parallel split 38

Parameter 95

Parent process 63, 80, 81, 95

Participant 131, 134, 141

Participant band 131

Persistent data 123

Pool 16, 20, 46, 47, 49, 55, 133

Presentation software 9

Private process 53

Process 47

Process control 43

Process definition 28

Process documentation 14

Process engine 13, 43, 55, 81, 86, 117, 141

Process execution 13, 127

Process execution conformance 13

Process instance 28, 56, 64

Process interface 137

Process management 56

Process model 16

Process modeling conformance 13

Public process 53, 129

Quality management 9

Receive activity 77

Receive task 90

Re-usable process 97

Re-usable sub-process 95

Risk management 9

Role 144

Rule 91

Safety 9

SAP 10

Scope 84

Script task 91

Send task 90

Sequence flow 17, 18, 20, 36, 38, 49, 55, 131, 136

Service provider 95

Service task 90

Service-oriented architecture, SOA 14

Shared service center 95

Signal end evend 70

Signal intermediate event 73

Signal start event 63

SOA See Service-oriented architecture

SOA platform 141

Software application 144

Split 17, 24, 36, 42, 77

Start event 17, 18, 28, 58, 59, 62, 79, 84, 94

State 75

Statechart diagram 75

Sub-conversation 139

Sub-process 63, 66, 79, 80, 83, 95, 96, 103

Swimlane 17

Symbol 143

System development 9

Task 79, 83

Task type 90

Technical terms diagram 127

Terminate end event 118

Terminate event 68, 70

Throwing compensation intermediate event 118

Throwing compensation end event 118

Throwing error event 103, 106

Throwing escalation event 106, 109

Throwing event 68

Throwing intermediate compensation event 119

Throwing intermediate event 71

Throwing message end event 61, 68

Throwing message event 124

Throwing message intermediate event 59, 62, 71

Timer event 62

Timer intermediate event 72

Timer start event 63

Token 18, 27, 39, 59, 79, 99

Token flow 28

Top-level process 83

Transaction 113, 115, 117, 118, 121

Transaction sub-process 118

Trigger 58, 62

UML See Unified Modeling Language

Unified Modeling Language, UML 10, 12, 75, 127, 144

Untyped end event 62, 68, 70, 81

Untyped event 94

Untyped intermediate event 75

Untyped start event 62, 63, 64, 81

User task 90

View 144

Virtual enterprise 56

Visibility 93

Web service 49

Workflow 13

Workflow management 14

Workflow management system 9, 55, 62

Workflow modeling 14

Workflow pattern 15

XML Process Definition Language,

XPDL 9, 12

XML schema definition 127

XOR 17, 26

XPath 86

XPDL See XML Process Definition Language

The Author

Thomas Allweyer studied Engineering at Stuttgart University and Brunel University (West London). He earned his doctoral degree at the Institue for Information Systems at the University of Saarland.

At IDS Scheer AG (now a division of Software AG) he was a product manager for the ARIS modeling tools and a consultant. After that he became process manager at emaro AG, a joint venture of Deutsche Bank and SAP. Currently he is a professor for enterprise modeling at Fachhochschule Kaiserslautern (University of Applied Sciences).

Thomas Allweyer is the author of several papers and a textbook on business process management. Besides his university activities he is also a consultant, and he frequently holds seminars and trainings for well-known companies, especially on business process management – and BPMN, of course.

In his weblog he regularly blogs about current developments in business process management (www.kurze-prozesse.de, in German).