A transactional collaboration is a collaboration whose data modifications can be rolled back. Like database transactions, transactional collaborations are all-or-nothing operations: either the entire collaboration succeeds or the entire collaboration fails. In addition, a transactional collaboration can detect and react to data isolation violations that might compromise the logic of its data operations.
Transactional collaborations are based on the principles established in database transactions and two-phase commit protocols. However, transactional collaborations differ from database transactions because of the unique nature of collaborations: distributed across any number of applications, asynchronous, long lived, and positioned outside of applications rather than inside them.
A transactional collaboration and a nontransactional collaboration execute differently. A transactional collaboration executes under the control of the InterChange Server's transaction service, which controls execution, rollback, and isolation checking.
This section describes the components of transactional collaborations.
A collaboration template's Minimum Transaction Level property determines whether the collaboration is transactional, and applies to all of its scenarios. All collaboration objects created from a template inherit its minimum transaction level.
Actual transactional logic applies at the scenario level. In a transactional collaboration, each scenario is a transactional scenario, whose start implicitly begins a transaction and whose successful completion implicitly commits the transaction.
Each scenario runs in a single execution context. If a collaboration is part of a collaboration group, a scenario might call another collaboration to do some work and then return. The scenario that is called executes within the caller's execution context and is part of the same transaction.
Each time a step in a scenario causes an application to modify data, that step initiates a transaction in the application itself. A step that causes an application transaction is a subtransaction step: a transaction within a transaction, where the larger transaction is the scenario itself.
To illustrate transactional concepts, this chapter uses the scenario shown in Figure 39. The scenario handles updates as part of a pricing management collaboration. The collaboration ensures that when an ERP application changes the price of a product, the change is matched in the customer service application and product configuration application. The illustration omits all processing details that are irrelevant to transactional semantics.
The scenario has four action steps, Action 1 (A1) through Action 4 (A4), and it interacts with three business objects, A, B, and C. Business object A represents a particular product in the ERP system, B represents the same product in the customer service application, and C represents the product in the product configuration application.
The scenario appears on the left. On the right, comments show what happens when a product manager logs into the ERP system and changes the price of the product to $700.
To make the scenario transactional, the first step is to identify the subtransaction steps. Figure 40 shows that the subtransactional steps in the scenario are A2 and A4, because they cause transactions at the customer service and product configuration applications, respectively.
Figure 40. Subtransaction steps in a transactional scenario
A step that performs a retrieve request, such as A1 or A3, is not a subtransactional step because it does not cause the modification of data.
The way that a transactional scenario responds to failure differs from the way that nontransactional scenarios respond to failure. When a nontransactional scenario fails, the collaboration simply logs an error and terminates. When a transactional scenario fails, the scenario rolls back to leave data in a consistent state across all of the involved databases.
When an error occurs, subtransactions might have already caused applications to commit work. Therefore, rollback is done through the use of compensation steps, actions that counteract the effects of other actions. A compensation step executes only during rollback.
During rollback, the InterChange Server steps backward through the execution path. For each subtransaction step that completed, the server executes the associated compensation. Rollback is complete when all executed transactional steps have been compensated. If an error occurs during rollback, the InterChange Server simply logs the error.
A compensation step can consist of any action that a collaboration
developer wants to use to counteract the original action. Table 8 lists some common ways in which a collaboration developer
might choose to compensate for specific actions.
Table 8. Compensation Examples
Action | Compensation |
---|---|
Create business object | Delete business object |
Delete business object | Create business object |
Update business object | Update business object, restoring the former values |
Although compensation typically consists of reversing the original action's data modifications, it need not do so. For example, compensation for a create request could be another create request, this time causing a record to be written to an audit log. Compensation is therefore a logical undo operation, and not necessarily an actual undo operation.
A collaboration designer must design the scenario to enable rollback to occur. Figure 41 shows how the example scenario could be modified to permit rollback.
Figure 41. Actions and compensations
The example has changed as follows:
Imagine that the scenario encounters an error after executing A2. During rollback, compensation step C2 executes, using the value stored in B1 to return B to its original value.
The following figure illustrates execution of the sample scenario. In the illustrated runtime sequence, action steps A1, A2, and A3 execute successfully. During the execution of A4, however, an error occurs at the application. When the scenario receives an error instead of a successful status for A4, it fails, and rollback begins.
Stepping back through the steps, the transaction service proceeds as follows: