A method for implementing BPMN state machine based on saga

Abstract

The present invention discloses a method for implementing a BPMN state machine based on saga, which draws a bpnm state diagram through a custom visual service arrangement interface, defines the process of service calling, and sets the compensation action corresponding to each service, as well as the number of retries and retry intervals for compensation failures. Then, a transaction control server is operated through a restful interface or a java API, and the transaction control server starts a transaction, calls each service according to the process defined by bpnm, and executes a recovery strategy in the event of an exception. The recovery strategy is divided into two types: forward retry and backward compensation. Both strategies need to ensure the idempotence of the called service and the compensation action, and the backward compensation strategy has a smaller business invasion on each called service.

Description

Technical Field

[0001] The present invention relates to the field of distributed technology, and in particular to a method for realizing a BPMN state machine based on saga. Background Art

[0002] Currently, the service orchestration systems of telecom operators involving multiple business areas either lack a unified distributed transaction management mechanism or require major changes to the interface services of the business areas to support distributed transactions.

[0003] Under existing technologies, service orchestration often involves a large number of services provided by other companies or historical legacy systems. The orchestrated service business processes are long and involve many businesses. It is difficult to make large-scale modifications to all services, transaction management is difficult, and the service call process is difficult to track. Summary of the invention

[0004] The object of the present invention is to provide a method for realizing a BPMN state machine based on saga.

[0005] The technical solution adopted by the present invention is:

[0006] A method for implementing a BPMN state machine based on saga, comprising the following steps:

[0007] Step 1: In the service orchestration stage, transaction configuration is performed through a customized visual service orchestration interface to form transaction information;

[0008] Step 2: Send the configured transaction information in JSON format to the transaction control server. The transaction control server parses the JSON and converts it into transaction information in the form of an XML document that complies with the BPMN specification, and records the node information, compensation actions, and extended content in the database.

[0009] Step 3: The user controls the transaction control server to obtain the configured transaction information from the database to start the global transaction, and calls the bpmn state machine engine to build a state instance;

[0010] Step 4: The transaction control server generates a unique branch transaction primary key through RESTful or RPC, synchronously or asynchronously calls the services specified in the branch transaction in sequence, and records the transaction status and the branch transaction primary key of each service;

[0011] Step 5, determine whether the branch transaction is executed successfully; if yes, execute step 11; otherwise, execute step 6;

[0012] Step 6, determine whether the branch transaction retry limit is reached; if yes, execute step 7; otherwise, execute step 4;

[0013] Step 7, determine whether to start the backward compensation strategy; if yes, execute step 8; otherwise, execute step 10;

[0014] Step 8: The transaction control server sets the global transaction status to "compensating", finds the status that needs to be compensated, and executes the compensation logic of the corresponding branch transaction;

[0015] Step 9, further determining whether the compensation status of all branch transactions is completed; if so, executing step 11; otherwise, locating the next branch transaction to be compensated and executing step 8;

[0016] Step 10, determine whether to ignore the failure and continue execution; if yes, execute step 11; otherwise, execute step 12;

[0017] Step 11, update the global transaction status and record the log to determine whether the current global transaction status is a terminated state; if yes, execute step 12; otherwise, the transaction control server continues to transfer the bpmn state machine engine and executes step 3;

[0018] Step 12: The transaction control server ends the global transaction.

[0019] Furthermore, the interface style of the customized visual service orchestration interface refers to the DingTalk approval process interface.

[0020] Furthermore, the transaction information in step 1 includes an abnormal recovery strategy, the number of retries after a service failure, a compensation action corresponding to the service, and the number of retries and retry intervals for compensating for failure.

[0021] Furthermore, in step 3, the user uses the client to operate the transaction control server by calling a restful interface or a java API.

[0022] Furthermore, the transaction control server also provides a management interface to monitor and maintain the status of global and branch transactions.

[0023] Furthermore, under the backward compensation strategy, when the service specified in the branch transaction in step 4 is called, the service execution log is recorded in the local database and the branch transaction primary key is recorded; when the specified service call is successful, the status of the branch transaction is marked as executed; when the specified service call fails, the status of the branch transaction is marked as execution failure.

[0024] Furthermore, the specific steps in step 8 are as follows:

[0025] Step 8-1, determine whether a branch transaction exists; if yes, execute step 8-2; otherwise, execute step 8-6;

[0026] Step 8-2, determine whether the status of the branch transaction is executed; if yes, execute step 8-3; otherwise, execute step 8-6;

[0027] Step 8-3, execute the compensation logic of the corresponding branch transaction, and record the compensation log and the branch transaction primary key;

