Design Patterns

Reacting to Specific Events

When a specific moment/condition occurs within a process or when a certain time expires, there is a need to react to the event. This can be achieved using boundary events or event subprocesses.

'OR' Gateway, Exclusive Gateway (if-else condition)

The 'OR' gateway selects the sequence flow based on data (conditions) to which control is passed (opens in a new tab).

If the gateway has multiple distinct flows (branches), all of them must have a logical expression. One of the branches, considered "successful" from a business perspective, can be marked as "default" (without any conditions). The gateway might have one flow without a logical expression, which should be marked as "default."

During execution, the process instance checks conditions at the gateway. If none of the conditions at the gateway are met, and there's no default flow (branch), an incident will be created.

Demonstration of the working process (opens in a new tab) for the 'OR'/exclusive gateway.

Examples of logical expressions that can be used in the gateway flows:

= totalPrice > 100
= order.customer = "Paul"            
= orderCount > 15 or totalPrice > 50            
= valid and orderCount > 0

Working with logical expressions is further described in the Camunda documentation (opens in a new tab).

'AND' Gateway, Parallel Gateway

The 'AND' gateway allows splitting the flow into parallel paths without considering conditions on the branches. The Parallel Gateway (opens in a new tab) generates new tokens, activating multiple sequence flows (opens in a new tab) in parallel.

Outgoing flows (branches) from the parallel gateway must be joined. The process instance will wait at the parallel gateway until all remaining flows (branches) are executed. Afterward, all tokens from the parallel branches will be merged into one.

Demonstration of the operation of the 'AND'/parallel gateway (opens in a new tab).

'OR' Gateway, Inclusive Gateway

The inclusive gateway 'OR' operates similarly to the parallel gateway but allows evaluating conditions on outgoing flows. If more than one condition is met, the gateway activates multiple sequence flows in parallel.

Outgoing flows (branches) from the inclusive gateway must be joined. The process instance will wait at the inclusive gateway until all remaining flows (branches) are executed. Afterward, all tokens will be merged into one.

In the above example, after the process is initiated, two tasks will be created if process variables paymentReceived == false and shipOrder == true. If none of the conditions are met, an error will be generated, which can be avoided by marking one of the flows (branches) as "default."

Event-Based Gateway

The event-based gateway allows making decisions based on events.

When a process instance reaches the gateway, execution is paused. The process instance waits at the gateway until one of the events is initiated. After that, no other gateway events can be executed.

• An event-based gateway must contain two or more outgoing control flows.
• BPMN event types like "Message," "Signal," "Timer," "Condition," and "Compound" are used with BPMN event-based gateways. They are placed on outgoing branches directly after the gateway.
• The usage of event types such as "Error," "Cancel," "Compensation," and "Link" is prohibited with BPMN event-based gateways.
• Elements (events or tasks) connected by outgoing control flows to the event-based gateway are part of this gateway's configuration. They should not have additional incoming operation flows from other elements except this gateway.
• If a "Message" type event follows the gateway, a "Receive Message" type task cannot be used afterward, and vice versa.

Best Practices in Process Modeling

1. Avoid Overlapping Operation Flows in Diagrams

   The simpler and clearer the diagram is modeled, the more understandable it is for users. Try to avoid overlapping operation flows on diagrams: this simplifies the understanding of BPMN business process models for both experienced and novice BPMN analysts.

   Sometimes it's impossible to eliminate intersecting flows, but it's always worth spending extra time optimizing the layout of diagram elements to make it even more understandable and comfortable for users to perceive.

   Good example

   

   

   Bad example

   

   

2. Naming Elements in BPMN

   Each BPMN element has its symbol and name. Events should be named according to the formula "noun + past tense verb." For example, "transaction occurred." A process (pool) should contain the name of the process or the entity performing it. For example, "Corporate Portal" or "Contract Initiator" or "Delivery Management." Tasks are preferably named according to the formula "gerund noun + name of the object on which the action is performed." For example, "Preparing Report" or "Goods Shipment" or "Signing Contract." Exclusive gateways should be labeled with questions, and the outgoing operation flows should be labeled with answers (conditions).

   Naming Formulas for Elements

   

   

   Good example

   

   

   Bad example

   

   

3. Symmetrical Modeling Symmetrical modeling allows diagram users to better understand the logic of the process. This advice is illustrated in the two examples below.

   Good example

   

   

   Bad example

   

   

   Good example

   

   

   Bad example

   

   

Using a Loop / Repeating the Same Action

A loop allows performing a task until the exit condition is met.

Let's consider an order example.

1. Upon receiving an order, check its availability in stock.
2. If the products are available, collect payment for the order.
3. In case of an error during payment, an exclusive gateway 'or' can simulate payment retries.

The loop can be represented differently in the process, more compactly. For this, there is a special marker.

This marker implements a do-while loop - executing the action until the condition becomes true. Thus, the payment step will be repeated in case of failure.

Actions with Multiple Instances (multi-instance)

