Details of our Transaction Modulation Method

Our TM method contains the following five steps in sequence.

1. Transform each process defined into a transaction, and attach an error intermediate event and a cancel intermediate event to the boundary of the transaction.

2. Append an exclusive gateway and a cancel end event on each sequence flow, in all transactions.

3. Append a compensation handler to all activities that do not have such a handler, in all transactions.

4. Add an independent timer event subprocess and an independent conditional event subprocess in each transaction, where the end of the timer event subprocess throws an error end event and the end of the conditional event subprocess throws a cancel end event.

5. Add an independent error event subprocess and an independent compensation event subprocess to indicate the compensation event for each activity in each transaction.

The compensation events are given in the reverse order of the activities; each split and merged flow in the compensation flows is connected with a parallel gateway.

The end of the error event subprocess throws an error end event and the end of the compensation event subprocess throws a none end event.

The first step of the method is to transform a BPMN process defined into a BPMN transaction because the activities of the process are atomic. The transformed transaction is viewed as an ACID transaction. To improve the capability of event handling of the transaction, an error and a cancel intermediate event are attached to the boundary of the transaction after the transformation is completed.

The next step of the method is to add cancel end events to the transaction because the transaction allows the participant to cancel its execution. When a cancel end event is thrown

30

from a transaction, the execution of transaction is interrupted. Besides, the completed activities of the transaction are compensated and the incomplete ones are rollback. To allow the participant to cancel the transaction at any time, an exclusive gateway and a cancel end event are appended to each sequence flow in the transaction to check whether the cancel end event is thrown or not.

The third step of the method is to add a compensation handler for each activity in the transaction. A compensation handler is responsible to compensate the original activity when catching the compensation event [12]. The compensation handler of each activity in the transaction makes the compensation process of the transaction to be clearer. Therefore, such a compensation handler is appended to each activity in the transaction in our method. Table 4.1 presents the rules of the step according to original activities.

Table 4.1 The Rules of Adding Compensation Handlers Contents

Activity Type

Original Activity Result of the implementation

(1)Task

(2)Subprocess

31

(3)Event handler

(4)Compensatio n handler

(5)Transaction

Table 4.1 shows that a compensation handler is appended to the original activity except for the rule (4) because it is added already in previous step. In rule (3) and (5), the compensation handler is appended to an event handler besides the original activity.

The fourth step adds two event subprocesses in the transaction for improving the capability of event handling of the transaction. These two processes are of predefined structure and defined as:

1. The timer event subprocess, responsible to direct the process to the error handling flow, defined in the next step, when the transaction is time-out.

32

2. The conditional event subprocess, canceling the execution of the activities in the transaction when an interrupted event occurs outside of the transaction. For example, when the other parallel ASA is canceled, an interrupted event is thrown away.

The last step adds two additional event subprocesses in the transaction. The activities and their flow inside both subprocesses are defined based on the workflow in the transaction, furthermore:

1. The error event subprocess, responsible to invoke a series of compensation activities when a hazard occurs in the transaction. After the compensation is completed, the event subprocess generates an error event to direct the flow to the error catcher attached to the boundary of the transaction.

2. The compensation event subprocess, a callback function for invoking a series of compensation activities when the corresponding compensation event is thrown away. When the compensation of the transaction is completed, the compensation event generator outside of the transaction continues the process.

BPMN [12] declares that both processes are not necessary. However, to make the structure more clearly, we ask designer to fulfill the step.

Table 4.2 The Rules of Constructing the Executive Order of Compensation Activities

Contents

33

(2)XOR-Split

(3)XOR-Join

(4)AND-Split

(5)AND-Join

34

Table 4.2 presents nine rules for constructing the executive order of compensation activities according to the control nodes in [12]. The execution order of compensation activities is the reverse of execution of the original activities in the transaction. To simplify the construction, when the original workflow has a split control node, a join node is adopted to merge the corresponding compensation flows. The all compensation activities are invoked but only the completed activities can be compensated. The rules of constructing compensation

(6)OR-Split

(7)OR-Join

(8)Event-Based XOR-Split

(9)Event Handler

35

flows are classified as three categories:

1. Sequence: In the rule (1), when the flows of activities are sequence, the executive order of compensation flows is constructed.

2. Split flows: In rule (3), (5) and (7), when the flows of activities are merged, the split compensation flows are constructed.

3. Merged flows: In the rule (2), (4), (6), (8) and (9), the compensation flows are merged because the flows of activities are diverged.