A customer wishes to withdraw a cash amount from a particular branch of his bank. However, his account is held at another branch. Each branch uses their own UTM application for data management.
When the customer makes his withdrawal, data in both UTM applications must be updated, i.e. the cashier’s balance in one application and the customer account balance in another. This is achieved by means of a single dialog transaction distributed across both applications (distributed transaction). The individual cash transactions (cashier and customer account) are posted in local dialog services. The diagram shows how these local dialog services communicate with each other.
Figure 18: Dialog job with global transaction management
The “GIRO” service in the UTM application APP1 functions as the job-submitting service. This service addresses the job-receiving service, i.e. the “POST” service in the UTM application APP2, in the dialog program unit PU11.
The program unit PU11 completes its processing step but leaves its transaction open. The program unit PU21 in the “POST” service receives data by means of a dialog message. PU21 returns a dialog response to the job-submitting service and then requests an end of transaction from openUTM.
This dialog response triggers the follow-up program unit PU12 in the “GIRO” service, which terminates the posting job and then requests an end of transaction. openUTM synchronizes the two local synchronization points (= end of transaction) and sets a common synchronization point. The two local transactions (in application APP1 and application APP2) thus form a synchronization unit, in other words a distributed transaction.
If an error occurs before the common synchronization point is set, the entire synchronization unit, i.e. the two local transactions, is rolled back.