Figure 146: When a cancelation message is received, the effects of the finished activities are reversed
The term “transaction” is used in different contexts. For example, there are business transactions, such as a money transfer from one bank account to another. In computer science, especially database transactions are well-known. The different types of transactions have in common that they are always complete units of work. A transaction can either be carried out in its entirety, or not at all. If something goes wrong, the transaction must be rolled back.
During a money transfer, it might turn out that the receiver’s account number does not exist. Then the money must be transferred back. If the computer crashes while a customer data set is being saved, the database system will roll back the database to the original state before the saving operation had been started. Thus, it prevents incomplete data sets causing an inconsistent state of the database.
Parts of business processes can also be treated as transactions. A typical example is the booking of a journey which involves separate bookings of a flight and a hotel. The booking of the entire journey is only successful if both the flight and the hotel have been booked successfully. If the hotel has been booked and it then turns out that there is no flight available anymore, the booking of the journey has not been entirely completed. In this case, the hotel booking needs to be reversed, i.e. it must be canceled at the hotel. Since such booking procedures including inquiries and answers may take many days, business process transactions are also called long-running transactions.
For modeling transactions, the process from figure 129 in chapter 8.1 is used again. There, the sub-process “Process Order” will be aborted when the event “Cancelation received” occurs. According to the model, a cancelation fee may be invoiced. Apart from that, the process is finished.
A closer look reveals that in fact the abortion of a sub-process entails further activities. In the sub-process, first the order is checked, then the goods are removed from stock, and finally they are packed. Depending on the point in time the cancelation arrives, it is possible that the goods have already been removed from stock or packed. In these cases, it is necessary to put the goods back into stock, or first to unpack and then put them back into stock.
Thus, the effects of the activities already completed must be reversed. This can be reached by defining compensating activities for the sub-process’s activities. “Check Order” does not need to be compensated. The compensating activity for “Remove Goods from Stock” is “Put Goods into Stock”. “Pack Goods” is compensated by “Unpack Goods”.
Figure 146: When a cancelation message is received, the effects of the finished activities are reversed
Figure 146 shows how the required compensations could be modeled with basic BPMN constructs. When the interrupting event occurs, it needs to be distinguished whether the goods have already been removed from stock. If this is not the case, nothing needs to be done.
If the goods have already been removed from stock, it must be determined whether they are already packed. In this case, the activity “Unpack Goods” will be carried out first. In both cases, the goods will then be put into stock again.
The rounded rectangle with the dash-dotted line is a group. It only serves presentation purposes, such as highlighting interesting parts of a model, or grouping elements that belong together, as it is the case here. The control flow logic of the model is not influenced by a group (cf. chapter 13.1)
This model is rather intricate. The handling of the exception is larger than the normal flow. It can be easily imagined what would happen if a sub-process contained many more activities which could be executed in various sequences. The part of the model containing the compensations would become very huge since all possible combinations of completed activities would need to be distinguished.
Another way of modeling this case is shown in figure 147. Here the border of the subprocess “Process Order” is drawn with a double line, thus marking the sub-process as a transaction. A transaction must either be carried out completely or not at all. This means that aborting a transaction automatically reverses the effects of the activities that have already been executed. In order to enable this, a compensation activity is assigned to each activity that requires compensation.
The activity “Put Goods into Stock”, for example, contains a rewind symbol (two arrowheads), identifying it as a compensation activity. It compensates the activity “Remove Goods from Stock”. This assignment is modeled with a compensation association and a compensation intermediate event attached to the boundary of the activity to be compensated. Not only tasks but also sub-processes can be marked with a rewind-symbol and be used as compensating activities.
Catching intermediate events of the compensation type are only used for this purpose. They are always attached to an activity, and they always have outgoing compensation associations running to the compensating activity. The compensation association is a dotted line with an arrow. It must not be confused with message flow.
The activity “Check Order” does not have a compensating activity, because it does not have any effects that need to be reversed. It would not make sense to “uncheck” a checked order.
If the transaction is aborted, it will be checked which activities have already been carried out. Only for these activities, the assigned compensation activities will be executed one after another – in the reversed order of the original activities.
Figure 147: Model with a transaction and compensating activities
What does this mean for the example process? If only the activity “Check Order” has been carried out, no compensation takes place in case of cancelation, because there is no compensation defined for this activity. If the goods have already been removed from stock, they will be put back into stock. If the goods are even packed, they will first be unpacked and then put into stock again. Thus, the flow following an abortion of the sub-process “Process Order” is exactly the same as the exception flow in figure 146 involving several gateways.
How is a transaction aborted? One possibility is to trigger the abortion from the outside. If the process is executed by a process engine, an administrator can react to an error that cannot be handled otherwise by aborting the process via the engine’s administration component.
In such a case, first the compensation activities are carried out, as described above. Then a token is passed to the modeled exception flow. For this, there is a catching intermediate event attached to the transaction boundary. This intermediate event type is called “cancel” and contains a blank cross. The cancel intermediate event indicates that the sub-process is not just aborted, but the compensations will be carried out first.
In the case of serious errors, it may happen that it is not possible anymore to abort the transaction normally, including compensations. A defect in the storage equipment may cause not only the need to abort the transaction, but it may also inhibit putting goods into storage. For such a case it is possible to add another exception flow without previous compensations. This could be modeled with a normal error intermediate event attached to the transaction boundary. However, in practice, it is not feasible to model every conceivable case.
The normal abortion of a transaction can not only be triggered from the outside, but also from within the process. This is modeled by an end event of type “cancel”. Its symbol is a filled diagonal cross. If this end event is reached, the entire process will be aborted, just as when a terminate end event is reached. In the case of the cancel end event, however, the required compensations are carried out, and then the exception flow starts at the catching cancel intermediate event.
In the example, the transaction must be aborted when the event “Cancelation received” occurs. While in the model of figure 146 the catching message intermediate event is attached to the sub-process boundary, this is not possible for a transaction. A normal interrupting intermediate event would trigger the exception flow without performing the compensations, as described above.
A catching cancel intermediate event must be used instead. This is triggered when a throwing cancel end event is reached within the transaction. Therefore, two parallel paths are created by the parallel gateway. In the sequence flow at the top, the activities are performed. At the same time, the parallel sequence flow at the bottom waits for the occurrence of the intermediate event “Cancelation received”. If this intermediate event occurs, the cancel end event is reached, i.e. the transaction is aborted. Then the required compensations are carried out and the exception flow at the attached cancel intermediate event is triggered. Since the cancel event aborts the entire transaction, the path at the top is aborted, as well.
If the transaction is not aborted, the end event of the upper path finally will be reached. In this case the bottom path is still active, i.e. a token still waits for the reception of a cancelation. Therefore, it would not be correct to use an untyped end event because this would only terminate the upper path. Instead, a terminate end event is used that finishes the entire transaction sub-process, including the lower path. In this case, the transaction has been completed successfully, and the process continues with the normal sequence flow. The next activity to be performed is “Ship Goods”.
Compensations can be modeled without transactions, as well. For this, throwing compensation end or intermediate events can be used. They contain filled rewind-symbols.
In figure 148, the process for booking and approving a business trip has been modeled. Here it is assumed that the travel will only be approved when the exact dates and prices of hotel and transport have been provided. Therefore, in this process, the booking activities take place before approval.
The activities “Book Flight” and “Book Hotel” both have compensation activities assigned. However, these activities are not part of a transaction, so that the compensations cannot be triggered by aborting a transaction. They must be called explicitly.
Figure 148: Direct call of compensations
The exclusive gateway after requesting the approval has three exits. In the first case, the request is approved, and the process finishes with an untyped end event. There are no compensations required. In the second case, the request is completely rejected. The sequence flow runs to a throwing compensation end event. This event does not have any label. Thus, it triggers the compensation of all completed activities in reverse order. Both the flight and the hotel booking are canceled. The activity “Request Travel Approval” does not have a compensation activity, so it is not compensated.
In the third case, the travel is approved, but it is not approved to travel by plane. Therefore, only the activity “Book Flight” must be compensated, but not the activity “Book Hotel”. This is indicated by naming the activity to be canceled in the label of the throwing intermediate compensation event. If required, it is also possible to specify several activities in the label of a throwing compensation event. In this example, however, only the compensation activity “Cancel Flight” is carried out. Afterwards, a train journey is booked, and the process is finished.
In this model, it is not possible to book a train in the first place. This, of course, is not very reasonable, but the model should be kept rather compact in order to illustrate the essence of the BPMN structure to be illustrated, just like all examples in this introductory book.
Compensations can also be handled by event sub-processes. They have compensation start events. In contrast, to other event sub-processes as discussed in chapter 8.5, they are not triggered by an event of the surrounding process. Instead, they are started when a throwing compensation event of the same name occurs after that process. Thus, the event sub-process will only be performed after the surrounding process has been finished.
The border of the compensation start event is always drawn as a solid line. In normal event sub-processes, this indicates that the surrounding process is aborted. Since a cancelation is only carried out when the surrounding sub-process is already finished, there is no distinction between a non-interrupting and an interrupting compensation start event.
In figure 149, a travel agency organizes the visit of a festival for its customers. For this, they first book the journey and then the tickets for the festival. The activity “Book Journey” has a compensation activity; the festival tickets, on the other hand, cannot be returned.
After the festival visit has been organized, the process waits until either the deadline is over, or a cancelation is received from the customer. In this case, the compensation end event “Cancelation of festival visit” is reached. Now the event sub-process is started via the compensation start event with the same name as the throwing end event. In the event sub-process, the compensation for “Book Journey” is triggered. Since unfortunately the festival ticket cannot be returned, the travel agency issues a voucher of a smaller amount of money to the customer which can be used when booking the next journey.
Since in the main process the end event has already been reached, the entire process is completed with the end of the “Process Cancelation” event sub-process. It would also have been possible to trigger this sub-process by a throwing compensation intermediate event, after which the process would be continued.
Such a compensating event sub-process can be used if not only the compensation activities need to be performed in the case of a cancelation, but also other activities. Although it is a bit more complicated to figure out in which case which activities have to be compensated in which order, such an event sub-process provides a sophisticated way of modeling such complex scenarios.
The concepts for modeling exceptions, transactions, and compensations, as they have been described in this and the previous chapter, originally have been developed in software technology. They are especially interesting for modeling executable workflows. In principle it is also possible to use them in business-oriented models, since errors, exceptions, cancelations, etc. also occur in non-automated processes. The examples used for the explanations have been deliberately taken from the business domain.
Some BPMN experts point out that many process models almost exclusively consider normal processes in which everything runs as expected. However, a large portion of problems and the effort involved in managing business processes results from errors, exceptions, and special cases. Therefore, they recommend to model exception flows, as well, using the special constructs provided by BPMN (cf. e.g. [Silver 2012]).
On the other hand, in contrast to the basic BPMN elements, these constructs need a lot of explanation, and they are not easy to apply. Exact models of all exceptional cases will become very large and detailed. It needs to be decided whether they yield an appropriate benefit to the target audience and whether the required effort is justified. This depends on the modeling purpose.
In principle, some of the more technical concepts can be transferred to the business level, but this may cause additional problems and questions.
For example, compensating a booking transaction in a computer system can be achieved rather easily by creating a compensating entry into the system. The above example concerning the booking of a flight or a hotel is not that easy in practice. For example, a cancelation may be ruled out for budget tickets, or it may be possible only within a certain time span, or it may cost an additional fee. In some cases, it is better to alter the person or the date of a booking instead of canceling it entirely. Each of these cases can have different effects on a process. Just modeling a compensation activity does not accurately reflect all these cases.
It needs to be decided in advance whether, how, and how detailed such cases should be modeled. This should be documented as modeling conventions.
