Overview
The Transactional Sub-Processes are offered to facilitate the implementation of business scenarios with transactions whose execution could last many days or weeks until the set of Activities is completed.
From a business perspective, a transaction is a set of activities that constitute a logical unit of operation that must be performed atomically (indivisible). It is supported by a special protocol that ensures that all parties involved have completeness agreement that the Activity should be completed or canceled.
A transaction or transactional Sub-Process is performed successfully when the changes to be implemented (update, addition or deletion of records) are saved in the database; in other words, the changes are committed once the transaction has ended.
Exceptions or Cancellation Events are launched without affecting the information or integrity of the database when the transaction is not successfully completed. Transactions can be short or long depending on the type of tasks to be executed, which can be automatic or manual.
The long lasting transactional BPMN models have three possible outcomes:
•The first outcome is when all Activities in the Process are successfully performed, the Process continues with the normal flow.
•The second outcome is when a failure occurs, and it is necessary to reverse all Activities that have already been completed within the Process. This is achieved through the execution of compensation Activities. Each Activity that needs compensation has one task associated to it. Compensation is executed when it is necessary to return to the initial state of something and is only performed when an Activity has successfully ended.
•The last outcome occurs when an unexpected error is presented, the transactional Sub-Process activities are interrupted without any compensation and the Process continues with the Intermediate Error Event.
To model a transactional Process it is necessary to attach the Error and Cancel Events to the Sub-Process. If any of these two Events occur the flow will be able to continue.
The edge of the transactional Sub-Process figure will be displayed with double line.
Transactional Sub-Process Shape
Modeling Transactional Sub-Processes
Imagine a typical transaction example where money is being transferred between accounts.
A debit is performed in one account to credit an amount in another account. The debit and credit actions are performed independently, using bank-specific interfaces.
The debit must be reversed when a problem occurs (wrong account number, inactive client, and so on), and the execution of a new action is required to reverse or compensate the transaction. In this case the transaction is terminated with no funds transferred.
The diagram of the Process would be:
The Transferring Funds for Disbursement process can have three different outputs: normal, cancellation and exception.
Normal
In the normal process flow the debit and the credit operations are performed correctly. Bizagi saves the changes executed in the database (commit is performed) and continues with the sequence of the normal flow of the Process when the transaction is completed successfully.
In the image below the Process performs the transference of funds using an interface implemented with Web Services, which debits the amount and credits it to another. The Process continues with the normal flow and continues with the Activate Credit Task as soon the transactional Process is performed correctly.
Cancellation
The Cancellation Event is triggered when a failure occurs and an exception is thrown (cancellation is performed). In this case, the process performs the compensation activities required and leaves the Sub-Process to execute the cancellation flow. The data modified within the Sub-Process will not be stored in the database; therefore, the Process will be reversed to the last stage previous to the execution of that Sub-Process.
The following flow clarifies the operation of the Cancellation Events:
1.An account is successfully debited through the execution of an interface.
2.The credit to the customer’s account is tried, but the account number is wrong and thus, rejected. The second interface generates an error result and the Cancellation Event is triggered.
3.Bizagi executes the compensation Activities in the reserve order as they were executed. In this case the task Compensate Debit is the only compensation and is in charge of undoing the transaction performed by the Debit task; therefore, an interface has to credit the previously debited amount.
4.The credit suspension is performed because the transferring of funds could not be completed.
|
Cancellation Events can only be defined for transactional Sub-Processes. |
Compensation Activities
Compensation Activities must restore the information that was changed in the Activity that was successfully performed. Usually this compensation Activities are performed over external systems. The compensation Activities are created using the Intermediate Event of compensation:
Exception
An exception error is thrown when there is an unhandled error within the transactional Process that does not allow the Sub-Process to continue; the Activities are interrupted without compensation. The information of the database is restored to its initial state (rolled back) and the Process continues by the Intermediate Error Event. The exception handling is done using an Intermediate Error Event.
The following flow clarifies the operation of the Cancellation Events:
1.The debit to the customer’s account is tried, but the server is not responding. The interface generates an error result and the Error Event is triggered.
2.The transfer is performed by phone and the transaction is concluded.
|
Consider the following: •External interfaces must be compensated adequately when these interfaces have been implemented within a Process, to perform modifications on data external to Bizagi through Web Services or component library. Activities that perform reversal for multiple cases must be avoided because the Activity does not know which Activities were completed successfully and which ones must be reversed. •Error Events can only be defined for transactional Sub-Processes. |
Last Updated 7/16/2024 9:59:55 AM