BPMN Gateways
Gateways in BPMN 2.0
BPMN is a hierarchical modeling language. In another article I discussed the difference between tasks and subprocesses already, but in this article you will learn everything about the use of gateways in BPMN.
BPMN XOR Gateway
In BPMN, gateways control process flow. A gateway tests an outcome of a preceding activity: it can not perform work itself. A gateway can have as many gates as you want, it is not limited to two, and the specification does not describe that they have to connect to the points of the diamond. The XOR gateway can also be drawn with an X inside. The X-OR gateway means: only follow the path of the true data condition. A gateway should be seen as conditional logic: a gateway often tests a decision, that occurred previously, in an activity. The result of that decision, is an end-state of the activity that makes it. The gateway tests the end state of the activity. It does not make a decision, since tasks are the only objects in BPMN stat can perform work.
BPMN XOR Gateway or Exclusive Gateway?
In BPMN, the terms XOR, Exclusive Databased Gateway and Exclusive Gateway are used interchangeably. However, they mean the same thing.
BPMN Parallel Gateway
A parallel gateway is very different than the XOW gateway because you don’t evaluate any conditions or event. Instead, the parallel gateway is used to represent two concurrent tasks in a process flow. It is the same as a fork in a UML activity diagram. The parallel gateway is visualized by the + symbol inside the shape. When a sequence flow arrives at a parallel gateway, two or more concurrent paths are activated. Either of those activities may start first, and they may overlap in time. If two sequence flows arrive or join at a parallel gateway, it means that both activities should be completed before the flow can continue.
Gateways don't make decisions
Another difference with traditional flowchart diagramming, is the fact that in BPMN, gateways do not make decisions. Making a decision is performing work, and as we discussed earlier, work is only performed by activities.
A gateway should be seen as conditional logic: a gateway often tests a decision, that occurred previously, in an activity. The result of that decision, is an end-state of the activity that makes it. The gateway tests the end state of the activity.
The first diagram is thus incorrect: a gateway can’t approve anything, it can only test if a condition is met. You need an activity for approving the invoice. All human work, decision making or other process logic that is performing work MUST be modelled as an activity. The gateway that follows the activity, often containing a yes/no question, can only test a decision. The second diagram shows how you should model a decision. Note that approve invoice is modelled as an activity, and the gateway only tests the end state of the activity: approving the invoice, which is returned by a simple yes or no.
