Displaying items by tag: bpmn transaction
Transaction Modelling with BPMN 2.0
Often, when I am out and about delivering BPMN training to our clients, I am asked if it is possible to model the ability to “undo” certain actions within a process model.
The answer is of course yes, BPMN 2.0 provides us with the necessary tools to show this kind of action via transaction modelling.
As you may or may not know, BPMN 2.0 is broken down into several disciplines, see below:
The tools offered by the notation that allow us to undertake transaction modelling fall firmly into the realm of Analytical Modelling.
This means that for users of Sparx Systems Enterprise Architect, we will find everything we need in the toolboxes for BPMN Collaboration and Process diagrams.
Elements for Transaction Modelling
A Transaction Sub-Process refers to the coordinated execution of multiple activities such that they will all complete successfully or, in the event of a cancellation, the activities are rolled back to a state equivalent to none of them completing. To create a Transaction in Enterprise Architect, you first need to create a Sub-Process and then set the Tagged Value isATransaction in the element properties: |
This event will be triggered should the Transaction reach a state in which a Cancel End Event has been reached. The event will then Cancel (not just a clever name) all successfully completed activities within the Transaction that have defined compensating activities and undo them so that they are in a state equal to none of them having been completed. |
Note for Enterprise Architect Users: despite Enterprise Architect allowing you to set any intermediate event as a Cancel, this event type cannot be used used mid-flow and must be attached to a Transaction Sub-Process. |
Should this End Event be reached within a Transaction Sub-Process, it will then trigger the Cancel Event attached to the boundary of the Transaction. |
An Activity can only be rolled back if it has a Compensation Event set as an interrupting boundary event. This will then need to be connected to a Compensation Activity (or Sub-Process) via the Association relationship. To mark an activity for compensation in Enterprise Architect, you will need to access the element properties and set the tagged value isForCompensation to true: |
When triggered, this End Event will terminate the process and will itself trigger any Compensation Events within the process, and by association any Compensating Activities, allowing us to rollback after the successful completion of our Transactions. |
Approaches to Transaction Modelling
Self-Cancelling
When talking about transaction modelling and the phrase “self-cancelling activities” comes up, it is referring to any activities (including Sub-Processes) within a transaction that can be undone should a Cancel End Event be triggered.
A Transaction can contain a single or multiple self cancelling activities.
In the example below we can see that we have a Transaction Sub-Process (modelled as expanded) that contains multiple activities that can be undone when the Compensation Events are triggered by the Cancel Events.
Each of these compensable activities is then linked to a Service Task that is marked for compensation, and it is this Compensation Activity that roles the others back to a state where none of them have been completed.
Note: Whilst it is good practice for an Activity to have one sequence flow in and one out, the same is not true for Associations as can be seen in the example below. |
Deferred Cancellation
Deferred cancellation of activities happens when we model a way for our Transaction Sub-Processes to be undone after they have been successfully completed. We do this by implementing a Compensation End Event somewhere in our possible sequence of events. An example of this is shown in the process below:
Note: Whilst the example above has been modelled with the Transactions in expanded fashion this is has been done for illustrative purposes. It is better practice to keep things simple and model the Transactions in collapsed fashion and link to the other diagrams via abstraction. It is also worth noting that we do not model any link between the Compensation and Cancel End Events and the events that they trigger. I recommend using the same names for each, as per the examples above, to show that there is a logical link between them. |
This concludes our look at Transaction Modelling in BPMN 2.0, I hope you found it a useful explanation.
How can Dunstan Thomas help you with BPMN 2.0?
Dunstan Thomas have been Sparx Systems partners for the last 18 years, delivering training and consulting services around Enterprise Architect to organisations spanning multiple markets.
Leverage the knowledge and experience of our expert consultants to supplement your teams with services such as: