Working with BPMN 2.0 Parallel Gateways
By Tijs Rademakers
An exclusive gateway is a simple but powerful construct for controlling the flow throughout a process definition. A parallel gateway is part of the same gateway construct family, but it can be considered a more advanced BPMN element.
It’s a common requirement for parts of process logic to be executed at the same time. If there are multiple tasks to perform, it would be inefficient to place the activities in a waiting line. A parallel gateway makes it possible to perform multiple activities simultaneously.
In addition, when a parallel gateway is placed after multiple incoming sequence flows, it will make sure that all activities are finished before the process execution goes further. A parallel gateway executes all outgoing sequence flows leaving the gateway and waits for all incoming sequence flows to complete.
With a simplified example process, the functionality of a parallel gateway becomes easier to comprehend. Let’s look at a fictional day in the life of a multitasking developer in figure 1. The first parallel gateway is called a fork because it makes the process execution fork into two parallel executions. The second parallel gateway is a join because it makes the process execution wait until all the activities between the fork and join gateways are executed.
Figure 1 A multitasking process definition with a fork and join parallel gateway. All activities must be executed before the process will end with the last activity after the join parallel gateway.
In the following sections, we’ll implement the multitasking process in a BPMN 2.0 XML file.
Implementing a process with a parallel gateway
Parallel gateways aren’t hard to implement in a BPMN 2.0 process definition. But the runtime behavior is more difficult to grasp. As you’ll discover, the different outgoing sequence flows aren’t really executed in parallel but are still running one after another.
HINTReal parallel execution with multiple threads running at the same time isn’t the result of using a parallel gateway. The activity sequences that are modeled after the fork construct run after each other. The first sequence of activities is executed until a wait state is encountered. This can be a receive or user task or a parallel gateway join when there are no wait state activities in the sequence. After the first sequence of activities has come into a wait state, the second sequence of activities will be executed, and so on. There are good reasons why the Activiti framework decided to implement the parallel gateway this way. If there are multiple threads running at the same time, a need for locking and concurrency checking would come up and that would introduce a lot more complexity and lead to some performance loss.
Let’s first look at the implementation of the multitasking example process definition in the next listing.
#1 Fork parallel gateway
#2 First activity of first sequence
#3 First activity of second sequence
#4 Join parallel gateway
As you already saw, the BPMN 2.0 XML definition of a parallel gateway isn’t difficult. The runtime behavior is another thing. For example, how does the Activiti Engine know the first defined parallel gateway (#1)is a fork? It doesn’t know that. The parallel gateway acts as a join and fork. First, the Activiti Engine waits until all incoming sequence flows have been executed; then, it will fork into all outgoing sequence flows.
For your fork parallel gateway, there’s only one incoming sequence flow, so the process will immediately perform the fork behavior.