[0028] Step 8-4, determine whether the compensation is successful; if yes, update the compensation status of the corresponding branch transaction and execute step 9; otherwise, execute step 8-4;

[0029] Step 8-5, determine whether the compensation retry upper limit is reached; if yes, execute step 8-6; otherwise, execute step 8-3;

[0030] Step 8-6, ends the compensation, changes the backward compensation strategy to the forward retry strategy and executes step 7.

[0031] Furthermore, the global transaction status of step 11 includes "commit successful", "commit failed", "rollback successful" or "rollback failed".

[0032] The present invention adopts the above technical solution and adopts a centralized control orchestration method to execute the scheduling of branch transactions, which makes it easier to coordinate from the global transaction and coordinate the status in heterogeneous distributed components; it can understand the status of the entire distributed system from the controller level; by introducing a set of Java class libraries on the service provider side, it realizes support for branch transactions and reduces the difficulty of service transformation; the state machine instance log is fully recorded on the control side, which is convenient for restoring the transaction context through the log after the control side crashes or restarts.

[0033] The present invention is based on the theoretical foundation of saga and combines a visual process editing interface to draw the bpnm state machine. At the same time, it adopts an orchestration architecture to implement distributed transactions under microservices in a non-intrusive or low-intrusive manner, and provides a control center to monitor and maintain the status of distributed transactions, implement service call tracking, and manual / automatic transaction rollback operations. BRIEF DESCRIPTION OF THE DRAWINGS

[0034] The present invention is further described in detail below with reference to the accompanying drawings and specific embodiments;

[0035] Figure 1 A flow chart of a method for implementing a BPMN state machine based on saga according to the present invention;

[0036] Figure 2 It is a schematic diagram of the execution flow of the branch transaction of the present invention;

[0037] Figure 3 It is a schematic diagram of the compensation process of the branch transaction of the present invention. DETAILED DESCRIPTION

[0038] In order to make the purpose, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application.

[0039] like Figures 1 to 3 As shown in one, the present invention discloses a method for implementing a BPMN state machine based on saga, which comprises the following steps:

[0040] Step 1: In the service orchestration stage, transaction configuration is performed through a customized visual service orchestration interface to form transaction information;

[0041] Step 2: Send the configured transaction information in JSON format to the transaction control server. The transaction control server parses the JSON and converts it into transaction information in the form of an XML document that complies with the BPMN specification, and records the node information, compensation actions, and extended content in the database.

[0042] Step 3: The user controls the transaction control server to obtain the configured transaction information from the database to start the global transaction, and calls the bpmn state machine engine to build a state instance;

[0043] Step 4: The transaction control server generates a unique branch transaction primary key through RESTful or RPC, synchronously or asynchronously calls the services specified in the branch transaction in sequence, and records the transaction status and the branch transaction primary key of each service;

[0044] Step 5, determine whether the branch transaction is executed successfully; if yes, execute step 11; otherwise, execute step 6;

[0045] Step 6, determine whether the branch transaction retry limit is reached; if yes, execute step 7; otherwise, execute step 4;

[0046] Step 7, determine whether to start the backward compensation strategy; if yes, execute step 8; otherwise, execute step 10;

[0047] Step 8: The transaction control server sets the global transaction status to "compensating", finds the status that needs to be compensated, and executes the compensation logic of the corresponding branch transaction;

[0048] Step 9, further determining whether the compensation status of all branch transactions is completed; if so, executing step 11; otherwise, locating the next branch transaction to be compensated and executing step 8;

[0049] Step 10, determine whether to ignore the failure and continue execution; if yes, execute step 11; otherwise, execute step 12;

[0050] Step 11, update the global transaction status and record the log, and determine whether the current global transaction status is a terminated state; if yes, execute step 12; otherwise, the transaction control server continues to transfer the bpmn state machine engine and executes step 3;

[0051] Step 12: The transaction control server ends the global transaction.

[0052] Furthermore, the interface style of the customized visual service orchestration interface refers to the DingTalk approval process interface.

[0053] Furthermore, the transaction information in step 1 includes an abnormal recovery strategy, the number of retries after a service failure, a compensation action corresponding to the service, and the number of retries and retry intervals for compensating for failure.

[0054] Furthermore, in step 3, the user uses the client to operate the transaction control server by calling a restful interface or a java API.

[0055] Furthermore, the transaction control server also provides a management interface to monitor and maintain the status of global and branch transactions.

[0056] Furthermore, under the backward compensation strategy, when the service specified in the branch transaction in step 4 is called, the service execution log is recorded in the local database and the branch transaction primary key is recorded; when the specified service call is successful, the status of the branch transaction is marked as executed; when the specified service call fails, the status of the branch transaction is marked as execution failure.

[0057] Furthermore, the specific steps in step 8 are as follows:

[0058] Step 8-1, determine whether a branch transaction exists; if yes, execute step 8-2; otherwise, execute step 8-6;

[0059] Step 8-2, determine whether the status of the branch transaction is executed; if yes, execute step 8-3; otherwise, execute step 8-6;

[0060] Step 8-3, execute the compensation logic of the corresponding branch transaction, and record the compensation log and the branch transaction primary key;

[0061] Step 8-4, determine whether the compensation is successful; if yes, update the compensation status of the corresponding branch transaction and execute step 9; otherwise, execute step 8-4;

[0062] Step 8-5, determine whether the compensation retry upper limit is reached; if yes, execute step 8-6; otherwise, execute step 8-3;

[0063] Step 8-6, ends the compensation, changes the backward compensation strategy to the forward retry strategy and executes step 7.

[0064] Furthermore, the global transaction status of step 11 includes "commit successful", "commit failed", "rollback successful" or "rollback failed".

[0065] The specific working principle of the present invention is described in detail below:

[0066] The present invention draws the bpnm state diagram through a customized visual service orchestration interface, defines the process of service call, and sets the compensation action corresponding to each service, as well as the number of retries and retry intervals for compensation failures. Then, the transaction control server is operated through the restful interface or java API, and the transaction control server starts the transaction, calls each service according to the process defined by bpnm, and executes the recovery strategy in the event of an exception. The recovery strategy is divided into forward retry and backward compensation. Both strategies need to ensure the idempotence of the called service and the compensation action. At the same time, the backward compensation strategy has a smaller business intrusion on each called service. The overall steps are as follows:

[0067] 1. During the service orchestration stage, transactions are configured through a customized visual service orchestration interface. The interface style refers to the DingTalk approval process interface.

[0068] 2. Send the configured transaction information including exception recovery strategy, number of retries after service failure, compensation action corresponding to the service, number of retries and retry interval for compensation failure to the transaction control server in JSON format. The transaction control server parses the JSON and converts it into an XML document that complies with the BPMN specification, and records the node information, compensation action, and some extended content in the database.

[0069] 3. Deploy the transaction control server to start the scheduled transaction or commit or roll back the transaction. The transaction control server also provides a management interface to monitor and maintain the status of global and branch transactions.

[0070] 4. The client operates the transaction control server by calling the restful interface or java API: the transaction control server builds transaction initialization parameters, calls the bpmn state machine engine, and starts the global transaction.

[0071] 5. The transaction control server generates a unique branch transaction primary key through RESTful or RPC, synchronously or asynchronously calls the services specified in the branch transaction in sequence and records the transaction status and the branch transaction primary key of each service. Under the backward compensation strategy, when the service specified in the branch transaction is called, the service execution log is recorded in the local database and the branch transaction primary key is recorded. If the branch transaction primary key already exists, the execution of the service is skipped.

[0072] 6. When any branch transaction fails to execute, it will be retried according to the configured number of retries. Under the forward retry strategy, if the number of retries exceeds the number of retries, it will determine whether to continue to execute the subsequent processes according to the configuration, so that the global transaction can finally execute successfully. Under the backward compensation strategy, if the number of retries exceeds the number of retries, the compensation execution is triggered. The transaction control server sets the global transaction status to "compensating", finds each status that needs compensation, and executes the compensation logic of each branch transaction. When the branch transaction executes compensation, it searches for the branch transaction primary key in the local service execution log. If the branch transaction primary key is not found, it will directly return the compensation success and record the branch transaction primary key.

[0073] 7. When compensation of any branch transaction fails, it will be retried according to the configured compensation retry times. After the retry exceeds the compensation retry times, the context will be restored from the earliest branch transaction where compensation failed, and the forward retry strategy will be switched to complete the subsequent processes.

[0074] 8. The transaction control server updates the global transaction status to "commit successfully", "commit failed", "rollback successfully" or "rollback failed" according to whether the service execution is successful and whether the compensation execution is successful, and records the log.

[0075] 9. The transaction control server continues to transfer the bpmn state machine engine until the termination state.

[0076] The present invention adopts the above technical solution and adopts a centralized control orchestration method to execute the scheduling of branch transactions, which makes it easier to coordinate from the global transaction and coordinate the status in heterogeneous distributed components; it can understand the status of the entire distributed system from the controller level; by introducing a set of Java class libraries on the service provider side, it realizes support for branch transactions and reduces the difficulty of service transformation; the state machine instance log is fully recorded on the control side, which is convenient for restoring the transaction context through the log after the control side crashes or restarts.

