Transaction (BPMN)

A transaction is a series of tasks that are closely related to each other. The special execution rule is added so that the result is "success" when all the tasks are appropriately completed and "failure" when any of the tasks is not executed correctly.

Overview
In general, business processes consist of a series of tasks. Among those tasks in business processes, some are closely related to other tasks and could cause a serious problem if it is executed when other tasks related to it had any kind of errors. Let us think about an example in which "money is transferred between two accounts" to grasp the concept.



As illustrated above, when "money transfer between accounts" is executed, $50 is withdrawn from Account X, $50 is deposited into Account Y, and finally the balances of both accounts are set to be $150. Here, for example, if "money is transferred to Account X from another account" between "the withdrawal of $50 from Account X" and the balance update, the process to "set the balance to be $150" is incorrect. "Money transfer between accounts" can be correctly completed only when the withdrawal, deposit, and balance update are done consecutively and all of them are executed without any errors.

Such "a series of tasks that are meaningful only when all of the tasks are completed appropriately" are called a transaction.

There is the special execution rule that sets the execution results of tasks in a transaction to be, as a whole, whether "all tasks are executed" or "none of them is executed." The tasks are tentatively executed first, and if all the tasks are successfully completed, the process continues. Otherwise, all of them are undone and started over again. In the example described above, for example, if "the balance update for Account X" fails for some reason, all of "the $50-withdrawal from Account X," "the $50-deposit into Account Y," and "the balance update" are undone, and all the tasks are redone. If all the tasks are successfully completed, "money transfer" is considered to be completed.

The purpose of defining "transactions" is, as shown in the example above, to prevent business processes whose failure require the tasks to be stopped or to be redone from scratch from being executed with errors. Imagine the serious problem caused when "the balance is updated" before "$50 is withdrawn from Account A," and you will understand that defining transactions for such a series of tasks is truly effective.

Notation for Transaction
In BPMN, transactions are treated as either "Collapsed Sub Process" or "Expanded Sub Process," and their boundaries are represented with double lines. (See the figures on the right.)

Sub Process is also a set of tasks. However, the difference between Sub Process and a transaction is that the relationships among tasks in a transaction is very strong and constraints regarding their execution are placed on the tasks while Sub Process is merely a set of tasks.



Evaluation of Transaction
In BPMN, the execution result of a transaction is one of Successful Completion, Unsuccessful Completion (Cancel), and Hazard (Exception).

Successful Completion
This is a case in which all tasks in a transaction are completed correctly. The business process including the transaction proceeds normally.

Unsuccessful Completion (Cancel)
Unsuccessful Completion occurs in either of the following two cases. If a transaction ends up Unsuccessful Completion, the abnormal flow is executed instead of the normal flow. In this case, the normal business process is not executed, and none of the tasks in the transaction is done.
 * Any of the pre-determined criteria of failure of the transaction is satisfied.
 * "Abort" message is received from outside of the transaction.

In addition, as mentioned above, it is also possible to do "compensating rollback (rollback to make up for the failure)" to undo the entire transaction once and do it over again from scratch in case of "Unsuccessful Completion." However, a case in which "Unsuccessful Completion" occurs owing to problems outside of the transaction is out of scope of compensating rollback.

Hazard (Exception)
Hazard is a case in which a transaction can not be terminated, regardless of whether successfully or unsuccessfully, for some reason. When a hazard (exception) occurs, any of the tasks in the corresponding transaction ends up not being executed.

Example
As an example, a process to arrange a business trip is shown below.
 * Successful completion of business-trip arrangement
 * If the train and hotel reservations are completed

However, even if the train can not be reserved, the result is set to be successful if the airline reservation is done. ("Compensation")
 * Business process proceeds to "Business-trip Offer," which is a normal flow.


 * Unsuccessful completion of business-trip arrangement
 * If the reservations can not be made
 * Business process proceeds to "Date Change," which is an abnormal flow.


 * Hazard (Exception)
 * If any kind of problem happens
 * Business process is aborted.

In order to execute "Business-trip Offer," reservations for both transportation and accommodation must be completed. In case one of them can not be done, the other will be cancelled even if it has been successfully reserved.

Related Articles

 * BPMN
 * Business process
 * Sub Process
 * Business Process Diagram