Up to this point, we’ve concentrated on processes which have one clearly defined work flow. In practice, workflows are obviously more complex and it very much depends on a variety of factors how a process actually runs.
For this purpose, BPMN defines a set of gateways.
The simplest is the condition gateway:
The gateway is marked with an X and a brief statement describes the actual decision which leads the process to the output gate. The output arrows are marked with different outcome variations – e.g. answers to the question posed in the decision gateway’s label.
There’s one major difference to many other documentation styles, which is important to keep in mind here: all the work and activities that choose the further path of the process (or token), are completed before the gateway. Not within the gateway, not afterwards.
In the instance of the previous sample, the decision if the temperature is correct, is already coming out the activity “Check temperature”.
You can also mark one outgoing thread as the “default” choice by putting a slant line at the start of the outgoing thread:
Another gateway variant is an exclusive event gateway: it defines a choice of available events which may be triggered. As soon as one triggers, the process flow continues down the event’s path. Basically, in a sense the process flow is influenced by “external” factors here.
Lets briefly look at this sample:
- We order pizza
- Then, either we receive the pizza first or 30 minutes pass
- If we receive the pizza, the process is completed
- If 30 minutes pass first, we call the pizza guy to complain and return the event gateway
- Then – again – either 30 minutes pass or we receive the pizza.
Basically, we are calling up the pizza guy in 30 minute intervals until we finally receive the pizza. In practice, we would probably want another gateway in there to cancel the order if we’ve been waiting to long. I suppose you get the gist of it and could design this now by yourself.
Merging two execution threads
When a process is split up into two separate paths, it is possible to merge it either indirectly (as shown so far) or via an additional merge gate.
The only visible difference is that the gate is a clearly outlined pictogram and point where the process merges up again. However, the use of merge gates is not simply about visual appeal or legibility.
There are a few occasions in which merge gates become mandatory – for instance, when merging a path into an event. BPMN allows only one process flow to run into an event; therefore, if multiple paths need to merge into an event, they first need to be combined via a merge gate.
It is also possible to use markers to mark which kind of merge the gate is representing. For the previous example, we could also draw the diagram like this:
Another type of gateway is one marked with a plus sign (+); this one splits up the process into to separate threads which run in parallel. In principle, at this gate the process token is cloned into the number of outgoing threads and one separate token is walking down. At the merging gate, the process halts until all previously cloned tokens arrive at the merge gate or are consumed otherwise (e.g. by arriving at and “end event”).