Demystifying the Event Driven Gateway
Blog: Process-Modeling.com - Rick Geneva
Event Based Exclusive Gateway
The event driven gateway is one of the most useful symbols that I know of in BPMN. Yet it’s often overlooked as a solution to common problems. It is a compound symbol, inheriting attributes of other BPMN shapes. First of all, it’s a gateway that is used to split sequence flow paths. The gateway is the diamond symbol. Inside this diamond shape you will see the intermediate event shape, which is the double thin line circle. Inside the intermediate event shape there is the pentagon, which is a symbol for multiple events. So when you put all of this together we have a gateway that deals with multiple intermediate events.
BPMN version 1.1 and higher
In all of my classes I tend to get more questions about the event based gateway than any other shape in BPMN. This is probably because there are so many use cases for it, and its pattern to many people appears to be drawn backwards. Most beginners in BPMN tend to draw the pattern with the intermediate event shapes to the left of the gateway. Let’s start by looking at the basic pattern and then discuss some of the potential business scenarios where you could use this notation.
The basic pattern that applies to the event based exclusive gateway
The main purpose of the event gateway is to illustrate that you must choose between one, and only one event attached to the right. Any other event would not correlate to the same process instance. For example, I send a message to a coworker, and he replies either by email or by phone. The message type is different for the reply, and requires a different action for me to process it. I don’t know in advance which message I’m going to receive. Therefore it is an event that I must react to and process accordingly.
The exclusive behavior of the event based gateway is due to the fact that only one path can be chosen. This is similar to the exclusive data based gateway, except that event-based means that we are reacting to events instead of data conditions. With data-based gateways, I already have the condition, and I must evaluate it at the relative point in time that it appears in the diagram. The event based behavior is expressing that we don’t yet have the condition at the specific point in time, and we must wait for an event to make the choice of which path should proceed.
There is a unique capability for this gateway to be used at the beginning of a process. It actually takes the place of the start event in this case. Often I encounter diagrams where there is additionally a start event to the immediate left of the event based gateway. This might actually be incorrect, depending on what you are trying to express. The literal interpretation when you use the event based gateway as a start event reads like this: My process starts when I receive one of the following events. The BPMN specification is very specific about using only intermediate events to the right of the event driven gateway. But if it makes more sense to you, think of the intermediate events acting as start events, with the gateway acting as the place where the choice of event is made.
The event based gateway acting as a start event expresses that multiple events can start a process.
When used in place of a start event, the event driven gateway is expressing that there are many events that can cause the process to begin. When used as an intermediate gateway, it expresses that the process is in a wait-state, and will proceed only after one of multiple events have occurred.
In either case of starting a process or continuing a process, the event based gateway merges with the exclusive data-based gateway. This might sound strange, but merging on gateways is found in a diagram when we want to express that a synchronizing flow exists. It’s similar to a traffic symbol. Exclusive merge means that only one path will ever be permitted through this point in the diagram. In contrast, parallel merge indicates that all paths are required in order to move forward, and will create a wait-state until all paths have reached the point of the gateway.
Using the exclusive data-based gateway for merging
Because per BPMN specification, the event based gateway is only permitted to have events to the right, we cannot use it for merging. But since we only need to express the merging behavior, the data-based exclusive gateway is a suitable substitute. Often a process modeler will omit the merging gateway. I am a proponent of always using a gateway for merging because it shows an explicit behavior, rather than leaving the diagram open to interpretation errors. For example, if I write a quote and don’t use the close quote symbol, doesn’t this leave you hanging a bit? So it’s better style to always use a merging gateway.
A best practice of using event based gateways is to use multiple event types whenever practical. If you have investigated the merging behavior of gateways, you might already know that it is possible to cause a deadlock or a replicated instance with improper usage of gateways.
Expecting the Unexpected Condition
A replication of sequence flow occurs when a parallel split occurs and there is no checkpoint or gateway to ensure that synchronization or merge of the parallel paths occur. For example, I split with a parallel gateway and I forget to merge with it. Somewhere downstream I could potentially end up with replication of effort on the same process instance. Suppose I send a new hire document to IT, human resources, and accounting departments in parallel. After these departments are complete with the document it is passed to another department who does a background check. The background check is expensive, and it is outsourced to an external agency. The external agency will not check to see if the same person is being processed more than once. There must be a point in the process that prevents the background check from occurring three times on the same person. Potentially every subsequent step downstream in the process might also occur three times until someone finally realizes the error and merges the files. Before the error is caught, duplication or triplication of effort occurs. This would be expensive and wasteful.
Without merging, a potential for replicating the downstream activities exists
Likewise with exclusive behavior it’s possible have sequencing and synchronization errors without properly handling the merging behavior. A deadlock condition occurs when a splitting gateway doesn’t match up with a corresponding merging gateway. Sometimes this can accidentally occur implicitly whenever the merging gateway is omitted from the diagram. For example, I send a document to one of three departments. A fourth department is expecting to receive documents from all three proceeding steps in parallel, but it only ever receives one. This can be a deadlock situation, meaning because of a merging flow error, the process will never proceed past the checkpoint.
Improper usage of gateways can lead to process deadlock
Deadlocks can occur in event based gateways as well. But in this case, it’s not because of using the improper merging shape, or from omitting the merging behavior. The deadlock is event based. Event based deadlocks occur when the primary means receiving the expected events has failed. For example, I send an email to my friend to have lunch with me. He might reply via email or via calling my mobile phone. But I don’t receive a reply so I go ahead and wait at the restaurant anyway. I assume he must have received the message, because email is so reliable, right? Meanwhile I’m waiting at the restaurant for him. I wait all day. I wait all week. Eventually, after about three months, the manager at the restaurant feels inclined to call the police to physically remove me from the restaurant. My friend actually did receive the message and left a note on my desk that he could not join me. Because the event (note on my desk) was outside of my processing capacity, I wasted three weeks of my life waiting. This was a terribly inefficient process, and could have benefitted from planning for the events based deadlock.
Obviously this is a fictional story. As human beings we have enough common sense to avoid this situation. But the elaborate computer systems we build don’t have this kind of common sense. A stuck automated process will wait forever until an administrator comes along and terminates the process or reboots the computer. Meanwhile, money was spent, customers were lost, paperwork piles up on someone’s desk. Eventually someone will realize the problem, but not until after the customer gets angry. Or maybe the error is realized after the board of directors becomes angry because your company keeps losing money.
The deadlock of events is usually caused by the assumption that things will always go as planned. The reality is that in business things go as planned only about 35% of the time. The other 65% is either the more expensive way to make money, or the ways that money is lost in a business transaction.
In the scenario of me waiting for my friend at the restaurant, my common sense tells me that I should only wait about an hour before I make the decision that he is not coming to meet me. For other friends this might be two hours because they might be an hour late on a regular basis. But the point is, I would not wait indefinitely. So the addition of an intermediate timer event to my process flow can save the day when I have an event based deadlock.
If you wish to be even more careful about event based deadlocks, try to consider more reasons why the process could fail. For example, as I’m waiting for my friend I hear the tsunami warning siren. The restaurant is by the beach, so I don’t think my friend will meet me. In fact, its time I consider evacuating to higher ground. In this case I would add a signal event to my process that listens to all “broadcasts” that might be interesting to me.
Full example of the event based gateway in action, using multiple events to avoid process deadlock.
A more realistic example
Now let’s apply the same pattern to a common business problem. Suppose that I send an order to my supplier. Do I wait indefinitely, assuming the supplier received the message? After all, they have been fairly reliable in the past, right? So what happens when I don’t receive the order? Should I continue waiting months later when I have no products to sell because I have no supplies to make anything? Maybe you assumed that someone else would realize this problem and call the manufacturer. But when will they make the call? Most likely it will be after supplies are low and we are at risk of shutting down manufacturing. In other words, it might be too late before we spot the problem. So instead, we model our process to include for provisions such as a timer that monitors when the product is received. Also we allow for the vendor to report an error in processing the order, which should prompt someone in my organization to reorder. And while we are at it, why not ask the supplier to broadcast system outage messages so that we know when to resubmit orders that might have been lost in transmission.
Ordering supplies with an error handling event and a timeout event
Hopefully this clarifies the usage of the event-based exclusive gateway. I hope you can now see that although the event based gateway uses a pattern difficult to understand, it’s well worth while learning. It’s one of the most powerful shapes in BPMN. Processes are not linear and don’t always function like clockwork. Modeling in the flowchart style with swimlanes and everything being perfectly sequential doesn’t depict the true nature of business processes. In the real world, processes are event based, and 65% of the time things don’t follow the optimal plan. By using an event based process model you are more likely to uncover the subtle details and pockets of inefficiency.
Leave a Comment
You must be logged in to post a comment.
