A process with an event-based gateway (click to enlarge)
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.
Waiting for events in a sub-process (click to enlarge)
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.
A waiting task with interrupting events (click to enlarge)
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“:
Thomas:
Are Events and Gateways Necessary to Model A Process?
In my assessment NO. My reasons:
1: An “event” is an occurrence–something that happens. It is a detectable input from an identified or unidentified process to the process under consideration. This will take care of business and natural events.
2: A “Gateway” is an identified activity or process which is anyway well represented.
Thus, there is no need to explicitly model events, triggers, gateways (event or data based) and process modeling can be significantly simplified.
PVN 03SEP16
Missing Elements of Process Model
Most process models represent only three elements, namely inputs, activities and outputs (inputs and outputs are of the same kind) but there are THREE more critical and essential elements to fully represent processes. They are 1. Performer of Activity 2 Process Resources and Consumables, 3 Undesirable inputs, outputs and feedback (which is a special kind input or output).
Please see http://www.slideshare.net/putchavn/1-c-comprehensive-radical-process-representation-23sep13 for details.
Putcha, thanks for your comments. You are right, there are several aspects of a process that are not represented in a BPMN diagram.
According to my experience, gateways and events are useful concepts to depict the process flow and things like interactions between different processes, handling exceptions etc.
Two remarks:
– I see the Problem of deflagration in both of the BPMN diagrams – althogh this is very unlikly it can occur that if the inquiry is in execution and just in this moment the customers confirmation is received the receiving event will deflagrate. In my opinion a non-deflagration solution is to make the timer-event non-interrupting. In this case the sequenceflow after activity „Inquire about…“ should be drawn into an end-event. In this case the waiting activity can receive the customers confirmation at any time.
– In my optinion there is doubling in the waiting activity. In my point of view the activity waits until a message is received – then a normal sequence-flow can leave the activity. What is the added value of interrupting the receive-Task with the same event?
Best regards.
You are right concerning deflagration. In fact, the problem also exists in the original diagram with the event based gateways. In a pure analysis diagram, this inaccuracy may be accepted in order to keep the model compact and easily understandable. In an executable model, it’s necessary to solve the problem. In many BPM-systems, the presented diagrms will work nicely, because it is common to buffer messages that arrive too early. So if the confirmation arrives during execution of the inquiry task it will be buffered, and when the process proceeds, the message can be consumed without further waiting. However, message buffering is not part of the BPMN standard, but a proprietary (albeit common) extension.
I like your solution with the non-interrupting timer event. There’s only one minor issue: If the timer event has been triggered, and the inquiry task is in a user’s task list, the arrival of the confirmation will not cancel the inquiry task – so that an inquiry is carried out although it’s not nessary any more. To prevent that you could put the whole waiting and inquiry logic into a sub-process which is terminated by a teminate end event after the reception of the confirmation message.
A similar solution (not using attached events, but events in parallel sequence flows) would be:
https://www.kurze-prozesse.de/blog/wp-content/uploads/2016/09/Order-from-warehouse-parallel.png
Concerning the waiting task: You are right, if you make the task a message receiving task, it could handle the message and have a normal outgoing sequence flow. Usually I try to use events for receving messages rather than tasks (since the arrival of a message has the character of an event). Therefore, the dummy waiting task has been used.