Figure 128: Abortion of an activity by a timer intermediate event
Usually, it is rather easy to model the normal process flow. Capturing and documentting special cases and exceptions is more complicated and laborious. BPMN contains several specific constructs for modeling and handling exceptions.
When an activity is carried out, sometimes an event occurs that results in an early abortion of that activity. When writing an examination, it may happen that the time is over before the candidate has finished. Thus, the timer event “Time over” occurs during “Writing Examination”. This causes the activity to be aborted.
This is modeled by attaching an interrupting event to an activity, i.e. by placing it on the border’s activity (figure 128). Since the event occurs while the process is being carried out, it is an intermediate event. The activity “Write Examination” now has two outgoing sequence flows: a normal one, originating directly from the activity, and an exception flow that starts at the attached intermediate event.
If the event “Time over” does not occur during the examination, the activity will be finished regularly. A token is passed via the normal sequence flow to the activity “Submit Examination Sheet”.
However, if the event does occur, the activity will be aborted, and a token will be released via the downwards outgoing exception flow. The next activity is then “Collect Examination Sheet” (carried out by the examination supervisor). No token will be passed anymore to “Submit Examination Sheet” since the activity has been aborted. The attached event only has an effect if it occurs while the activity is being performed. If it occurs earlier or later, it will be ignored.
Figure 128: Abortion of an activity by a timer intermediate event
Figure 129: Aborting a sub-process when a message is received
An interrupting event can also be attached to a sub-process. In the process shown in figure 129, the entire sub-process “Process Order” is aborted when a cancelation is received. In this case, everything that happens within the process is completely terminated. If one of the three activities is being executed at that moment, it will be aborted. Activities that have not been started yet will not be executed anymore. When the sub-process is aborted, all tokens will be removed from within that sub-process, and a token will be emitted via the exception flow at the interrupting event.
If the order has been completely processed, in this example no cancelations are possible anymore. If a cancelation arrives nevertheless, it will be ignored.
When an attached intermediate event is used, it is also possible to leave the activity only through that event.
In figure 130, the daily work of a security guard has been modeled. Since there is no natural ending for the activity “Guard Building”, it is always finished by the timer event “Finishing time”. Here, the regular end event is not useful since it will never be reached. However, BPMN requires it. If there are any start events in a model, then every activity needs to have a regular outgoing sequence flow.
Figure 130: The activity will always be left via the interrupting event
Figure 131: A loop activity that is aborted by an attached intermediate event
The model in figure 131 is not so ideal. The activity “Sell Pastries” will be repeated until the closing time is reached. The problem is that the activity is aborted at once when the timer event occurs. If the salesperson is just in the middle of selling some pastries, in real life, he or she will complete the sale before finishing the work.
This example can be modeled in a better way according to figure 132. Here a loop with a terminating condition is used. This condition is evaluated only when each loop repetition has been finished. Therefore, a selling activity at closing time will be completed before the process is finished.
There is another variant of the attached intermediate event. In the previous models, the occurrence of the event always resulted in an abortion of the activity. Sometimes, however, it is desired to react to such an event, but still to continue the ongoing activity. In figure 133, the customer should be notified if his order has not been completed within five days, but the processing of the order must not be interrupted.
This can be indicated by using a dashed line for the intermediate event’s double border. If the event “5 days after order processing has begun” is reached before the activity has been finished, a newly created token will be passed via the exception flow to the task “Notify about Intermediate Status”. After this task, the token flows to the lower end event where it will be swallowed.
Figure 132: Improved process
Figure 133: The attached intermediate event does not interrupt the activity
At the same time, the original token still remains in the activity “Process Order”. When this task is finished, the original token is moved via the regular sequence flow, and the product is shipped. The process is finished when both tokens have reached their end events.
An attached non-interrupting event simply creates an additional token if it occurs during the execution of the respective activity. If both sequence flows should be merged by a gateway, it is not possible to use an exclusive gateway, since more than one token may arrive. A parallel gateway neither would be correct since only sometimes there will be a token in the lower sequence flow. Thus, an inclusive gateway would be required.
The message event also has a non-interrupting variant. In figure 134 the reception of an inquiry concerning an order triggers the task “Answer Inquiry”. The order is further processed in parallel.
Besides timer and message events, the following types of intermediate events (described in chapter 6.4) can be attached to activities: Signal events, conditional events, multiple events, and parallel multiple events (figure 135). Each of them can be used as an interrupting or a non-interrupting event, the latter with a dashed border. Of course, non-interrupting intermediate events not only can be attached to tasks, but also to sub-processes.
Figure 134: The non-interrupting version of the attached message event
Figure 135: Types of attached intermediate events: Signal, condition, multiple, parallel multiple. At the top the interrupting versions; at the bottom the non-interrupting versions.
The handling of exceptions is quite often required because of an error. For this, intermediate events of type “error” can be used. They are marked with a flash symbol. In contrast to the previous types of intermediate events, error intermediate events cannot be used within normal sequence flows. They can only be attached to activity boundaries.
Figure 136 contains a process in a laboratory. First an analysis is conducted, and then the results are evaluated. Should the analysis reveal that the equipment is defective, this would be an error which prevents the normal execution of the process. For this case, there is an exception flow in which the sample is sent to an external laboratory.
The activity to be aborted by an error event may also be a sub-process. In this subprocess, it is possible to model kind and origin of the respective error. Therefore, the catching error event is complemented with its throwing counterpart.
Figure 137 shows a sub-process with two throwing error events. After taking a sample, the sub-process is started. First the sample is analyzed. This is usually followed by checking the result. If the result is plausible, the sub-process finishes. If the result is not plausible, this is an error, and the throwing error end event “Result not plausible” is reached. In this case, the sub-process is aborted, and the thrown error is caught by the error intermediate event at the sub-process boundary. In this case, the exception flow is followed, and the activity “Arrange for External Analysis” is triggered.
Figure 136: When an error occurs, an exception flow is started
In the sub-process, another error may occur: If during the activity “Analyze Sample” it turns out that the equipment is defective (here also modeled with a catching error event), it will be repaired. If the repair has been successful, the analysis of the sample will be started again. In the case of an unsuccessful repair, the throwing error event “Equipment out of order” occurs. Again, the sub-process is aborted, and the error is thrown to the intermediate error event that triggers the exception flow to the activity “Arrange for External Analysis”.
Like in the other event types, the filled icon stands for a throwing event, while a catching event is represented by a blank icon. Throwing error events are always end events, because they completely abort the surrounding sub-process. Catching error events, on the other hand, are always intermediate events. They can only be attached to the boundaries of tasks or sub-processes.
In figure 137 there are two different throwing error events in the sub-process. Since the error intermediate event at the boundary does not have a label, it catches any kind of error from the sub-process – regardless from which error event it is thrown.
In some cases, however, it may be necessary to have different exception flows for different errors. For this, several catching error events can be attached to the subprocess boundary. If they are labeled with the names of the throwing error events, each event will only react to errors thrown by an error event of the same name.
The model in figure 138 makes use of this. If the error “Result not plausible” occurs, an external analysis should be arranged, as in the previous model. If the error “Equipment out of order” occurs instead, repair by the manufacturer should be arranged in addition to the external analysis.
If there are several error intermediate events attached to a sub-process boundary, they should always be labeled. Since an unlabeled error intermediate event always catches any type of error, it also reacts to errors with own labeled events. The implicit parallel flows resulting from such a combination of labeled and unlabeled events would be difficult to understand.
Escalation events are similar to error events. While error events are mainly used for technical problems, escalation events primarily stand for problems on a business level, e.g. if a task is not completed, a goal is not reached, or a required agreement is not achieved.
Figure 137: Errors occurring in the sub-process are forwarded to the error intermediate event at the boundary
Figure 138: Different exception flows are triggered by named error events
Like throwing error events, throwing escalation events can be used in sub-processes. An escalation is caught by an escalation intermediate event with the same name, attached to the sub-process border. The intermediate event again triggers an exception flow.
In contrast to errors which always abort the activity, escalations come in both variants: The interrupting and the non-interrupting event. Non-interrupting escalation events are regarded as the default.
The example of figure 139 starts with adding an incoming inquiry to a queue. After that, the expected duration for answering the inquiry is calculated. This expected duration depends on the length of the queue. If it turns out that the inquiry cannot be answered within the promised reaction time, a token flows to the throwing escalation end event. The escalation is caught by the non-interrupting escalation intermediate event at the sub-process’s boundary. This event then emits a token and triggers the activity “Arrange for Additional Personnel”.
Figure 140: Alternative model of the sub-process from figure 139
Since it is a non-interrupting intermediate event, the sub-process continues in parallel. If the inquiry is the first one in the queue, an answer will be written without delay. Otherwise, if the queue already contains other inquiries, it must be waited until all of them are completed. This is indicated by the conditional event “Inquiry has reached the beginning of the queue”. When this event has occurred, the answer is written and finally sent to the customer in the main process.
It may be confusing that there is an exclusive gateway for merging the two sequence flows because they originate from an inclusive gateway. However, if the conditions at the inclusive gateway are analyzed, it turns out that in any case exactly one of these conditions becomes true. Therefore, the merging by an exclusive gateway is correct. As an alternative, the model of the sub-process could be a bit more extensive, as in figure 140, which on the other hand requires more space.
Since an escalation usually does not abort the sub-process, it is not only possible to use an end event for throwing an escalation, but also an intermediate event (figure 141).
If an escalation is required to abort the entire activity, the attached intermediate event’s boundaries are drawn with solid lines (figure 142). In such a case, the throwing escalation event in the sub-process must be an end event. If a throwing escalation intermediate event were used, the subsequent sequence flow could never occur because the sub-process would be aborted by the escalation.
Figure 141: Sub-process with throwing escalation intermediate event
As in the case of error intermediate events, there can be several escalation intermediate events which can be distinguished by their names.
In contrast to an ordinary sub-process, an event sub-process is not triggered by a sequence flow, but by an event occurring during process execution. Therefore, an event sub-process does neither have any incoming nor any outgoing sequence flows.
Figure 143 shows a simplified software development process. At the beginning the requirements are determined, followed by the development. It may involve several iterations. Each iteration is planned before the planned features are implemented. The iteration steps are repeated until the software is completed.
In most software projects, change requests arise during the development. These are handled in the event sub-process “Process Change Request”. The dotted boundary distinguishes the event sub-process from a normal sub-process. It is triggered by the event “Change request received” – but only if this occurs while the main process is running. The start event’s border is dashed, i.e. it is a non-interrupting start event. The main process is therefore continued while the event sub-process is carried out. In this special sub-process first the feasibility of the required change is checked, and then the effort is estimated, and a decision is made about the implementation. If the change is to be implemented, it will be documented. In the main process, this documented change will be implemented in one of the following iterations.
Figure 143: Software development process with an event sub-process for processing change requests
During software development, several change requests may arise. Accordingly, the event sub-process can be performed several times. Several simultaneous instances of the event sub-process are also possible.
There is also the possibility to abort the surrounding process when an event sub-process is started. In this case, the start event is drawn with the normal solid line.
Figure 144 shows the sub-process “Produce Chemicals”. This sub-process itself contains two event sub-processes. The first one, “Adjust System”, is non-interrupting, as can be seen by the dashed line of the conditional start event. The system may be adjusted several times during production. By contrast, an error of the type “Critical problem” not only starts the second event sub-process “Conduct Emergency Shut-Off”, but it also aborts the process “Produce Chemicals”. This is indicated by the fact that the start event’s border is not dashed, but solid.
The interrupting event sub-process “Conduct Emergency Shut-Off” can be started only once during the execution of the sub-process “Produce Chemicals”, because after all this process is aborted. If the event sub-process ended in a normal untyped end event, a token would be emitted to the surrounding process’s outgoing sequence flow. In this example, however, an error end event is used, which again throws an error. This error is caught by the attached error intermediate event “Emergency shut-off”, and a token is emitted to the exception flow.
A start event of type “error” can only be used in event sub-processes. There is no dashed variant of the error start event, i.e. such an event can only trigger interrupting event sub-processes.
Most other event types can be used both as interrupting and non-interrupting events. Besides message events and conditional events, this is also true for timer events, signal events, multiple events, and parallel multiple events. In contrast to normal processes, the escalation event here can also be used as a starting event. The non-interrupting variants of the aforementioned events are only allowed within an event sub-process, but not in a normal process. Untyped start events, on the other hand, cannot be used in event sub-processes.
In the next chapter, the compensation event will be introduced as a further event type that can also be used as a start event in an event sub-process, but only as an interrupting event.
As it is known from normal sub-processes, event sub-processes can also be drawn in a collapsed state (figure 145). Like the expanded versions they have dotted boundary lines. In addition to this, the respective start event of each process is shown in the upper left corner. This event’s boundary – solid or dashed – shows whether the surrounding process is aborted or not.
