Business Process Diagram Connecting Objects

This section defines the graphical objects used to connect two objects together (i.e., the connecting lines of the Diagram) and how the flow progresses through a Process (i.e., through a straight sequence or through the creation of parallel or alternative paths).

Graphical Connecting Objects

There are two ways of Connecting Objects in BPMN: a Flow, either sequence or message, and an Association. Sequence Flow and Message Flow, to a certain extent, represent orthogonal aspects of the business processes depicted in a model, although they both affect the performance of activities within a Process. In keeping with this, Sequence Flow will generally flow in a single direction (either left to right, or top to bottom) and Message Flow will flow at a 90° from the Sequence Flow. This will help clarify the relationships for a Diagram that contains both Sequence Flow and Message Flow. However, BPMN does not restrict this relationship between the two types of Flow. A modeler can connect either type of Flow in any direction at any place in the Diagram.

The next three sections will describe how these types of connections function in BPMN.

Common Connecting Object Attributes

The following table displays the set of attributes common to Connecting Objects (Sequence Flow, Message Flow, and Association), and which extends the set of common graphical object attributes (see See Common Graphical Object Attributes.):

Attributes

Description

Name (0-1) : String

Name is an optional attribute that is text description of the Connecting Object.

Source : Object

 

Source is an attribute that identifies which Flow Object the Connecting Object is connected from. Note: there are restrictions as to what objects Sequence Flow and Message Flow can connect. Refer to the Sequence Flow Connections section and the Message Flow Connections section for each Flow Object, Swimlane, and Artifact.

Target : Object

Target is an attribute that identifies which Flow Object the Connecting Object is connected to. Note: there are restrictions as to what objects Sequence Flow and Message Flow can connect. Refer to the Sequence Flow Connections section and the Message Flow Connections section for each Flow Object, Swimlane, and Artifact.

Common Connecting Object Attributes

Changes Since 1.0 Version

These are the changes since the last publicly released version:

·          

 

Sequence Flow

A Sequence Flow is used to show the order that activities will be performed in a Process. Each Flow has only one source and only one target. The source and target must be from the set of the following Flow Objects: Events (Start, Intermediate, and End), Activities (Task and Sub-Process), and Gateways. During performance (or simulation) of the process, a Token will leave the source Flow Object, traverse down the Sequence Flow, and enter the target Flow Object.

·         A Sequence Flow is line with a solid arrowhead that MUST be drawn with a solid single line (as seen in See A Sequence Flow.).

·   The use of text, color, and size for Sequence Flow MUST follow the rules defined in See Use of Text, Color, Size, and Lines in a Diagram..

 

A Sequence Flow

BPMN does not use the term "Control Flow" when referring the lines represented by Sequence Flow or Message Flow. The start of an activity is "controlled" not only by Sequence Flow (the order of activities), but also by Message Flow (a message arriving), as well as other process factors, such as scheduled resources. Artifacts can be Associated with activities to show some of these other factors. Thus, we are using a more specific term, "Sequence Flow," since these lines mainly illustrate the sequence that activities will be performed.

·         A Sequence Flow MAY have a conditional expression attribute, depending on its source object.

 

This means that the condition expression must be evaluated before a Token can be generated and then leave the source object to traverse the Flow. The conditions are usually associated with Decision Gateways, but can also be used with activities.

·         If the source of the Sequence Flow is an activity, rather than Gateway, then a Conditional Marker, shaped as a "mini-diamond"," MUST be used at the beginning of the Sequence Flow (see See A Conditional Sequence Flow.).

 

The diamond shape is used to relate the behavior to a Gateway (also a diamond) that controls the flow within a Process. More information about how conditional Sequence Flow are used can be found in See Splitting Flow..

 

A Conditional Sequence Flow

A Sequence Flow that has an Exclusive Data-Based Gateway or an activity as its source can also be defined with a condition expression of Default. Such Sequence Flow will have a marker to show that it is a Default flow.

·         The Default Marker MUST be a backslash near the beginning of the line (see See A Default Sequence Flow.).

 

A Default Sequence Flow

Attributes

The following table displays the set of attributes of a Sequence Flow, and which extends the set of common Connecting Object attributes (see See Common Connecting Object Attributes.):

Attributes

Description

ConditionType (None | Expression | Default) None : String

