If you want to model the reactions to different events in a BPMN process, the event-based gateway is very useful. At a normal exclusive splitting gateway, a sequence flow is selected based on data. It is therefore called data-based gateway. For example, a procurement request may be routed to a manager for approval if the total amount exceeds a certain limit. At an event-based gateway, on the other hand, a sequence flow is selected based on the occurence of an event. There must be a catching event (or a receive task) in each outgoing sequence flow. When the gateway is activated, the process waits until one of the following events occurs. The first event to occur wins, and the respective sequence flow is selected.
In the above figure, a warehouse order is entered into a software system and sent to the warehouse. The process then waits at the splitting event-based gateway until a confirmation is received or until one day is over. If the first event is the reception of the confirmation, it is checked for correctness, and the process is finished. If, however, one day is over before the reception is received, the upper path is selected, and the status of the order is inquired from the warehouse, before the process waits again for a confirmation to arrive. In real life, it would be necessary to add a data-based gateway after the timer event so that the process can be finished after several unsuccessful inquiries, thus preventing an endless loop.
Unfortunately, not all BPM systems for process execution have the event-based gateway in their palette of modeling symbols. For example, I am using the free community edition of Bonita in my lectures which unfortunately does not have the event-based gateway. It is therefore necessary to find another way for achieving the same behaviour as described above. Finding such a workaround can be a good exercise for improving the understanding of the BPMN flow logic.
One possible solution is shown in the following figure. Here, a sub-process has been used for modeling the wait. When the sub-process is activated, the sequence flow is split by a parallel gateway into two parallel paths, since the process waits for both events at the same time. In the parent process, a boolean variable has been defined to indicate whether the confirmation has been received in time. By default, this flag has the value true. If the event „Confirmation received“ is the first one to occur, the sub-process is finished, and the data-based gateway in the parent process selects the lower path, since the flag still has the value „true“. The terminate end events in the sub-process are required to finish the sub-process when one of the events is triggered. Otherwise, the sub-process would continue to wait for the other event.
If one day is over before the confirmation is received, the flag’s value is set to „false“, and the upper path is selected at the data-based gateway in the parent-process. Before the sub-process is activated again, the flag needs to be reset to its default value „true“. This is not modeled as a separate task, but it is included in the inquiry task.
The next figure shows another possibility for achieving the same behaviour. The task „Waiting for Confirmation“ is more or less a dummy task, because it doesn’t do anything – other than waiting. This task does not finish in a regular way, but only via the attached interrupting events. When the first interrupting event occurs, the waiting task is aborted, and the event’s outgoing exception flow is activated.
When implementing this process in the BPMS, the endless waiting of the task has been achieved by assigning the task to a dummy user, i. e. a user that does not belong to a real person. The task therefore waits in a task list that nobody ever gets to see – before it is aborted by an attached event.
Since the process starts with an explicit start event, it may be considered incorrect to have an activity without a regular outgoing sequence flow. It would not be any problem to add such an outgoing sequence flow leading to an end event. However, this sequence flow would never be used.
More about BPMN in the second edition of „BPMN 2.0 – Introduction to the Standard for Business Process Modeling“: