WO2021136575A1

WO2021136575A1 - Method and system for synchronizing isolated business transactions

Info

Publication number: WO2021136575A1
Application number: PCT/EG2020/000015
Authority: WO
Inventors: Ehab Mohamed Ibrahim EL-KERSH
Original assignee: El Kersh Ehab Mohamed Ibrahim
Priority date: 2019-12-29
Filing date: 2020-06-21
Publication date: 2021-07-08

Abstract

The invention generally relates to business automation, and in particular to distributed business transactions processing. The invention includes a new method for distributed transaction handling and a system that applies the new method. This method enables the transaction preparation phase to be decoupled from the transaction execution phase (commit phase). Said decoupling enables each part of the distributed transaction to be prepared in isolation from the other parts. "In isolation" means, in different place and in different time. Each prepared part should have a reference or a handle. The method completes the transaction by executing the commit phase using said "handles" together.

Description

Method and System for Synchronizing Isolated Business Transactions

Detailed Description

Technical Field

The invention generally relates to method and system for business automation, and in particular to distributed business transactions processing.

A business transaction means, a change in the business data. For example, a money transfer within a bank needs to change accounts data to deduct the amount of money from the source account balance and add this amount of money to the target account balance within the bank systems/devices. The “account balance” is the “business data” that must be changed to accomplish the “business transaction” called “money transfer”.

Distributed business transactions are the transactions that need to change different business data in different systems/devices at the same time; these systems/devices could be distributed within the same organization (e.g. the bank) or distributed across multiple organizations. The nature of this type of transactions is atomic that means, for data consistency in all contributing organizations, either to change all the data that must be changed in all systems/devices or not to change any data at all (All or None).

Technical Background For Distributed Transaction Processing (DTP), the standard is The Open Group XA (extended Architecture).

The standard reference material is “http://pubs.opengroup.org/onlinepubs/009680699/toc.pdf”.

In XA DTP systems, two-phase commit (2PC) protocol is used to coordinate transactions. Distributed transactions are widely used today to allow systems to interact with several data resources, and apply changes to resources while ensuring data consistency.

A two-phase commit protocol requires that all resources in distributed systems agree to commit a transaction before it gets committed (preparation phase). This ensures that either all resources commit the transaction or all resources abort the transaction (commit phase). When the transaction is committed, all the changes are made permanent. When a resource failed to commit, the whole transaction is rolled back, and all the changes already made should be undone to keep the data consistency.

To explain the difference in “distributed transaction processing” between the prior art method and the method of the present invention, a comparison between the two methods should be conducted as follows in the next part. Disclosure of the Invention

The IBTS Method: Figure 1 depicts a comparison between the traditional “XA DTP Method” (10) and the invented “Isolated Business Transaction Synchronization Method” (20). For simplification, in both methods there are one Parent (5) and two child transactions, “Child 1” (1), and “Child 2” (2). In the traditional method (10), child transactions get created in step (A 10) “Create Child Transactions”. Step (B10) “Create Parent Transaction & Add the Children to it”, as shown, the Parent (5) gets created and the children get added to it. Step (CIO) “Prepare Child Transactions”, and step (D10) “Commit Child Transactions” are within the boundaries of the “Execution Phase” (8). What the XA does is to try to prepare the child transactions then (if preparation succeeded) immediately commit them. As shown “Prepared Child 1” (3), “Prepared Child 2” (4), “Committed Child 1” (6), and “Committed Child 2” (7) are inside the “Execution Phase” (8). The philosophy of the XA DTP is to minimize the time between preparing the child transactions and committing them, to minimize the probability of any undesired change that could turn a prepared transaction invalid for commit.

In the invented method (20), child transactions get created in step (A20) “Create Child Transactions”. This method adopts a philosophy totally different from the previous method; the invention lets each transaction get prepared independent from the execution phase and in isolation from other transactions, step (B20) “Prepare Child Transactions (this is the main inventive step in this invented method). Each organization prepares its transaction in its own way according to its business rules, and the preparation could involve human activities (e.g. approvals, signatures, etc.). At the end, it must make its prepared transaction guaranteed for commit, no matter how long it takes to prepare it; shown in figure 1 as “Prepared Child 1” (3i) and “Prepared Child 2” (4i). This type of prepared transactions is being referred along the rest of current disclosure as GPT (Guaranteed Prepared Transaction). Step (C20) “Create Parent Transaction & Add the Children to it”, and step (D20) “Commit Child Transactions” can be done any time later. Step (C20) to create “Parent” (5) and add the child GPTs to it, then Step (D20) to perform the “Execution Phase” (8i) where the GPTs get committed together as shown, “Committed Child 1” (6), and “Committed Child 2” (7).

Problems and Implications:

To explain clearly the problem in the traditional method and how it has been solved using the invented method, a common business scenario (car selling) will be used. Assume a buyer and a seller want to conduct a business transaction where a transfer for the car ownership should happen from the seller to the buyer in the Publicity Department (PD), and another transfer for the money should be from the buyer to the seller in the bank at the same time with ownership transfer to secure the rights for both parties. Based on the comparison, if XA DTP is applied for the car selling scenario, the problem will be, for preparation phase, the XA DTP engine has to collect all data from buyer and seller, and perform all the transaction preparation checks instead of the bank and the PD, or to be fully integrated with both organizations to be able to send signals to them to do the needful checks. Also, human tasks must be automated, e.g. car license validation, buyer signature, ownership transfer fees collection, etc.

Practically speaking, the XA DTP engine cannot do all of this. That implies, there should be a project to tailor a system to collect all the data, and establish specific integrations needed to cater for this business scenario, then the said engine can be used at the end of the business scenario within the tailored system to commit the transaction using said integrations. All of this cost is to support only one business scenario that spans only two organizations. So, what is the expected cost to support any number of scenarios with unlimited number of organizations involved?

Using the invented method features of having the commit phase decoupled from the preparation phase, and transaction preparations are decoupled from each other, each organization can prepare its transaction independently. So, no need for tailored systems to collect all business data, perform all checks, and automate all human tasks. Also, no need for specific integrations, regardless of the number of business scenarios and their complexities. Only one generic integration interface, and only one generic system for GPTs execution are needed to solve the problem and support any business scenario across any number of organizations; this will be explained in “Methods of Implementing the Invention”.

XA DTP method fits within the same organization or across organizations that have full integration; this enables the engine to have control over the data sources involved in the transaction. Also, all checks and tasks should be fully automated to be able to use this method.

Description of Figures and Drawings

Figure 1 illustrates a flowchart comparison for a distributed business transaction, gets processed according to the two-phase commit protocol, versus according to certain embodiment of the invention. Figure 2 shows a flow diagram depicting a system that implements the invention method according to certain embodiment of the invention.

Figure 3 shows a state-machine describing different states and transitions for a prepared business transaction according to certain embodiment of the invention.

Figure 4 shows a flow diagram detailing a business case solution according to certain method of implementing the invention. Methods of Implementing the Invention The IBTS System:

Figure 2 depicts the system that implements the IBTS method. The system is comprised of three main elements and has one pre-requisite to work properly. All these elements do not exist currently, they need to be implemented according to the present invention embodiments.

As shown in the figure, the three main elements are:

1. IBTS Input Module (3)

2. IBTS Machine (5)

3. IBTS Receivers (8, 9) compliant to unified interface described in the next part of this section. And the pre-requisite is the “Transaction Handle” (1, 2) as examples, but the system can manage any number of handles. Handles could be arranged in list or tree structures; this will be described later in “method variations” part.

A Transaction Handle is a fully qualified reference for a GPT; in other words, it’s a global unique identifier that contains a full address for the GPT. This handle is used to add the GPT to its parent, and to manage it (e.g. commit, reverse, cancel, etc.).

How these elements work together to achieve the desired result of synchronizing isolated transactions, this can be explained as follows:

1. IBTS Input Module: after getting the “transaction handles”, the users go to said module. “Transaction handles” can be implemented in different formats, so the input module should be implemented accordingly. For example, if the “handles” are in text format, so the module can be a web page that has text fields. If “handles” are in QR code format, the module should have scanning capability to read it. If “handles” are put on smart cards, the module should have the right device to read such type of cards, and so forth. So, the implementation methods are unlimited but the point here is that the input module should be able to accept “transaction handles” from the users. The users could be human users or other systems that send “transaction handles” in signals to the input module. After accepting the “handles”, the input module sends all “transaction handles” to the IBTS machine in one combined signal (4). Any signal format and sending protocol here are viable as long as they are understandable by the IBTS machine. The signal could be sent over a direct wire, the internet (if the input module is a web page), wireless technologies, or any other medium suitable to carry the signal. 2. IBTS Machine: it receives the “transaction handles”, then starts to execute them as a single atomic distributed transaction. This happens by sending commit signals, like (6) and (7), to IBTS receivers. Based on the address included in the “transaction handle”, the IBTS machine sends it to the right receiver who can commit this transaction. Each signal contains a “transaction handle” along with the desired action for this transaction (e.g. commit). Any signal format and sending protocol here are viable as long as they are understandable by the IBTS receiver unified interface. The IBTS machine receives a confirmation signal from each IBTS receiver to know if the transaction is committed successfully or not. If all transactions are successful, so the whole distributed transaction is successful and committed. If anyone of transactions failed, the IBTS machine should send ‘reverse’ signals for all committed transactions, so the whole distributed transaction is considered failed. All these signals could be sent over the internet or any other medium suitable to carry this kind of signals. The IBTS machine could be implemented using hardware, software, or both.

IBTS Receiver Unified Interface:

Any organization/system that wants to provide a service for GPT handling (as an IBTS Receiver) should provide the core functionality for this purpose according to this unified interface. Figure 3 illustrates the GPT lifecycle states and transitions based on the transaction management list of interface functions:

1. Commit:

The GPT gets created in a “Prepared Transaction” (1) state. When its handling service receives a Commit (2) signal, it commits the GPT and transits it to “Consumed Transaction” (3) state. The latter state means the GPT cannot be committed again.

2. Reverse:

When a parent transaction starts to execute, it sends a Commit signal for the first child GPT. If it succeeds, it moves to the second child GPT. If the latter fails, the parent should send a Reverse (4) signal for the first committed GPT to go back to the “Prepared Transaction” state. For example, if the money transfer GPT succeeds to commit in the car selling scenario, then the ownership transfer failed due to car license expiry for instance, the IBTS machine must send a signal to the bank to reverse the money transfer by crediting the buyer account and debiting the seller account with the same amount of money transferred before.

3. Cancel:

If buyer and seller decided to cancel the deal, the GPTs should have the ability to be reverted back to the situation before preparation. For example, the IBTS machine sends Cancel (5) signal to the bank to ignore the money transfer GPT by removing the hold on the buyer’s money, then move the GPT to “Cancelled Transaction” (6) state. In this example, the IBTS machine should send also another Cancel signal for ownership transfer cancelation. 4. Validate:

The validate function does not change the GPT state. It gets the GPT data, and checks that GPT is still in the “Prepared Transaction” sate; this means it’s ready for commit. In other words, it validates that GPT didn’t get cancelled, committed, or expired. 5. Self-Expiry:

In some cases, a GPT gets expired after a certain amount of Time (7) and transited consequently to the “Expired Transaction” (8) state. For example, if the car license will expire in one week and the PD mandates that the ownership transfer should happen with an active license, so the PD can set the car ownership transfer GPT to expire after one week. So, if buyer and seller are going to use the IBTS system (to execute this GPT) after one week, the GPT will fail due to its expiry. This leads to the Reverse scenario described above if the money transfer GPT was successful before the ownership transfer fails.

The self-expiry functionality is optional, that means it’s not mandatory for any IBTS Receiver to support self-expiry; It depends on the business need, and the GPT nature. The rest of said functions constitute the mandatory interface for any IBTS Receiver.

Method of Industrially Applying the Invention The Transaction Handle (TH):

The TH is a fully qualified reference for the GPT; in other words, it’s a global unique identifier that contains a full address for the GPT. In this industrial application method, the standard URI (Unified Resource Identifier) is used to identify GPTs. URIs are currently widely used in the RESTful Web Services (RWS). REST (REpresentational State Transfer) is a common software architectural style that is based on the HTTP (Hyper Text Transfer Protocol) which is, the foundation of data communication for the World Wide Web (WWW).

It’s not mandatory for TH to be in a URI format. If a group of organizations, for example, agreed to have their own format for TH, no problem the present invention still can be applied. In future, if a new standard other than the URI emerged, the application method of the present invention will remain valid with same elements and steps.

An example for the URI of a TH (the TH of the money transfer GPT mentioned in the car selling scenario) looks like the format hereunder: http://www.bank.com/transaction-management/transactions/123xyz Where,

“htp”: is the communication protocol between sender and receiver (in this case, the IBTS machine and the bank, respectively).

“www.bank.com”: the bank electronic address on the world wide web. “transaction-management”: is an example for the name of the service exposed by this bank, “transactions”: is an example for the name of the data entity/table where the GPT record resides. “123xyz”: is an example for the unique key of the desired GPT within the “transactions” table.

To execute any function of the IBTS Receiver Unified Interface using the URI of a TH, just add “/function-name” to the URI as shown below, and use htp POST method to send it. http://www. bank.com/transaction-managemen ^transactions/ 123xyz/commit

This line above means; calling the commit function of the bank’s transaction-management service (as an IBTS Receiver) to handle the GPT whose key is “123xyz”.

To only inquire the transaction information, execute HTTP GET for the TH only.

Industrial Application Example: Figure 4 illustrates an industrial application example implementing the IBTS system; the same car selling example is used. IBTS system can be implemented in many ways using different technologies and variations. Some of the variations will be discussed in the next part of this section. The steps hereunder and the used technologies are just a simple example for IBTS system implementation.

1. Buyer (1) goes to the Bank (2) to prepare money transfer to seller. The Bank prepares the needed transaction according to its business rules, The Bank checks all the prerequisites; i.e. checks the Buyer account balance (if the Buyer has an account in this bank), checks that the account status is active, and any other mandatory checks. The Bank obtains the Buyer’s signature, collects the target account details (Seller account) from the Buyer to record it, and marks the required amount of money for transfer “on hold”. This means the Buyer cannot use this amount of money although it is still in his/her account. This way, the money transfer business transaction is fully prepared and guaranteed that needs only a “commit” trigger to be done.

2. After completing the transaction preparation, the Bank issues the money transfer “transaction handle” TH1, and gives it to the Buyer.

“TH1 = htp://www.bank.com/transaction-management/transactions/123xyz” (3), is an example as explained in “The Transaction Handle” part. 3. In Parallel, Seller (4) goes to the “Publicity Department” (5) to prepare car ownership transfer to buyer. The PD prepares the desired transaction according to its business rules, the Publicity Department performs the needful checks and preparations (e.g. the car license validity, the Seller ID validity), collects the ownership transfer fees, and records the needed information about the target owner (the Buyer) without changing the ownership in the PD records. This way, the car ownership transfer business transaction is fully prepared and guaranteed that needs only a “commit” trigger to be done.

4. After completing the transaction preparation, the PD issues the ownership transfer “transaction handle” TH2, and gives it to the Seller.

“TH2 = http://www.PD.gov/transaction-management/transactions/456abc” (6), is also an example as explained in “The Transaction Handle” part.

5. Both Buyer and Seller go together to the “IBTS Web Page” (7). Buyer and Seller put their transaction handles “ Ή1 and TH2” together in the IBTS Web Page, then choose to execute those transactions by pushing a button or so in the Web Page.

6. The Web Page uses the HTTP protocol to send a request including the THs to the IBTS Server (9) to execute the transactions using their handles. The IBTS Server, in this example, is a realization of the abstracted IBTS Machine mentioned in the IBTS System description. Example for the Web Page request is shown hereunder. This example posts to a servlet running on the IBTS Server.

“POST http://www.ibts.com/servlet

Parameters:

TH1

TH2” (8)

7. The servlet receives the posted handles and execute them together. Example for how the servlet could look like is hereunder:

Servlet (TH1, TH2) {

POST TH 1/commit POST TH2/commit } This program snippet sends TH 1 to the Bank in “POST TH 1 /commit” (10), calling the Commit function of the Bank’s transaction-management service, and also sends TH2 to the PD in “POST TH2/commit” (11) calling the Commit function of the PD’s transaction-management service, as explained in “The IBTS Receiver Unified Interface” part. By committing both transactions, the money gets transferred to Seller and the ownership gets transferred to Buyer within the same atomic transaction scope that commits all or none. Optionally, the servlet could validate each transaction (using its handle) before posting commit for this transaction, or validate all transactions at the beginning of execution then (if all valid) commit them all.

The servlet here is simplified for illustration; it represents a parent transaction that has just two child transactions to commit.

Method Variations:

The described IBTS method can be implemented with different variations that add value to its capabilities. For sure the list of variations hereunder does not include all possible variations; it represents a sample that shows the IBTS method flexibility, but any actual implementation should be driven by the business needs. Challenging examples will be demonstrated to show how it’s easy to overcome them by employing the present invention with variations.

1. Parametrized TH :

In the car selling example, the buyer might not have the seller account information at the time of preparing the money transfer. The bank could prepare the transaction, hold the required amount of money, and give the TH to the buyer. At the execution time, this TH should be provided to the IBTS System along with the needed parameters, e.g. the seller account IBAN. IBTS System’s post to the bank should look like: http://www.bank.com/transaction-management transactions/123 xyz/commit?IBAN=...

2. GPT with Pre-requisites: In the car selling example, may be the seller needs to postpone paying the ownership transfer fees for example for some reason but still wants to prepare the transaction and get the TH. PD will prepare the transaction. The payment cannot be passed as a parameter at runtime. PD will validate that the payment is in place before committing the transaction during the execution phase coordinated by the IBTS System. In this case, car ownership transfer is a GPT but not completely; it depends on a pre-requisite validation at runtime. . Parent Transaction Creation First:

Sometimes the parent distributed transaction is needed first then the child GPTs get added to it. For example, in some countries, before a visitor or a resident leaves the country, s/he should close all what s/he opened (e.g. bank account, mobile phone line, electricity bill account, etc.). In this case, the IBTS System should be used to create a parent transaction with the visa or residency number upon the visitor/resident request to leave the country.

To add child GPTs, s/he goes to the bank for example, but instead of closing the account before leaving the country and stay for some days without a bank account, the bank prepares a GPT for account closure and sends it to the IBTS System to join the parent transaction that is uniquely identified by the visa/residency number.

The visitor/resident should do the same in the telecom operator for the phone line, in the electricity company for the bill account, and so forth. At leaving time in the airport, the IBTS System should be used by “Foreign Affairs” staff to get the parent transaction by the visa/residency number, commit it, and consequently commit all child closure GPTs.

4. Execution Confirmation:

In a distributed transaction including business parties, sometimes a party or more needs to know about other parties’ transactions status after execution of all parties’ transactions. For example, if a customer booked a flight ticket using the airline website and got TH1 for this booking valid for some time to pay. Then s/he prepared the payment transaction TH2 and used the IBTS System to commit both THs. In such cases, the airlines company needs to know about the payment, therefore, IBTS System should send a confirmation notification to airlines after committing both transactions. This notification could be like: THl/confirm?id=TH2

5. User-Defined Tree-Structured Transaction:

For example, a tourist needs to plan a trip, wherein s/he will visit multiple countries, so s/he needs to book multiple hotels, flight tickets, rent cars, tours tickets, etc. in one transaction to make sure all booked elements are aligned according to the plan.

This can be done using the present invention. The tourist visits the websites of all trip elements to prepare GPTs and get their THs. S/he also prepares payment transactions for all these elements. Finally, the tourist uses the IBTS System, creates root transaction, and enrols all the THs s/he got in pairs. Each pair has a TH for one element booking and its equivalent payment TH. Each pair has a parent and all these parents are under the root parent, as shown below. o Root Transaction

■ Hotel 1 Booking

• Hotel 1 Booking TH

• Hotel 1 Payment TH ■ Hotel 2 Booking

• Hotel 2 Booking TH

• Hotel 2 Payment TH

^■ Flight 1 Booking

• Flight 1 Booking TH · Flight 1 Payment TH

^■ Flight 2 Booking

• Flight 2 Booking TH

• Flight 2 Payment TH

■ Etc. What the IBTS System will do, is to commit “Hotel 1 Booking” pair first, then the second pair and so forth according to the order defined by the user, but if any leaf transaction in any pair failed, all committed transactions will be reversed to guarantee that the whole trip either fully booked or none of it is booked.

The reason behind having pairs (i.e. not all THs are directly under the root) is; if hotels for example and airline companies are parties who want to be notified about the payment as described in previous variation “Execution Confirmation”, the IBTS System should differentiate between the payments (i.e. which payment belongs to which booking). Without pairing, IBTS System cannot correlate each payment to its party to notify it correctly.

As shown from different examples, IBTS System has many business cases to be applied in to avail features that were not existing before the present invention.

The preceding description of preferred embodiments of the invention has been presented for the purpose of illustration. The description provided is not intended to limit the invention to the particular forms disclosed or described. More modifications and variations will be readily apparent from the preceding description. As a result, it is intended that the scope of the invention not to be limited by the detailed description provided herein. Abbreviations

Claims

1. A method of "synchronizing isolated transactions", by combining said transactions into a "single distributed transaction", comprising the steps of: a. Creating child transactions, which are the leaves in case the distributed transaction structure is a tree structure; b. Preparing said child transactions in a way that makes these transactions guaranteed to commit. Readiness to commit can be guaranteed by checking all business rules that need to be validated before commit, and avoiding any change that might affect the readiness of prepared transactions to commit. This preparation phase in said method is distinguished by decoupling from execution phase, and also distinguished by that said transactions are totally decoupled from each other during preparation; each transaction can be prepared at different time and in complete isolation from other transactions; c. Creating the parent/root transaction, building the whole transaction structure including grouping nodes, and adding said prepared child/leaf transactions to the grouping node(s) to complete the transaction structure; d. Committing said transaction tree (execution phase). If all leaf transactions are successful, so the whole distributed transaction is successful and committed. If anyone of leaf transactions failed, all committed leaf transactions should be reversed, so the whole distributed transaction is considered failed.

2. The method of claim 1, wherein step ‘a’ could include creating the parent transaction at first, then creating child transactions. Adding a child transaction to the parent transaction should be after preparing the child transaction.

3. The method of claim 1 , wherein step ‘b’ includes and distinguished by issuing a globally unique “handle” for each prepared transaction. Said handle should include its issuer address and a unique ID for the prepared transaction. Said handle is used in step ‘c’ to add prepared transaction to the parent, and in step ‘d’ to commit or reverse said transaction.

4. The method of claim 1 , wherein step ‘b’ could perform the transaction preparation partially due to lack of some pre-requisite parameters and/or validations at preparation time. Said partial preparation should be complemented at transaction execution time by passing the missing parameters along with the ‘commit’ signal, and/or check the deferred validations as well.

5. The method of claim 1, wherein step ‘b’ can include defining a validity date/time for any prepared transaction according to the business needs. Once the prepared transaction validity date/time has been reached, said transaction should automatically expire.

6. The method of claim 1, wherein step ‘d’ optionally validates transactions before committing. This validation is to check that said transactions are in a ‘Prepared’ state. Said state means that said transactions are ready for committing.

7. The method of claim 1, wherein step ‘d’ might cancel prepared transactions upon business needs. Cancellation means the transaction is not ready to commit anymore.

8. The method of claim 1, wherein all steps typically performed on two or more transactions. Exceptionally, said method could be performed on a single transaction if there is a business need to decouple preparation phase from execution phase for said transaction.

9. A system adapted to carry out the steps of said method according to any one of claims 1 to 8, comprising the following elements: a. Transactions synchronization input module, to accept “transaction handles” from the users of said system; users could be humans or other systems. b. Transactions synchronization machine, to perform the transaction execution phase using the “transaction handles” accepted by said “input module”. c. Transactions synchronization receivers, to receive the transaction execution signals coming from said “machine”, and act accordingly by operating said receivers’ equivalent functions.

10. The system of claim 9, wherein element ‘a’ supports said users to build the complete transaction structure according to the method of claim 1 step ‘c’.

11. The system of claim 9, wherein element ‘b’ performs the transaction execution phase according to the method of claim 1 step ‘d’ and all step ‘d’ dependent claims.

12. The system of claim 9, wherein element ‘c’ should be compliant to a unified interface. ‘Commit’, ‘reverse’, ‘validate’, and ‘cancel’ functions constitute the mandatoiy interface for any “transaction synchronization receiver”. Said receivers could be the parties that originally create and prepare the transactions according to the method of claim 1 step ‘a’, and step ‘b’ and all step ‘b’ dependent claims.