By default, the ConditionType of a Sequence Flow is None. This means that there is no evaluation at runtime to determine whether or not the Sequence Flow will be used. Once a Token is ready to traverse the Sequence Flow (i.e., the Source is an activity that has completed), then the Token will do so. The normal, uncontrolled use of Sequence Flow, in a sequence of activities, will have a None ConditionType (see See Workflow Pattern #1: Sequence.). A None ConditionType MUST NOT be used if the Source of the Sequence Flow is an Exclusive Data-Based or Inclusive Gateway.

The ConditionType attribute MAY be set to Expression if the Source of the Sequence Flow is a Task, a Sub-Process, or a Gateway of type Exclusive-Data-Based or Inclusive.

If the ConditionType attribute is set to Expression, then a condition marker SHALL be added to the line if the Sequence Flow is outgoing from an activity (see See A Conditional Sequence Flow.). However, a condition indicator MUST NOT be added to the line if the Sequence Flow is outgoing from a Gateway.

An Expression ConditionType MUST NOT be used if the Source of the Sequence Flow is an Event-Based Exclusive Gateway, a Complex Gateway, a Parallel Gateway, a Start Event, or an Intermediate Event. In addition, an Expression ConditionType MUST NOT be used if the Sequence Flow is associated with the Default Gate of a Gateway.

The ConditionType attribute MAY be set to Default only if the Source of the Sequence Flow is an activity or an Exclusive Data-Based Gateway. If the ConditionType is Default, then the Default marker SHALL be displayed (see See A Default Sequence Flow.).

[ConditionType is set to Expression only] ConditionExpression: Expression

If the ConditionType attribute is set to Expression, then the ConditionExpression attribute MUST be defined as a valid expression. The expression will be evaluated at runtime. If the result of the evaluation is TRUE, then a Token will be generated and will traverse the Sequence--Subject to any constraints imposed by a Source that is a Gateway.

Quantity 1 : Integer

The default value is 1. The value MUST NOT be less than 1. This attribute defines the number of Tokens that will be generated down the Sequence Flow.

Sequence Flow Attributes

Changes Since 1.0 Version

These are the changes since the last publicly released version:

·          

 

 

Message Flow

A Message Flow is used to show the flow of messages between two entities that are prepared to send and receive them. In BPMN, two separate Pools in the Diagram will represent the two entities. Thus,

·         Message Flow MUST connect two Pools, either to the Pools themselves or to Flow Objects within the Pools. They cannot connect two objects within the same Pool.

·         A Message Flow is line with a open arrowhead that MUST be drawn with a dashed single black line (as seen in See A Message Flow.).

·   The use of text, color, size, and lines for Message Flow MUST follow the rules defined in See Use of Text, Color, Size, and Lines in a Diagram..

 

A Message Flow

The Message Flow can connect directly to the boundary of a Pool (See See Message Flow connecting to the boundaries of two Pools.),

especially if the Pool does not have any process details within (e.g., is a "Black Box").

 

Message Flow connecting to the boundaries of two Pools

A Message Flow can also cross the boundary of a Pool and connect to a Flow Object within that Pool (see See Message Flow connecting to Flow Objects within two Pools.).

Message Flow connecting to Flow Objects within two Pools

If there is an Expanded Sub-Process in one of the Pools, then the message flow can be connected to either the boundary of the Sub-Process or to objects within the Sub-Process. If the Message Flow is connected to the boundary to the Expanded Sub-Process, then this is equivalent to connecting to the Start Event for incoming Message Flow or the End Event for outgoing Message Flow (see See Message Flow connecting to boundary of Sub-Process and Internal objects.).

Message Flow connecting to boundary of Sub-Process and Internal objects

Attributes

The following table displays the identified attributes of a Message Flow, and which extends the set of common Connecting Object attributes (see See Common Connecting Object Attributes.):

Attributes

Description

Message (0-1) : Message

Message is an optional attribute that identifies the Message that is being sent. The attributes of a Message can be found in the See Message..

Message Flow Attributes

Changes Since 1.0 Version

These are the changes since the last publicly released version:

·          

 

Association

An Association is used to associate information and Artifacts with Flow Objects. Text and graphical non-Flow Objects can be associated with the Flow Objects and Flow. An Association is also used to show the activities used to compensate for an activity. More information about compensation can be found See Compensation Association..

·         An Association Flow is line that MUST be drawn with a dotted single black line (as seen in See An Association.).

·   The use of text, color, size, and lines for an Association MUST follow the rules defined in See Use of Text, Color, Size, and Lines in a Diagram..

 

An Association

If there is a reason to put directionality on the association then:

·         A line arrowhead MAY be added to the Association line. (see See A directional Association.).

 

A directional Association is often used with Data Objects to show that a Data Object is either an input to or an output from an activity.

A directional Association

An Association is used to connect user-defined text (an Annotation) with a Flow Object (see See An Association of Text Annotation.).

An Association of Text Annotation

An Association is also used to associate Data Objects with other objects (see See An Association connecting a Data Object with a Flow.). A Data Object is used to show how documents are used throughout a Process. See Data Object. for more information on Data Objects.

An Association connecting a Data Object with a Flow

Attributes

The following table displays the identified attributes of a Association, and which extends the set of common Connecting Object attributes (see See Common Connecting Object Attributes.):

Attributes

Description

Direction (None | To | From | Both) None : String

Direction is an attribute that defines whether or not the Association shows any directionality with an arrowhead. The default is None (no arrowhead). A value of To means that the arrowhead SHALL be at the Source object. A value of From means that the arrowhead SHALL be at the Target Artifact. A value of Both means that there SHALL be an arrowhead at both ends of the Association line.

Association Attributes

Changes Since 1.0 Version

These are the changes since the last publicly released version:

·          

 

 

 

 

 

 

 

 

 

Sequence Flow Mechanisms

The Sequence Flow mechanisms described in the following sections are divided into four types: Normal, Exception, Link Events, and Ad Hoc (no flow). Within these types of flow, BPMN can be related to specific "Workflow Patterns1." These patterns began as development work by Wil van der Aalst, Arthur ter Hofstede, Bartek Kiepuszewski, and Alistair Barros2. Twenty-one patterns have been defined as a way to document specific behavior that can be executed by a BPM system. These patterns range from very simple behavior to very complex business behavior. These patterns are useful in that they provide a comprehensive checklist of behavior that should be accounted for by BPM system. Therefore, some of these patterns will be illustrated with BPMN in the following sections to show how BPMN can handle the simple and complex requirements for Business Process Modeling.

Normal Flow

Normal Sequence Flow refers to the flow that originates from a Start Event and continues through activities via alternative and parallel paths until it ends at an End Event. The simplest type of flow within a Process is a sequence, which defines a dependencies of order for a series of activities that will be performed (sequentially). A sequence is also Workflow Pattern #1 -- Sequence3 (see See Workflow Pattern #1: Sequence.).

Workflow Pattern #1: Sequence

As stated previously, the normal Sequence Flow should be completely exposed and no flow behavior hidden. This means that a viewer of a BPMN Diagram will be able to trace through a series of Flow Objects and Sequence Flow, from the beginning to the end of a given level of the Process without any gaps or hidden "jumps" (see See A Process with Normal Flow.). In this figure, Sequence Flow connect all the objects in the Diagram, from the Start Event to the End Event. The behavior of the Process shown will reflect the connections as shown and not skip any activities or "jump" to the end of the Process.

A Process with Normal Flow

As the Process continues through the series of Sequence Flow, control mechanisms may divide or combine the Sequence Flow as a means of describing complex behavior. There are control mechanisms for dividing (forking and splitting) and for combining (joining and merging) Sequence Flow. Gateways and conditional Sequence Flow are used to accomplish the dividing and combining of flow. It is possible that there may be gaps in the Sequence Flow if Gateways and/or conditional Sequence Flow are not configured to cover all performance possibilities. In this case, a model that violates the flow traceability requirement will be considered an invalid model. Presumably, process development software or BPM test environments will be able to test a process model to ensure that the model is valid.

A casual look at the definitions of the English terms for these mechanisms (e.g., forking and splitting) would indicate that each pair of terms mean basically the same thing. However, their effect on the behavior of a Process is quite different. We will continue to use these English terms but will provide specific definitions about how they affect the performance of the process in the next few sections of this specification. In addition, we will relate these BPMN terms to the terms OR-Split (for split), Or-Join (for merge), AND-Split (for fork), and AND-Join (for join), as defined by the Workflow Management Coalition.4

The use of an expanded Sub-Process in a Process (see See An Expanded Sub-Process without a Start Event and End Event.), which is the inclusion of one level of the Process within another Level of the Process, can sometimes break the traceability of the flow through the lines of the Diagram. The Sub-Process is not required to have a Start Event and an End Event. This means that the series of Sequence Flow will be disrupted from border of the Expanded Sub-Process to the first object within the Expanded Sub-Process. The flow will "jump" to the first object within the Expanded Sub-Process. Expanded Sub-Processes will often be used, as seen in the figure, to include exception handling. A requirement that modelers always include a Start Event and End Event within Expanded Sub-Processes would mainly add clutter to the Diagram without necessarily adding to the clarity of the Diagram. Thus, BPMN does not require the use of Start Events and End Events to satisfy the traceability of a Diagram that contains multiple levels.

An Expanded Sub-Process without a Start Event and End Event

Of course, the Start and End Events for an Expanded Sub-Process can be included and placed entirely within its boundaries (see See An Expanded Sub-Process with a Start Event and End Event Internal.). This type of model will also have a break from a completely traceable Sequence Flow as the flow continues from one Process level to another.

An Expanded Sub-Process with a Start Event and End Event Internal

However, a modeler may want to ensure the traceability of a Diagram and can use a Start Event and End Event in an Expanded Sub-Process. One way to do this would be to attach these events to the boundary of the Expanded Sub-Process (see See An Expanded Sub-Process with a Start Event and End Event Attached to Boundary.). The incoming Sequence Flow to the Sub-Process can be attached directly to the Start Event instead of the boundary of the Sub-Process. Likewise, the outgoing Sequence Flow from the Sub-Process can connect from the End Event instead of the boundary of the Sub-Process. Doing this, the Normal Flow can be traced throughout a multi-level Process.

Technically, the Start and End Events still reside within the Sub-Process. The use of this modeling technic is just a graphical short-cut to a more accurate depiction of the Process (i.e., as shown in See An Expanded Sub-Process with a Start Event and End Event Internal.. Therefore, the Sequence Flow connecting to the Start Event and connecting from the End Event do not violate the Sequence Flow connection rules (as defined in See Sequence Flow Connections. and Sequence Flow Connections)

An Expanded Sub-Process with a Start Event and End Event Attached to Boundary

When dealing with Exceptions and Compensation, the traceability requirement is also relaxed (See Exception Flow. and Compensation Association).

Forking Flow

BPMN uses the term forking to refer to the dividing of a path into two or more parallel paths (also known as an AND-Split). It is a mechanism that will allow activities to be performed concurrently, rather than sequentially. This is also Workflow Pattern #2 -- Parallel Split5. BPMN provides three configurations that provide forking.

The first mechanism to create a fork is simple: a Flow Object can have two or more outgoing Sequence Flow (see See Workflow Pattern #2: Parallel Split -- Version 1.). A special flow control object is not used to fork the path in this case, since it is considered uncontrolled flow; that is, flow will proceed down each path without any dependencies or conditions--there is no Gateway that controls the flow. Forking Sequence Flow can be generated from a Task, Sub-Process, or a Start Event.

Workflow Pattern #2: Parallel Split -- Version 1

The second mechanism uses a Parallel Gateway (see See Workflow Pattern #2: Parallel Split -- Version 3.). For situations as shown in the See Workflow Pattern #2: Parallel Split -- Version 2., a Gateway is not needed, since the same behavior can be created through multiple outgoing Sequence Flow, as in See Workflow Pattern #2: Parallel Split -- Version 1.. However, some modelers and modeling tools may use a forking Gateway as a "best practice." See Parallel Gateways (AND). for more information on Parallel Gateways.

Workflow Pattern #2: Parallel Split -- Version 2

Even when not required as a "best practice," there are situations were the Parallel Gateway provides a useful indicator of the behavior of the Process. See The Creation of Parallel Paths with a Gateway. shows how a forking Gateway is used when the output of an Exclusive Decision requires that multiple activities will be performed based on one condition (Gate).

The Creation of Parallel Paths with a Gateway

While multiple conditional Sequence Flow, each with the exact same condition expression (see See The Creation of Parallel Paths with Equivalent Conditions.), could be used with an Inclusive Gateway to create the behavior, the use of a forking Gateway makes the behavior much more obvious.

 

The Creation of Parallel Paths with Equivalent Conditions

This third version of the forking mechanism uses an Expanded Sub-Process to group a set of activities to be performed in parallel (see See Workflow Pattern #2: Parallel Split -- Version 3.). The Sub-Process does not include a Start and End Event and displays the activities "floating" within. A configuration like this can be called a "parallel box" and can be a compact and less cluttered way of showing parallelism in the Process. The capability to model in this way is the reason that Start and End Events are optional in BPMN.

Workflow Pattern #2: Parallel Split -- Version 3

Most of the time, the paths that have been divided with a fork are combined back together through a join (refer to the next section) and synchronized before the flow will continue. However, BPMN provides the flexibility for advanced methods to handle complex process situations. Thus, the exact behavior will be determined by the configuration of the Sequence Flow and the Gateways that are used.

Joining Flow

BPMN uses the term joining to refer to the combining of two or more parallel paths into one path (also known as an AND-Join). A Parallel Gateway is used to synchronize two or more incoming Sequence Flow (see See Workflow Pattern #3: Synchronization -- Version 1.). In general, this means that Tokens created at a fork will travel down parallel paths and then meet at the Parallel Gateway. From there, only one Token will continue. This is also Workflow Pattern #3 -- Synchronization6. See Parallel Gateways (AND). for more information on Parallel Gateways.

Workflow Pattern #3: Synchronization -- Version 1

Another mechanism for synchronization is the completion of a Sub-Process (see See Workflow Pattern #3: Synchronization -- Version 2.). If there are parallel paths within the Sub-Process that are not synchronized with an Parallel Gateway, then they will eventually reach an End Event (even if the End Event is implied). The default behavior of a Sub-Process is to wait until all activity within has been completed before the flow will move back up to a higher level Process. Thus, the completion of a Sub-Process is a synchronization point.

Workflow Pattern #3: Synchronization -- Version 2

There is no specific correlation between the joining of a set of parallel paths and the forking that created the parallel paths. For example, an activity may have three outgoing Sequence Flow, which creates a fork of three parallel paths, but these three paths do not need to be joined at the same object. See The Fork-Join Relationship is not Fixed. shows that two of three parallel paths are joined at Task "F." All of the paths eventually will be joined, but this can happen through any combination of objects, including lone End Events. In fact, each path could end with a separate End Event, and then be synchronized as mentioned above.

The Fork-Join Relationship is not Fixed

Thus, for parallel flow, BPMN contrasts with BPEL4WS, which is mainly block structured. A BPEL4WS flow, which maps to a set of BPMN parallel activities, is a specific block structure that has a well-defined boundary. While there are no obvious boundaries to the parallel paths created by a fork, the appropriate boundaries can be derived by an evaluation of the configuration of Sequence Flow that follow the fork. The locations in the Process where Tokens of the same TokenId and all the appropriate SubTokenIds are joined with through multiple incoming Sequence Flow will determine the boundaries for a specific block of parallel activities. The boundary may in fact be the end of the Process. More detail on the evaluation of BPEL4WS element boundaries can be found See Mapping to BPEL4WS..

Splitting Flow

BPMN uses the term splitting to refer to the dividing of a path into two or more alternative paths (also known as an OR-Split). It is a place in the Process where a question is asked, and the answer determines which of a set of paths is taken. It is the "fork in the road" where a traveler, in this case a Token, can take only one of the forks (not to be confused with forking--see below).

The general concept of splitting the flow is usually referring to as a Decision. In traditional flow charting methodologies, Decisions are depicted as diamonds and usually are exclusive. BPMN also uses a diamond to leverage the familiarity of the shape, but extends the use of the diamond to handle the complex behavior of business processes (which cannot be handled by traditional flow charts). The diamond shape is used in both Gateways and the beginning of a conditional Sequence Flow (when exiting an activity). Thus, when readers of BPD see a diamond, they know that the flow will be controlled in some way and will not just pass from one activity to another. The location of the mini-diamond and the internal indicators within the Gateways will indicate how the flow will be controlled.

There are multiple configurations to split the flow within BPMN so that different types of complex behavior can be modeled. Conditional Sequence Flow and three types of Gateways (Exclusive, Inclusive, and Complex) are used to split the flow. See Sequence Flow. for details on conditional Sequence Flow. See Gateways. for details on the Gateways.

There are two basic mechanism for making the Decision during the performance of the Process: the first is an evaluation of a condition expression. There are three variations of this mechanism: Exclusive, Inclusive, and Complex. The first variation, an Exclusive Decision, is the same as Workflow Pattern #4 -- Exclusive Choice7 (see See A Data-Based Decision Example -- Workflow Pattern #4 -- Exclusive Choice.). See Data-Based. for more information on Data-Based Exclusive Gateways.

A Data-Based Decision Example -- Workflow Pattern #4 -- Exclusive Choice

 

The second type of expression evaluation is the Inclusive Decision, which is also Workflow Pattern #6 -- Multiple Choice8. There are two configurations of the Inclusive Decision. The first type of Inclusive Decisions uses conditional Sequence Flow from an Activity (see See Workflow Pattern #6 -- Multiple Choice -- Version 1.).

Workflow Pattern #6 -- Multiple Choice -- Version 1

The second type of Inclusive Decisions uses an Inclusive Gateway to control the flow (see See Workflow Pattern #6 -- Multiple Choice -- Version 2.). See Inclusive Gateways (OR). for more information on Inclusive Gateways.

Workflow Pattern #6 -- Multiple Choice -- Version 2

The third type of expression evaluation is the Complex Decision (see See A Complex Decision (Gateway).). See Complex Gateways. for more information on Complex Gateways.

 

A Complex Decision (Gateway)

The second mechanism for making a Decision is the occurrence of a particular event, such as the receipt of a message (see See An Event-Based Decision Example.). See Event-Based. for more information on Event-Based Exclusive Gateways.

An Event-Based Decision Example

 

Merging Flow

BPMN uses the term merging to refer to the combining of two or more alternative paths into one path (also known as an a OR-Join). It is a place in the process where two or more alternative paths begin to traverse activities that are common to each of the paths. Theoretically, each alternative path can be modeled separately to a completion (an End Event). However, merging allows the paths to overlap and avoids the duplication of activities that are common to the separate paths. For a given instance of the Process, a Token would actually only see the sequence of activities that exist in one of the paths as if it were modeled separately to completion.

Since there are multiple ways that Sequence Flow can be forked and split, there are multiple ways that Sequence Flow can be merged. There are five different Workflow Patterns that can be demonstrated with merging.

The first Workflow Pattern, Simple Merge9, The graphical mechanism to merge alternative paths is simple: there are two or more incoming Sequence Flow to a Flow Object (see See Workflow Pattern #5 -- Simple Merge - Version 1.). In general, this means that a Token will travel down one of the alternative paths (for a given Process instance) and will continue from there. For that instance, Tokens will never arrive down the other alternative paths. BPMN provides two versions of a Simple Merge.

The first version is shown in See Workflow Pattern #5 -- Simple Merge - Version 1.. The two incoming Sequence Flow for activity "D" are uncontrolled. Since the two Sequence Flow are at the end of two alternative paths, created through the upstream exclusive Gateway, only one Token will reach activity "D" for any given instance of the Process.

Workflow Pattern #5 -- Simple Merge - Version 1

If the multiple incoming Sequence Flow are actually parallel instead of alternative, then the end result is different, even though the merging configuration is the same as See Workflow Pattern #5 -- Simple Merge - Version 1.. In See Workflow Pattern #7 -- Multiple Merge., the upstream behavior is parallel. Thus, there will be two Tokens arriving (at different times) at activity "D." Since the flow into activity "D" in uncontrolled, each Token arriving at activity "D" will cause a new instance of that activity. This is an important concept for modelers of BPMN should understand. In addition, this type of merge is the Workflow Pattern Multiple Merge10.

Workflow Pattern #7 -- Multiple Merge

The second version of the Simple Merge is shown in See Workflow Pattern #5 -- Simple Merge - Version 2.. The two incoming Sequence Flow for activity "D" are controlled through the Exclusive Gateway. Since the two Sequence Flow are at the end of two alternative paths, created through the upstream exclusive Gateway, only one Token will reach the Gateway for any given instance of the Process. The Token will then immediately proceed to activity "D."

Workflow Pattern #5 -- Simple Merge - Version 2

Again, if the multiple incoming Sequence Flow are actually parallel instead of alternative, then the end result is different, even though the merging configuration is the same as See Workflow Pattern #5 -- Simple Merge - Version 2.. In the model shown in See Workflow Pattern #8 -- Discriminator., there will be two Tokens arriving (at different times) at the Exclusive Gateway preceding activity "D." In this situation, the Gateway will accept the first Token and immediately pass it on through to the activity. When the second Token arrives, it will be excluded from the remainder of the flow. This means that the Token will not be passed on to the activity, but will be consumed. This type of merge is the Workflow Pattern Discriminator11.

Workflow Pattern #8 -- Discriminator

The fourth type of Workflow Pattern merge is called a Synchronizing Join12. This is a situation when the merging location does not know ahead of time how many Tokens will be arriving at the Gateway. In some Process instances, there may be only one Token. In other Process instances, there may be more than one Token arriving. This type of situation is created when an Inclusive Decision is made up stream (see See Workflow Pattern #9 -- Synchronizing Join.). To handle this, an Inclusive Gateway can be used to merge the appropriate number of Tokens for each Process instance. The Gateway, following the pattern Synchronizing Join, will wait for all expected Tokens before the flow will continue to the next activity. See Inclusive Gateways (OR). for more information on Inclusive Gateways.

Workflow Pattern #9 -- Synchronizing Join

The fourth type of Workflow Pattern merge is called a N out of M Join13. This type of situation is more complex and can be handled through a Complex Gateway (see See Workflow Pattern #8 -- N out of M Join.). The Gateway will receive Tokens from its incoming Sequence Flow and evaluate an expression to determine whether or not the flow should proceed. Once the condition has been satisfied, if additional Tokens arrive, they will be excluded (much like the Discriminator Pattern from See Workflow Pattern #8 -- Discriminator.). See Complex Gateways. for more information on Complex Gateways.

Workflow Pattern #8 -- N out of M Join

There is no specific correlation between the merging of a set of paths and the splitting that occurs through a Gateway object. For example, a Decision may split a path into three separate paths, but these three paths do not need to be merged at the same object. See The Split-Merge Relationship is not Fixed. shows that two of three alternative paths are merged at Task "F." All of the paths eventually will be merged, but this can happen through any combination of objects, including lone End Events. In fact, each path could end with a separate End Event.

The Split-Merge Relationship is not Fixed

Thus, for alternative flow, BPMN contrasts with BPEL4WS, which is mainly block structured. BPEL4WS switch and pick, which map to the BPMN Exclusive Gateway, are specific block structures that have well-defined boundaries. While there are no obvious boundaries to the alternative paths created by a decision in BPMN, the appropriate boundaries can be derived by an evaluation of the configuration of Sequence Flow that follow the decision. The locations in the Process where Tokens of the same identity are merged through multiple incoming Sequence Flow will determine the boundaries for a specific decision. The boundary may in fact be the end of the Process. More detail on the evaluation of BPEL4WS element boundaries can be found See Mapping to BPEL4WS..

Looping

BPMN provides 2 (two) mechanisms for looping within a Process. The first involves the use of attributes of activities to define the loop. The second involves the connection of Sequence Flow to "upstream" objects.

Activity Looping

The attributes of Tasks and Sub-Processes will determine if they are repeated as a loop. There are two types of loops that can be specified: Standard and Multi-Instance.

For Standard Loops:

·         If the loop condition is evaluated before the activity, this is generally referred to as a "while" loop. This means that the activities will be repeated as long as the condition is true. The activities may not be performed at all (if the condition is false the first time) or performed many times.

·         If the loop condition is evaluated after the activity, this is generally referred to as an "until" loop. This means that the activities will be repeated until a condition becomes true. The activities will be performed at least once, but may be performed many times.

For Multi-Instance Loops:

·         If the MI_Ordering is serial, then this becomes much like a while loop with a set number of iterations the loop will go through. These are often used in processes where a specific type of item will have a set number of sub-items or line items. A Multi-Instance loop will be used to process each of the line items.

·         If the MI_Ordering is parallel, this is generally referred to as multiple instances of the activities. An example of this type of feature would be used in a process to write a book, there would be a Sub-Process to write a chapter. There would be as many copies or instances of the Sub-Process as there are chapters in the book. All the instances could begin at the same time.

Those activities that are repeated (looped) will have a loop marker placed in the bottom center of the activity shape (see See A Task and a Collapsed Sub-Process with a Loop Marker.). Those activities that are Parallel Multi-Instance will have a parallel marker placed in the bottom center of the activity shape (see See A Task with a Parallel Marker.)

 

A Task and a Collapsed Sub-Process with a Loop Marker

A Task with a Parallel Marker

Expanded Sub-Processes also can have a loop marker placed at the bottom center of the Sub-Process rectangle (see See An Expanded Sub-Process with a Loop Marker.). The entire contents of the Sub-Process will be repeated as defined in the attributes.

An Expanded Sub-Process with a Loop Marker

Sequence Flow Looping

Loops can also be created by connecting a Sequence Flow to an "upstream" object. An object is considered to be upstream if that object has an outgoing Sequence Flow that leads to a series of other Sequence Flow, the last of which turns out to be an incoming Sequence Flow to the original object. That is, that object produces a Token and that Token traverses a set of Sequence Flow until the Token reaches the same object again. Sequence Flow looping is the same as Workflow Pattern #16 -- Arbitrary Cycle14 (see See A Data-Based Decision Example -- Workflow Pattern #4 -- Exclusive Choice.).

Workflow Pattern #16 -- Arbitrary Cycle

Usually these connections follow a Decision so that the loop is not infinite (see See An Until Loop.). If the Sequence Flow goes directly from a Decision to an upstream object, this is an "until" loop. The set of looped activities will occur until a certain condition is true.

An Until Loop

A while loop is created by making the decision first and then performing the repeating activities or moving on in the Process (see See A While Loop.). The set of looped activities may not occur or may occur many times.

A While Loop

Sequence Flow Jumping (Off-Page Connectors and Go To Objects)

Since process models often extend beyond the length of one printed page, there is often a concern about showing how Sequence Flow connections extend across the page breaks. One solution that is often employed is the use of Off-Page connectors to show where one page leaves off and the other begins. BPMN provides Intermediate Events of type Link for use as Off-Page connectors (see See Link Intermediate Event Used as Off-Page Connector.--Note that the figure shows two different printed pages, not two Pools in one diagram). A pair of Link Intermediate Events is used. One of the pair is shown at the end of one page. This Event is named and has an incoming Sequence Flow and no outgoing Sequence Flow. The second Link Event is at the beginning of the next page, shares the same name, and has an outgoing Sequence Flow and no incoming Sequence Flow.

 

Link Intermediate Event Used as Off-Page Connector

Another way that Link Intermediate Events can be used is as "Go To" objects. Functionally, they would work the same as for Off-Page Connectors (described above), except that they could be used anywhere in the diagram--on the same page or across multiple pages. The general idea is that they provide a mechanism for reducing the length of Sequence Flow lines. Some modelers may consider long lines as being hard to follow or trace. Go To Objects can be used to avoid very long Sequence Flow (see See Process with Long Sequence Flow. and See Process with Link Intermediate Events Used as Go To Objects.). Both diagrams will behave equivalently. For See Process with Link Intermediate Events Used as Go To Objects., if the "Order Rejected" path is taken from the Decision, then the Token traversing the Sequence Flow would reach the source Link Event and then "jump" to the target Link Event and continue down the Sequence Flow. The process would continue as if the Sequence Flow had directly connected the two objects.

 

Process with Long Sequence Flow

 

Process with Link Intermediate Events Used as Go To Objects

Some methodologies prefer that all Sequence Flow only move in one direction; that is, forward in time. These methodologies do not allow Sequence Flow to connect directly to upstream objects. Some consistency in modeling can be gained by such a methodology, but situations that require looping become a challenge. Link Intermediate Events can be used to make upstream connections and create loops without violating the Sequence Flow direction restriction (see See Link Intermediate Event Used for Looping.).

 

Link Intermediate Event Used for Looping

Passing Flow to and from Sub-Processes

This section reviews how flow will be passed between a parent Process and any of its Sub-Processes. The flow (e.g., a Token) will start at the parent Process and then move to the Sub-Process and then will move back to the parent process (see See Example of Sub-Process with Start and End Events Inside.). Most of the time the flow will reach a Sub-Process, get transferred to the Start Event of the Sub-Process, traverse the Sequence Flow of the Sub-Process, reach the End Event of the Sub-Process, and, finally, get transferred back to the parent Process to continue down the outgoing Sequence Flow of the Sub-Process object. If the Sub-Process contains parallel Flow, then all the Flow must complete before a Token is transferred back to the parent Process. This functionality treats the Sub-Process as a self-contained "box" of activities.

 

Example of Sub-Process with Start and End Events Inside

To make the flow between levels of a Process more obvious, a modeler has the option of placing the Start Event and the End Event on the boundary of the Sub-Process and connect the Sequence Flow from the Parent Process objects to/from these Events (see See Example of Sub-Process with Start and End Events on Boundary.).

 

Example of Sub-Process with Start and End Events on Boundary

Controlling Flow Across Processes

There may be situations within a Process where the flow is affected by or dependent on the activity that occurs in another Process. These events or conditions can be referred to as milestones. The process model must be able to identify and react to the milestone.That is, the starting or continuation of a Process may be triggered by Link Events, which pass the flow (Tokens) between processes (see See Link Events Used to Synchronize Behavior Across Processes.). The type of Workflow Pattern called a Milestone15.

 

Link Events Used to Synchronize Behavior Across Processes

Avoiding Illegal Models and Unexpected Behavior

BPMN, being a graph-structured Diagram, rather than having a block-structures like BPEL4WS, provides a great flexibility for depicting complex process behavior in a fairly compact form. However, the free-form nature of BPMN can create modeling situations that cannot be executed or will behave in a manner that is not expected by the modeler. These types of modeling problems can occur because there is not a tight relationship between forks and joins or splits and merges. A block structure provides these tight relationships, but a graph-structure allows these flow control mechanisms to be mixed and matched at the discretion of the modeler. Some combinations of these control elements will create Processes that cannot be executed or will create behavior that was not intended by the modeler. The situation where alternative paths cross the implicit boundary of a group of parallel paths can cause an invalid model.

See Potentially a dead-locked model. shows such a model. Task "D" is an activity that has two incoming Sequence Flow; one from a forked path (after a split path) and one from a split path. This can create a problem at the Parallel Gateway that precedes Task "E," which also has multiple incoming Sequence Flow. The Sequence Flow from Task "B" is crossing the implicit boundary of the fork created after Task "A." As a result, if the "Yes" Sequence Flow is taken from the Decision in the Diagram (Variation 1), then Task "E" can expect two Tokens to arrive--one from Task "C" and one from Task "D." However, if the "No" Sequence Flow is taken from the Decision (Variation 2), the Parallel Gateway will receive only one Token--one from Task "D." Since the Gateway expects two Tokens, the Process will be dead-locked at that position.

Potentially a dead-locked model

Another type of problem occurs with looping back to upstream activities. If the loop Decision is made within the implicit boundaries of a set of parallel paths, then the behavior of the loop becomes ambiguous (see See Improper Looping.), since it is unclear whether Task "E" was intended to be repeated based on the loop or what would happen if Task "E" was still active when the loop reached that Task again.

Improper Looping

The use of Link Events can also create unexpected behavior. In general, Link Events not used for off-page connectors should be considered an advanced modeling technique and the modeler should be careful to understand the resultant behavior and flow of Tokens.

The figure below (see See Improper use of a Link End Event.) is a variation of See Link Events Used to Synchronize Behavior Across Processes.. In this figure, however, the Link End Event in the top Sub-Process is not used properly. For the top Sub-Process, there is only one Token generated and available. When the Token leaves Task "C" and arrives at the Link End Event, it is consumed by the Event, but then immediately jumps to the target Start Event that shares its name (in the bottom Sub-Process). Because the Token jumps to the other Sub-Process, there is no Token left to be transferred up to the Parent Process and continue down the outgoing Sequence Flow of the top Sub-Process. Thus, the overall Process will be stuck waiting at the Parallel Gateway for a Token that will never arrive.

 

Improper use of a Link End Event

In general, the analysis of how Tokens will flow through the model will help find models that cannot be executed properly. This Token flow analysis will be used to create some of the mappings to BPEL4WS. Since BPEL4WS is properly executable, if the Token flow analysis cannot create a valid BPEL4WS process, then the model is not structured correctly.

Changes Since 1.0 Version

These are the changes since the last publicly released version:

·          

 

Exception Flow

Exception Flow occurs outside the Normal Flow of the Process and is based upon an event (an Intermediate Event) that occurs during the performance of the Process. While Intermediate Events can be included in the Normal Flow to set delays or breaks to wait for a message, when they are attached to the boundary of an activity, either a Task or a Sub-Process (see See A Task with Exception Flow (Interrupts Event Context).), they create Exception Flow.

A Task with Exception Flow (Interrupts Event Context)

By doing this, the modeler is creating an Event Context. The Event Context will respond to specific Triggers to interrupt the activity and redirect the flow through the Intermediate Event. The Event Context will only respond if it is active (running) at the time of the Trigger. If the activity has completed, then the Trigger may occur with no response. The source of the Trigger may be external to the Process execution, such as a message or an application error, or the Trigger may be caused by a "throw" Intermediate Event from any other active location within the Process.

If there are a group of Tasks that the modeler wants to include in an Event Context, then a Sub-Process can be added to encompass the Tasks and to handle any events by having them attached to its boundary (see See A Sub-Process with Exception Flow (Interrupts Event Context).).

A Sub-Process with Exception Flow (Interrupts Event Context)

Two Triggers for Intermediate Event are used by Event Contexts at the level of the execution language (BPEL4WS): Message, and Error (fault). A Message Event occurs when a message, with the exact identity as specified in the Intermediate Event, is received by the Process. An Error Event occurs when the Process detects an Error. If an Error Code is specified in the Intermediate Event, then the code of the detected Error must match for the Event Context to respond. If the Intermediate Event does not specify an Error Code, then any Error will trigger a response from the Event Context. Other BPMN Triggers, such as a Timer, must be converted into a BPEL4WS configuration that will generate the appropriate Message or Error (See Exception Flow. for details of a mapping of Exception Flow to BPEL4WS).

If this event does not occur while the Event Context is ready, then the Process will continue through the Normal Flow as defined through the Sequence Flow.

Ad Hoc

An Ad Hoc Process is a group of activities that have no pre-definable sequence relationships. A set of activities can be defined for the Process, but the sequence and number of performances for the activities is completely determined by the performers of the activities and cannot be defined beforehand.

A Sub-Process is marked as being an Ad Hoc with a "tilde" symbol placed at the bottom center of the Sub-Process shape (see See A Collapsed Ad Hoc Sub-Process. and See An Expanded Ad Hoc Sub-Process.). Activities within the Process are disconnected from each other. During execution of the Process, any one or more of the activities may be active and they can be performed in almost any order or frequency.

A Collapsed Ad Hoc Sub-Process

An Expanded Ad Hoc Sub-Process

The performers determine when activities will start, when they will end, what the next activity will be, and so on. Examples of the types of Processes that are Ad Hoc include computer code development (at a low level), sales support, and writing a book chapter. If we look at the details of writing a book chapter, we could see that the activities within this Process include: researching the topic, writing text, editing text, generating graphics, including graphics in the text, organizing references, etc. (see See An Ad Hoc Process for Writing a Book Chapter.). There may be some dependencies between Tasks in this Process, such as writing text before editing text, but there is not necessarily any correlation between an instance of writing text to an instance of editing text. Editing may occur infrequently and based on the text of many instances of the writing text Task.

An Ad Hoc Process for Writing a Book Chapter

It is a challenge for a BPM engine to monitor the status of Ad Hoc Processes, usually these kind of processes are handled through groupware applications (such as e-mail), but BPMN allows modeling of Processes that are not necessarily executable and should provide the mechanisms for those BPM engines that can follow an Ad Hoc Process. Given this, at some point, the Process will have completed and this can be determined by evaluating a Completion Condition that evaluates Process attributes that will have been updated by an activity in the Process.

Compensation Association

Some activities produce complex effects or specific outputs. If the outcome is determined to be undesirable by some specified criteria (such as an order being cancelled), then it will be necessary to "undo" the activities. There are three ways this can be done:

·         Restoring of a copy of the initial values for data, thereby overwriting any changes.

·         Doing nothing (if nothing has be changed because the changes have been set aside until a confirmation).

·         Invoking activities that undo the effects--also known as compensation.

 

An activity that might require compensation could be, for example, one that charges a buyer for some service and debits a credit card to do so. These types of activities usually need a separate activity to counter the effects of the initial activity. Often, a record of both activities is required, so this is another reason that the activity is not "undone." An Intermediate Event of type Compensation is attached to the boundary of an activity to indicate that compensation may be necessary for that activity.

One of the three mechanisms for "undo" activities, Compensation, requires specific notation and is a special circumstance that occurs outside the Normal Flow of the Process. For this reason, the Compensation Intermediate Event does not have an outgoing Sequence Flow, but instead has an outgoing directed Association (see See A Task with an Associated Compensation Activity.).

 

A Task with an Associated Compensation Activity

The target of this Association is the activity that will compensate for the work done in the source activity, and will be referred to as the Compensation Activity. The Compensation Activity is special in that it does not follow the normal Sequence Flow rules--as mentioned, it is outside the Normal Flow of the Process. This activity cannot have any incoming or outgoing Sequence Flow. The Compensation marker (as is in the Compensation Intermediate Event) will be displayed in the bottom center of the Activity to show this status of the activity (see the "Credit Buyer" Task in See A Task with an Associated Compensation Activity.). Note that there can be only one target activity for compensation. There cannot be a sequence of activities shown. If the compensation does require more than one activity, then these activities must be put inside a single Sub-Process that is the target of the Association. The Sub-Process can be collapsed or expanded. If the Sub-Process is expanded, then only the Sub-Process itself requires the Compensation marker--the activities inside the Sub-Process do not require this marker.

Only activities that have been completed can be compensated. The compensation of an activity can be triggered in two ways:

·         The activity is inside a Transaction Sub-Process that is cancelled (see See Compensation Shown in the context of a Transaction.). In this situation, the whole Sub-Process will be "rewound" or rolled back--the Process flow will go backwards and any activity that requires compensation will be compensated. This is why the Compensation marker for Events looks like a "rewind" symbol for a tape player. After the compensation has been completed, the Process will continue its rollback.

·         A downstream Intermediate or End Event of type Compensation "throws" a compensation identifier that is "caught" by the Intermediate Event attached to the boundary of the activity.

 

Compensation Shown in the context of a Transaction

 


1. http://tmitwww.tm.tue.nl/research/patterns/

2. http://tmitwww.tm.tue.nl/research/patterns/download/wfs-pat-2002.pdf

3. http://tmitwww.tm.tue.nl/research/patterns/sequence.htm

4. The Workflow Management Coalition Terminology & Glossary. The Workflow Management Coalition. Document Number WFMC-TC-1011. April 1999.

5. http://tmitwww.tm.tue.nl/research/patterns/parallel_split.htm

6. http://tmitwww.tm.tue.nl/research/synchronization.htm

7. http://tmitwww.tm.tue.nl/research/patterns/exclusive_choice.htm

8. http://tmitwww.tm.tue.nl/research/patterns/multiple_choice.htm

9. http://tmitwww.tm.tue.nl/research/patterns/simple_merge.htm

10. http://tmitwww.tm.tue.nl/research/patterns/multiple_merge.htm

11. http://tmitwww.tm.tue.nl/research/patterns/discriminator.htm

12. http://tmitwww.tm.tue.nl/research/patterns/synchronizing_join.htm

13. http://tmitwww.tm.tue.nl/research/patterns/n_out_of_m_join.htm

14. http://tmitwww.tm.tue.nl/research/patterns/arbitrary_cycle.htm

15. http://tmitwww.tm.tue.nl/research/patterns/milestone.htm