[0077] The present invention is based on the theoretical foundation of saga and combines a visual process editing interface to draw the bpnm state machine. At the same time, it adopts an orchestration architecture to implement distributed transactions under microservices in a non-intrusive or low-intrusive manner, and provides a control center to monitor and maintain the status of distributed transactions, implement service call tracking, and manual / automatic transaction rollback operations.

[0078] Obviously, the described embodiments are part of the embodiments of the present application, rather than all of the embodiments. In the absence of conflict, the embodiments in the present application and the features in the embodiments can be combined with each other. The components of the embodiments of the present application generally described and shown in the drawings here can be arranged and designed in various different configurations. Therefore, the detailed description of the embodiments of the present application is not intended to limit the scope of the application claimed for protection, but merely represents the selected embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians of the art without making creative work are within the scope of protection of the present application.

Claims

1. A method for implementing a BPMN state machine based on saga, characterized in that: It includes the following steps: Step 1: In the service orchestration stage, transaction configuration is performed through a customized visual service orchestration interface to form transaction information; Step 2: Send the configured transaction information in JSON format to the transaction control server. The transaction control server parses the JSON and converts it into transaction information in the form of an XML document that complies with the BPMN specification, and records the node information, compensation actions, and extended content in the database. Step 3: The user controls the transaction control server to obtain the configured transaction information from the database to start the global transaction, and calls the bpmn state machine engine to build a state instance; Step 4: The transaction control server generates a unique branch transaction primary key through RESTful or RPC, synchronously or asynchronously calls the services specified in the branch transaction in sequence, and records the transaction status and the branch transaction primary key of each service; Among them, under the backward compensation strategy, when the service specified in the branch transaction in step 4 is called, the service execution log is recorded in the local database and the branch transaction primary key is recorded; when the specified service call is successful, the state of the branch transaction is marked as executed; when the specified service call fails, the state of the branch transaction is marked as execution failure; Step 5, determine whether the branch transaction is executed successfully; if yes, execute step 11; otherwise, execute step 6; Step 6, determine whether the branch transaction retry limit is reached; if yes, execute step 7; otherwise, execute step 4; Step 7, determine whether to start the backward compensation strategy; if yes, execute step 8; otherwise, obtain the result of the current branch transaction and execute step 10; Step 8: The transaction control server sets the global transaction status to "compensating", finds the branch transaction that needs to be compensated, and executes the compensation logic of the corresponding branch transaction. The specific steps in step 8 are as follows: Step 8-1, determine whether a branch transaction exists; if yes, execute step 8-2; otherwise, execute step 8-6; Step 8-2, determine whether the status of the branch transaction is executed; if yes, execute step 8-3; otherwise, execute step 8-6; Step 8-3, execute the compensation logic of the corresponding branch transaction, and record the compensation log and the branch transaction primary key; Step 8-4, determine whether the compensation is successful; if yes, update the compensation status of the corresponding branch transaction and execute step 9; otherwise, execute step 8-4; Step 8-5, determine whether the compensation retry upper limit is reached; if yes, execute step 8-6; otherwise, execute step 8-3; Step 8-6, end the compensation, change the backward compensation strategy to the forward retry strategy and execute step 7; Step 9, further determining whether the compensation status of all branch transactions is completed; if so, executing step 11; otherwise, locating the next branch transaction to be compensated and executing step 8; Step 10, determine whether to ignore the failure and continue execution; if yes, execute step 11; otherwise, execute step 12; Step 11, update the global transaction status and record the log, and determine whether the current global transaction status is a terminated state; if yes, execute step 12; otherwise, the transaction control server continues to transfer the bpmn state machine engine and executes step 3; Step 12: The transaction control server ends the global transaction.

2. A method for implementing a BPMN state machine based on saga according to claim 1, characterized in that: Step 1 The transaction information includes the abnormal recovery strategy, the number of retries after service failure, the compensation action corresponding to the service, and the number of retries and retry intervals for compensation failure.

3. The method for implementing a BPMN state machine based on saga according to claim 1, characterized in that: In step 3, the user uses the client to operate the transaction control server by calling the restful interface or java API.

4. The method for implementing a BPMN state machine based on saga according to claim 1, characterized in that: The transaction control server also provides a management interface to monitor and maintain the status of global and branch transactions.

5. The method for implementing a BPMN state machine based on saga according to claim 1, characterized in that: The global transaction status of step 11 includes "commit successful", "commit failed", "rollback successful" or "rollback failed".

Images