Transactional
From Business Process Management, BPM and Workflow Automation Wiki | BizAgi BPMS
<keywords content="keywords"> transaction, transactional, transactions, long lasting transactions </keywords>
Contents |
Transactional Sub-process
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 insures that all parties involved have completeness agreement: that the activity should be completed or cancelled.
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 commit of the changes is performed 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. The transactions can be short or long depending on the type of tasks to be executed, which can be automatic or manuals.
| Example:Transferring money between accounts is a typical transaction sample. The execution of two different web services can be required by the transaction of transferring money such as debiting from one account and crediting to another account. A debit must be reversed when the second web service has a problem (wrong account number, inactive client, and so on); thus, the execution of a new web service can be required to reverse or compensate the transaction; the external system will be notified by the new web service, so that the amount debited from one account can be reversed. |
These business situations can be flexibly modeled with the BPMN standard, which offers a set of rules for their graphical representation; thus, the routing process when the transaction is not successfully completed can be naturally represented. -
Related Articles: How to model a Transactional Process
Configuration of Transactional Sub processes or Transactions
The “Transactional” property is configured in the Bizagi properties of the sub process figure in the tab of global properties. The edge of the figure will be displayed with double line when defining this property in a sub process; the double line will indicate the transactional nature of the figure.
For further information about the transactional notation (shapes) go to BPMN, or Shapes
Example of transferring funds for disbursement:
The debit from the merchant account and the corresponding credit in the client’s account are performed after the credit is approved and the authorization of the bank is issued. These processes of interface with the bank are performed through Web Services that executes the transactions independently. The diagram for this process would be the following:
The transferring funds process can have three different outputs: normal, cancellation and exception.
Normal path: Bizagi saves the changes executed in the database (commit is performed) and continues with the sequence of the normal flow of the process responsible for the invocation when a transaction is completed successfully.
|
Example: In the graphic, the Credit Request process performs the transfer of funds to be disbursed using an interface implemented with Web Services, which debits the amount of the accounts from the entity and credit the customer’s account. The process continues with the normal flow and activates the credit because the transactional process was performed correctly. |
Cancellation : This event is triggered when a failure occurs and an exception of cancellation is thrown. The process performs the activities of compensation required for each one of the sub process tasks and leaves the sub process executing the cancellation flow. The data modified within the sub process are not stored in the database; therefore, the process will be reversed to the last stage previous to the execution of that sub process. The first activity of the cancellation output has access to the data before the reversal to the original state, which will allow displaying information where the user will be notified about the cancellation reason; the data are reversed to the original state once the output is completed.
|
Example: The following flow clarifies the operation of the cancellation events: 1. The merchant account is successfully debited through the execution of the web service.
2. The credit to the customer’s account is tried, but the account number is wrong and rejected by the web service, which generates a result 101 (Error that indicates nonexistent account); the rule of the task “Crediting” detects the code 101 and the cancellation event is triggered. 3. Bizagi executes inversely all the activities of compensation; the task “Compensate Debit” is the only activity associated to the debit task. This task “compensates” the transaction performed by the “Debit” task; thus, a web service crediting the merchant account for the corresponding amount is performed and the operation is fully reversed. Bizagi starts the cancellation process with the “Suspend Credit” because only one activity of compensation exists. 4. The credit suspension is performed because the transferring of funds could not be completed. |
 |
Error Intermediate event: An exception error is thrown when occurs an error within the transactional process that does not allow the sub process to continue; the activities are interrupted (without compensation), the information of the Bizagi database is restored to its initial state (rolled back) and the process continues by the intermediate error event. The information of the external system is not restored to its original stage when the data of the external system are affected within the transaction.
|
NoteExternal interfaces must be compensated adequately when these interfaces has been implemented within a process to perform modifications on data external to Bizagi through Web Services or component library. The respective reversal must be defined in the compensation task. Activities that perform reversal for multiple cases must be avoided because the activity does not know what activities were completed successfully and what activities must be reversed. In the example the debit activity must have a compensation task to reverse the debit and the credit must have a compensation perform the reversal. A compensation activity in the debit that performs the debit and credit must be avoided because the task will not be able to determine whether the credit was completed correctly. The general rule is that the reversion of external agents must be performed through compensation activities associated to the task that performed the action. Normal tasks should not be used for this purpose because these tasks alter the normal flow. These tasks should not be performed within sub process activity output because this is not the function of this task. |
 |
The compensation activities are used to perform reversions on data no controlled by Bizagi; for example web services that have been executed or interfaces on other systems performed through the Component Library. These activities must only be used in transactional sub processes, and they only will be useful in these sub processes.
The compensation activities are created using the intermediate event of compensation:
Drag the compensation event towards the activity to be compensated and later on the task to be used as compensation: Manual, Service or Sub process (no transactional and without multiple instances).
|
Note : Do not forget that the compensation activity must restore the state of the external systems affected by the activity to be compensated; modifications on data of other activities must not be performed. |
How to execute a cancellation or exception
The web services that perform the debit and the credit returns 0 (zero) whether the transaction was successfully completed; otherwise, a number different from 0 along with the error code is returned. The process can use this response to decide whether the cancellation of the process activities must be executed and therefore the reversion of the modified data; the figure of the cancellation is used for this purpose:
The modified process to launch the cancellation would appear as follows:
|
Example: In the example the web service is enrooted by the Cancellation figure (Cancellation Event) whether the Accredit web service returns an error code. Bizagi search for all the activities that have compensation, and starts to execute its compensation tasks. Finally, the Cancellation flow is executed, which starts with the task “Display report”. The reversion of the data modified by the subs process is performed once the task ends; thus, the parent process is returned to the original state. |
|
Note The exceptions of cancellation or error can also be sent through business rules. See launch cancellation or exception through API. |
How the transactions sub processes are visualized when an exception of cancellation or error is sent
The transactional sub processes in which a cancellation exception was sent are displayed in the Web of the following way.
The transactional sub processes in which an error exception was sent is displayed in the Web of the following way.
A screen showing the process that was cancelled by exception or compensation is displayed when the user clicks on the filing number for both cases.
Related Articles
Long Term Transaction <comments />