The process step is repeated several times - once for each element of the collection (similar to a foreach loop).

This activity can be performed either sequentially or in parallel. Sequential action is indicated by a marker with three horizontal lines. Parallel action is indicated by a marker with three vertical lines.

In the case of sequential action, the action is performed for each instance.

In the case of parallel activity, the action is performed in parallel for each instance.

Defining a Collection for Iteration

In the Collection field, specify the collection of elements for iteration. To provide access to the element, enter its name in the Element variable field. If necessary, you can specify a condition to terminate the iteration - the Completion Condition field. Or specify the number of iterations using Loop Cardinality if there is no need to iterate through the entire collection.

Working with a collection can be resource-intensive. In such a case, mark it as asynchronous with Multi Instance Asynchronous Before='true'.

Download an example diagram

Subprocesses

Boundary Events

Boundary events in BPMN can be attached to subprocesses. This allows modeling alternative execution paths for actions in the parent process based on the state of the child subprocess.

When an event occurs, the subprocess is interrupted by the parent process, which reacts to an external circumstance. Then the BPMN control flow in the parent process continues along an alternative branch.

In BPMN 2.0, it is preferable to use escalation events instead of error events. The example above shows the use of a non-interrupting boundary escalation event. Non-interrupting boundary events are represented by a circle with a double dashed line. They trigger an additional branch in the parent process without interrupting the subprocess. In the example, the subprocess "Purchase Goods" passes information about delayed product delivery to the parent process "Order Processing". The "Purchase Goods" subprocess continues its execution, while an additional branch "Late Product Delivery" is activated in the parent process.

Event Subprocess

An event subprocess in BPMN is a subprocess that can be executed once or multiple times or not executed at all. An event subprocess is depicted on the diagram with a thin dashed line.

The BPMN event subprocess is initiated by its own start event and has no incoming or outgoing control flow. This is its main difference from a regular subprocess, which is initiated by the control flow of the parent process. The BPMN event subprocess must contain at least one start event.

The BPMN event subprocess can affect the parent process in the following ways:

1. Interrupt it if an interrupting start event is used. In this case, the parent process will be halted until the event subprocess is completed.
2. Not interrupt it if a non-interrupting start event is used. In this case, the parent process continues to execute along with the event subprocess.

The diagram below provides a simple example of using event subprocesses:

Transaction Subprocess

A BPMN transaction is a subprocess that can have multiple outcomes:

1. Successful completion, depicted as a control flow leaving the transaction.
2. Cancellation, depicted using a boundary "Cancel" event. This event can only be used with a BPMN "Transaction" subprocess. When a "Cancel" event occurs, compensation ("rollback") of specific transaction actions will take place, or a return to the beginning of the process.
3. Error. The occurrence of an error means that BPMN Transaction actions are performed incorrectly, and successful completion and cancellation of the transaction become impossible. The transaction execution is terminated without compensation, and the control flow of the parent process continues from the "Error" boundary event.

Successful completion of a Transaction differs from the completion of a regular subprocess. When all Transaction actions are completed with end events (except for cancellation or error), there is no immediate return to the parent process control flow. The transaction protocol first checks the status of all participants who have completed the transaction. If it is found that at least one of them has problems completing actions, the transaction triggers an "Error" or "Cancel" event. In this case, the control flow of the parent process is directed to the corresponding Transaction event.

Error Handling Strategies

Every process has a successful execution scenario, but sometimes deviations from successful execution need to be addressed. It is important to understand that, according to the BPMN specification, an exception is either handled to continue the process or terminates the process instance. Events-errors help to "catch" and handle exceptional situations.

Handling Exceptions as End Events

Handling Exceptions During Process Execution

Handling Error as Retry of an Action

Handling Error in Subprocess

Saga Pattern or Compensation Template

The Saga pattern suggests canceling a completed task when there is no way to roll it back. In BPMN notation, there is a compensation mechanism to associate tasks with cancellation tasks.

1. The client is added to the CRM system.
2. An error occurs, leading to a transaction rollback, and the process triggers compensation.
3. During the transaction rollback, all compensating actions will be executed, resulting in the deactivation of the client.

Handling Multiple Orders

Let's assume we want to model a BPMN process for a company that receives and processes orders from various distribution channels, one of which is a supermarket. Orders from the supermarket arrive at specific time intervals in the form of electronic forms with a list of items. Each incoming order must be verified and then loaded into the ERP system.

Download the example diagram

Two-Stage Escalation

Let's explore modeling a two-stage escalation in BPMN using the example of the "Pizza Order" process. Suppose we ordered pizza and are waiting for delivery. If the pizza is not delivered within 30 minutes, we call the delivery service. Then we wait for the pizza delivery again. If it is not delivered within 20 minutes, we cancel the order. Below are possible solutions for this scenario.

Solution 1

Download the example diagram

Solution 2

Download diagram example

Solution 3

Скачать пример диаграммы

DMN