JP2002099510A - Plural transactions processing system - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a technique that can perform recovery processing depending on the content of a transaction and the content of a fault when a fault has occurred in a workflow processing system that executes a series of transactions complying with a workflow. SOLUTION: This system sets a fault dealing method for the content of a fault for every transaction. If a fault has occurred during execution of the workflow, this system executes a fault recovery processing complying with the fault dealing method set depending on the fault event. The fault dealing method includes a rerun of the transaction that becomes faulty due to a temporary fault, a temporary stop in a status where the last executed transaction is completed, if a series of transactions that proceed to a fault occurrence time due to a permanent fault can not be cancelled, and an execution of compensation processing of each transaction, if the cancellation is possible.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a multi-transaction processing system for executing a series of transaction processes in accordance with a workflow, and is effective when applied to a multi-transaction processing system for performing a recovery process when a failure occurs during the execution of a transaction. It relates to a failure recovery method.

[0002]

2. Description of the Related Art In a travel reservation system that requires reservation of a hotel and an airline ticket, or a system in which money is transferred between a plurality of bank accounts, a plurality of servers are accessed in response to a request from a channel and transactions are performed. Processing needs to be performed.

In order to execute a series of processes in one transaction, it is necessary to lock the corresponding data in each server until the transaction is completed. For this reason, other processes are kept waiting for a long time, which may cause performance problems. Therefore, it is common practice to divide a series of processes into transactions for each access to each server, and execute them as a workflow including a plurality of transactions.

In such a system, when a failure occurs during the execution of a workflow, it is necessary to perform a recovery process such as canceling a series of transaction processes performed up to the time when the failure occurred. For this reason, conventionally, the contents of the processing performed in each transaction are registered in a queue as a history, and when a failure occurs, history information is sequentially extracted one by one from the tail of the queue to perform compensation processing for each transaction. Such a system is described, for example, in "Introduction to Transaction Processing Systems" (by Philip A. Bernstein and Eric Newcomer, Nikkei BP, 111
Page).

If another transaction processes the same server before the transaction is canceled by the compensation processing, the transaction is affected by the result of the transaction to be canceled. Therefore, it is desirable that the time required for the recovery process be as short as possible.

For this reason, as described in JP-A-2000-163372, a recovery processing flow for performing failure recovery is registered at the time of executing a transaction, and when a failure occurs during the execution of the transaction, the registered recovery processing flow is registered. , A portion executed in parallel by the branching process during execution of the transaction is also executed in parallel by the compensation process, thereby improving the efficiency of the recovery process.

[0007]

In the above-mentioned conventional system, it may not be effective to simply execute the compensation processing depending on the contents of the transaction and the contents of the failure. For example, in a transaction for remittance from a plurality of bank systems, a transaction for withdrawing money from a remittance source account in a remittance source system A and a transaction for depositing money in a remittance destination account in a remittance destination system B are executed. Think. In the conventional method, when a transaction to be paid out becomes a failure, a recovery process can be performed by executing a transaction to “pay-in” the system A as a compensation process for a transaction to be withdrawn.

[0008] However, when another transaction for checking the account of the remittance source system A is executed, the result of the transaction differs before and after the execution of the compensation processing. In this case, it is considered better to stop the execution once when the transaction drawn from the system A is executed, remove the cause of the failure, and then restart the transaction to be paid into the system B.

If the cause of the failure is due to the congestion of the remittance destination system B, it is better to end the series of remittance processing normally by re-executing the transaction received from the system B after a while. it is conceivable that.

As described above, a more reliable transaction processing system can be constructed by executing different recovery processing depending on the contents of a transaction and the contents of a failure, rather than simply executing compensation processing when a failure occurs.

An object of the present invention is to solve the above-mentioned problems.
An object of the present invention is to provide a technology capable of performing a recovery process according to the content of a failed transaction and the content of the failure when a failure occurs during the execution of a workflow.

[0012]

In order to achieve the above object, a failure handling method for the content of a failure is set for each transaction. If a failure occurs during the execution of the workflow, failure recovery processing is performed according to the failure handling method set based on the failure content. Failure response methods include re-executing failed transactions for temporary failures,
If it is not effective to cancel a series of transaction processing performed up to the time of the failure, it is necessary to suspend the last executed transaction in a completed state. There is execution.

As described above, according to the transaction processing system of the present invention, it is possible to set a failure handling method for the content of a failure for each transaction in a workflow, so that even if a failure occurs during execution of the workflow, optimal failure recovery can be performed. And a more reliable transaction processing system can be constructed.

[0014]

FIG. 1 is a diagram showing a software configuration showing an example of a transaction processing system to which the present invention is applied.

FIG. 2 is a diagram showing a hardware configuration of the transaction processing system of the present embodiment. The system of the present embodiment includes a workflow control system 201,
The system includes a channel 209 and servers 210 to 212 connected to networks 214 to 217.

The workflow control system 201 interprets the request message from the channel 209 and
While requesting a transaction from 0 to 212,
This is a system that performs processing for satisfying a request from the channel 209. The channel 209 is a system that transmits a request message to the workflow control system 201 according to a request from a user. The servers 210 to 212
This is a system that executes a transaction according to a request from the workflow control system 201. here,
It is assumed that each of the servers 210 to 212 is providing a different service. In the present embodiment, a configuration in which one channel and three servers are connected is shown, but a configuration in which more channels and servers are connected may be adopted.

The workflow control system 201 includes a CP
U202, memory 203, hard disk drive 204,
Network interface controller 205-
208 and an input / output device 213. The hard disk device 204 stores a group of software for performing processing in accordance with the workflow. The software is loaded into the memory 203 and executed by the CPU 202. Network interface controllers 205 to 208 control interfaces to networks 214 to 217 and connect to channels 209 and servers 210 to 212.

Next, the software configuration of the workflow control system 201 of the present embodiment will be described with reference to FIG. The workflow control system 201 includes a transaction control program 101, a trader 107, adapters 103 to 106, a serial number management program 108
, A workflow execution program 102, and a workflow registration program 109.

Transaction control program 101
Provides a mechanism that allows transmission and reception of request and response messages between components. Each component in the workflow control system 201 uses the transaction control program 101 to communicate with other components.

The trader 107 provides a mechanism for searching for an object from the service content of each component. The adapters 103 to 106 and the workflow execution program 102 register the service contents provided by themselves in the trader 107. When transmitting a message, the trader 107 searches for a service and receives a destination object reference. The object reference is data including information for uniquely identifying a target object. Each object requests the transaction control program to send a message to the target object using the object reference.

The adapters 103 to 106 are connected to the channel 20
9 is a component that transfers messages between the workflow execution program 102 and the servers 210 to 212 and the workflow execution program 102. The adapters 103 to 106 communicate with the channels 209 and the servers 210 to 2 using different protocols.
12 and controls a protocol for connecting to the channel 209 and the servers 210 to 212 via the networks 215 to 218 and converts a message format.

The serial number management program 108 is a component for giving a unique number to a message transferred in the workflow control system 201. The serial number management program 108 sequentially manages numbers, and returns a unique number within the workflow control system 201 in response to a request from each component. Each component numbers the message with the serial number received from the serial number management program 108.

The workflow execution program 102 is a component that receives a request message from the channel 209, requests the servers 210 to 212 to process transactions according to the workflow, and processes the request from the channel 209.

The work flow execution program 102 is a business DB 11 for storing request contents and intermediate data of processing.
0, a workflow control program 111 for starting a transaction in accordance with the workflow, a workflow management DB 118 for storing the workflow, and the server 21
Transaction processing programs 112 to 114 for requesting processing to the process 0 to 212, a response processing program 115 started by the workflow control program 111 and transmitting a response message to the channel 209, and when a failure occurs during the execution of the workflow A recovery processing program 116 for performing recovery processing, a history information storage queue 117 for storing the execution history of each transaction,
And a failure correspondence table 120 indicating a recovery method when a failure occurs.

FIG. 3 shows the transaction processing programs 112 to 114 and the response processing program 11 of this embodiment.
FIG. 5 is a diagram showing a schematic configuration of No. 5; As shown in the transaction processing program 301 of FIG. 3, the transaction processing programs 112 to 114 and the response processing program 11
5 includes a normal processing unit 302 for requesting a transaction to the servers 210 to 212, and a compensation processing unit 303 for canceling a normally executed transaction.

The normal processing section 302 is a processing section for registering history information indicating the content of the executed transaction at the time of executing the transaction. The compensation processing unit 303 is a processing unit that retrieves the history information when a failure occurs during the execution of the transaction, and executes a compensation transaction for each transaction registered in the history information. As shown in FIG. 3, a transaction process and a compensation transaction process corresponding to each transaction are defined in advance.

Workflow management DB 118 and business DB
110 is stored in the hard disk device 204. The workflow management DB 118 stores a normal processing flow 119 describing a normal workflow. Business D
A business DB table as shown in FIG. 4 is stored in B110.

FIG. 4 is a diagram showing an example of the business DB table according to the present embodiment. The business DB 110 stores a business DB table 400 as shown in FIG. The business DB table 400 includes columns for storing a request serial number 401, a request content 402, a normal processing flow ID 403, and a queue ID 404. The queue ID 404 is an ID for identifying the history information storage queue 117.

Workflow registration processing program 109
Is a program for registering a workflow in the workflow management DB 118. The operator of the workflow control system 201 registers the normal processing flow 119 from the input device 213 in advance. The workflow registration processing program 109 includes a command for registering a workflow and G
The UI is provided, and the input workflow is registered in the normal processing flow 119 of the workflow management DB 118. When registering a workflow, the operator attaches a normal processing flow ID 403 for uniquely identifying the workflow. With this ID, the workflow control program 111 can manage a plurality of workflows registered in the normal processing flow 119. Further, the workflow control program 111 registers the registered workflow in the trader 107 as a service provided by itself. FIG. 5 shows an example of the normal processing flow 119 defined in this way.

FIG. 13 is a diagram showing an example of the routing information 121 managed by the trader 107. Trader 10
7 performs service registration and search based on this. The routing information 121 includes the service 1301 and the service ID 1
302 and an object reference 1303. In the present embodiment, the content of the service ID 1302 is a transmission destination ID for identifying a server to which the adapter is connected in the case of an adapter, and a normal processing flow ID for identifying a normal processing flow in the case of a workflow execution program. is there.

FIG. 5 shows a normal processing flow 119 of this embodiment.
It is a figure showing an example of. Nodes 501, 505, 506, and 51 describing a transaction in a workflow
In 2, a program for executing the corresponding transaction is defined.

In the present embodiment, a transaction processing program 301 is prepared for each transaction, and its normal processing section 302 is defined as an object to be activated on each node.

The operation in the case where a request message is received from the channel 209 and processing is performed according to the workflow shown in FIG. 5 will be described below. Adapter 103
Receives the request message from the channel 209, acquires the serial number for the request message by the serial number management program 108, and adds it to the message. Next, Trader 10
7, the object of the workflow control program 111 is transmitted from the request service based on the contents of the request message.
The reference is acquired, and a request message is transmitted to the workflow control program 111 using the object reference.

The workflow control program 111 receives the request message from the adapter 103 and registers a request serial number 401 and a request content 402 in the business DB table 400. Then, a normal processing flow ID 403 for identifying the normal processing flow 119 corresponding to the requested service is registered. Further, a queue ID 404 for identifying the history information storage queue 117 is generated and registered.

Further, the workflow control program 111
Stores the requested workflow in the workflow management DB 1
18 and proceed according to the contents described in the normal processing flow 119 as shown in FIG. The workflow control program 111 executes transactions in the order described in the workflow, makes a determination, and performs branching and queuing processing. A normal processing unit 302 to be started in the transaction is defined in a transaction node in the workflow, and the workflow control program 111 starts the defined normal processing unit 302 when executing the transaction.

According to the normal processing flow 119 shown in FIG. 5, the workflow control program 111 starts the execution of the workflow, and executes the transaction 1 to execute the transaction 1.
Is started (node 501).

FIG. 6 is a flowchart showing the processing procedure of the normal processing unit 302 of the transaction processing programs 112 to 114 according to this embodiment. The normal processing unit 302 performs processing according to the procedure of FIG. Here, the processing procedure of the normal processing unit 302 will be described with reference to FIG.

The workflow control program 111 passes the request serial number 401 to the normal processing unit 302 as an input. The normal processing unit 302 reads the contents of the row corresponding to the request serial number 401 of the business DB table 400, and creates a request message for a service required for the requested processing. Then, the object reference of the adapter connected to the server providing the required service is stored in the trader 107.
And a request message is transmitted (step 601).

Upon receiving the request message, the adapter 104 transmits the message to the server 210 via the network 216. After receiving the request message and performing the requested processing, the server 210
A response message including the processing number assigned to “0” and the data of the processing result is transmitted to the adapter 104. Adapter 104
Receives the response message from the server 210, and executes the normal processing unit 30 of the transaction 1 processing program 112.
Send to 2. When a failure is detected, such as when there is no response from the server 210 or when an error response due to the failure is received, an error response is sent to the normal processing unit 302 of the transaction 1 processing program 112 together with the details of the failure.

The normal processing section 302 receives a response message from the adapter 104 (step 602).

Next, the normal processing section 302 determines whether the processing for the request message has been completed normally (step 603). If the processing has been completed normally, the normal processing unit 302 registers history information on the transaction in the history information storage queue 117 (step 604).

Finally, the normal processing section 302 reports the normal end to the workflow control program 111 (step 605), and ends the processing.

As a result of the determination in step 603, the server 2
If the request for the job 10 has not been completed normally, the normal processing unit 302 reports the abnormal end to the workflow control program 111 and ends the process (step 60).
6).

Here, returning to the normal processing flow 119 of FIG. 5, the description will be continued. Transaction 1 (node 501)
Is completed as described above, the workflow control program 111 determines an end report from the transaction processing program 301, and performs a branching process if the processing is completed normally (node 503). If the transaction processing program 301 has terminated abnormally, recovery processing is executed. The recovery process will be described later.

The workflow control program 111 activates the transaction 2 processing program 113 in transaction 2 (node 505) and activates the transaction 3 processing program 114 in transaction 3 (node 506). Both transaction processing programs perform processing in the same procedure as in FIG. The transaction 2 processing program 113 requests the service provided by the server 211 via the adapter 105, and the transaction 3 processing program 114
Is requested via the adapter 106.

When each transaction ends normally, the history information relating to the transaction is stored in the history information storage queue 117 in the same manner as in transaction 1 (node 501).

When the processing of both transactions is completed in FIG. 5, the workflow control program 111 makes a judgment on each transaction. If the result of the determination is that the transaction has ended normally, a wait is performed (node 509). In the waiting process, when the workflow control program 111 detects that both of the two determination processes have been completed normally, it processes the next transaction (node 512). The case where the transaction 2 or the transaction 3 ends abnormally will be described later.

The transaction 4 (node 512) defines a response process to the channel 209. The response processing program 115 includes a normal processing unit 302 and a compensation processing unit 303, similarly to the transaction processing program 301 shown in FIG. However, the operations are different from those of the normal processing unit 302 and the compensation processing unit 303 in the transaction processing program. The workflow control program 111 activates the normal processing unit 302 in the response processing program 115.

FIG. 7 shows a response processing program 1 according to this embodiment.
15 is a flowchart illustrating the processing procedure of the normal processing unit 302 in FIG. The normal processing unit 302 in the response processing program 115 performs processing according to the procedure of FIG. Here, the processing of the normal processing unit 302 in the response processing program 115 will be described with reference to FIG.

The workflow control program 111 passes the request serial number 401 to the normal processing section 302 as an input. The normal processing unit 302 stores the business DB corresponding to the request serial number 401.
The contents of the data 110 are read, a response message to the channel 209 is generated based on the data, and a response serial number is given to the message by requesting the serial number management program 108 (step 701). Next, the normal processing unit 302 transmits the generated response message to the adapter 103 (Step 702). The adapter 103 transmits a response message to the channel 209 via the network 215.

Next, the normal processing section 302 determines whether or not these processes have been completed normally (step 70).
3). If the process is normally completed, the history information storage queue 1
The history information relating to the response process is stored in step 17 (step 704). Then, the normal end is reported to the workflow control program 111 (step 705), and the process ends. If it is determined in step 703 that an error has occurred, an abnormal end is reported to the workflow control program 111 (step 706), and the process ends.

When the processing of transaction 4 is completed in FIG. 5, the workflow control program 111 makes a determination (node 513). If the result of the determination is that transaction 4 has ended normally, the workflow control program 111 ends the processing. The processing when the transaction 4 ends abnormally will be described later.

FIG. 8 shows the history information storage queue 1 of this embodiment.
17 is a diagram illustrating a content example of No. 17. FIG. 8 shows the contents of the history information storage queue 117 when the execution of the normal processing flow 119 ends normally. History information storage queue 1
Reference numeral 17 denotes a First In Last Out type queue.

Transaction processing program 112-
The history information saved by 114 is history information 801, 802, and 803 in FIG. The history information stored by the response processing program 115 is the history information 80.
4. Since the transaction 2 and the transaction 3 are executed in parallel, the order of the history information 802 related to the transaction 2 and the history information 803 related to the transaction 3 differs depending on the timing at which the normal processing related to each transaction ends.

Transaction processing program 112-
Reference numeral 114 denotes a process ID for identifying each transaction request process in step 604 of FIG. 6, a transmission destination ID for identifying the server that transmitted the request message,
In the servers 210 to 212, history information including the processing number assigned to each transaction and data on the response content from each server is stored.

In step 704 of FIG. 7, the response processing program 115 attaches the processing ID for identifying the response processing, the transmission destination ID for identifying the channel 209 that transmitted the response message, and the response message. The history information including the response serial number and the data on the content of the response message is stored.

When a failure occurs, recovery processing is performed using the history information thus stored.

Next, the processing when a transaction ends abnormally will be described. When the transaction ends abnormally in the transaction processing nodes 501, 505, 506 and 512, the workflow control program 111 activates the recovery processing program 116.

At this time, the workflow control program 11
Reference numeral 1 denotes a queue ID 404 stored in the business DB table 400 and the transaction processing programs 112 to
114 and the normal processing unit 3 of the response processing program 115
02 and the recovery processing program 116
Pass as input to. The recovery processing program 116 extracts the history information in the history information storage queue 117 identified by the queue ID 404, and performs the processing according to the processing procedure illustrated in FIG. FIG. 9 is a diagram illustrating an example of the failure correspondence table 120 according to the present embodiment.
The failure handling table 120 has a transaction processing ID 901
, A failure content 902, and a recovery operation 903.

The fault content 902 may be classified according to the content of the detected fault. For example, when an error response due to resource shortage is received from the servers 210 to 212, it is classified as a re-executable failure, and when there is no response from the servers 210 to 212 such as a communication failure, the failure is classified as a non-re-executable failure.

The recovery operation 903 includes “re-execution” for re-executing a failed transaction process, “recovery” for executing a compensation process for the transaction process performed up to the time of occurrence of the failure, and execution of a workflow at the time of occurrence of the failure. There is a "stop" to stop.

FIG. 10 is a flowchart showing the processing procedure of the recovery processing program 116 according to this embodiment. Less than,
The processing of the recovery processing program 116 will be described with reference to FIG. The recovery processing program 116 calculates a failure handling table 120 based on the failed transaction and the content of the failure.
(Step 1001).

When the recovery operation is "re-execute" (step 1)
002), the re-execution of the failed transaction process is reported to the workflow control program 111 (step 1003), and the process ends.

The workflow control program 111 restarts the transaction processing programs 112 to 114 corresponding to the failed transaction and the normal processing section 302 of the response processing program 115.

At this time, it is also possible to restart at a fixed time interval or to re-execute a transaction to a different server providing the same service.

When the recovery operation is "stop" (step 10)
04), the workflow control program 111 is notified to stop the workflow when a failure occurs (step 1005), and the process ends.

The workflow control program 111 displays on the input / output device 213 a message indicating that the workflow has terminated abnormally.

At this time, by displaying the failed transaction processing ID, the request serial number, and the content of the failure, the operator removes the cause of the failure, and then the input / output device 213 sends the workflow control program to the workflow control program in response to the request serial number. By requesting the restart of the workflow, the failed workflow can be efficiently restarted.

When the recovery operation is “recovery”, the queue ID 4
It is determined whether there is history information in the history information storage queue 117 identified by 04 (step 1006). If the history information does not exist in the history information storage queue 117, the normal end of the recovery process is reported to the workflow control program 111 (step 1007), and the process ends. If the history information exists, the history information is extracted and the transaction processing program 1 identified by the process ID
12 to 114 and the compensation processing unit 303 of the response processing program 115 are started (step 1008).

Next, it is determined whether the compensation processing has been completed normally (step 1009). If the processing has been completed normally, the flow returns to step 1006 to continue the processing. In the case of abnormal termination, the workflow control program 11
1 and end the process (step 1010).

As described above, the compensation processing for the transaction processing performed up to the point of occurrence of the failure is executed.

The workflow control program 111 terminates the process when it determines that the process has been completed normally, and performs an abnormal termination process when it determines that it has completed abnormally. In the abnormal termination processing, the workflow control program 111 displays on the output device 214 a message indicating that the recovery processing has terminated abnormally.

The recovery processing program 116 described above
11 and 12 show the processing procedure of the compensation processing unit 302 started by the above processing. The processing procedure of the compensation processing unit 302 differs between the transaction processing programs 112 to 114 and the response processing program 115.

FIG. 11 is a flowchart showing a processing procedure of the compensation processing unit 302 of the transaction request processing programs 112 to 114 of this embodiment. First, the processing procedure of the compensation processing unit 302 in the transaction request processing programs 112 to 114 will be described with reference to FIG.

The recovery processing program 116 converts the history information extracted from the history information storage queue 117 into the compensation processing unit 30.
Pass to 2 as input. The compensation processing unit 302 generates a message for canceling the processing corresponding to the processing number based on the history information, and generates a message for the server 210 identified by the transmission destination ID.
Send a cancel request message to the adapters 104 to 106 connected to
1).

Next, from the adapters 104 to 106,
A response message relating to the cancellation processing performed by the servers 210 to 212 is received (step 1102). Then, it is determined whether or not the cancel processing has been completed normally (step 1103). If the processing has been completed normally, it is reported to the recovery processing program 116 and the processing ends (step 1104). If the cancel processing has not been completed normally, the abnormal end is reported to the recovery processing program 116 and the processing is terminated (step 1105).

FIG. 12 is a flowchart showing a processing procedure of the compensation processing unit 302 of the response processing program 115 of the present embodiment. Next, the processing of the compensation processing unit 302 in the response processing program 115 will be described with reference to FIG.

The recovery processing program 115 converts the history information extracted from the history information storage queue 117 into the compensation processing unit 30.
Pass to 2 as input. The compensation processing unit 302 generates a message for canceling the process corresponding to the process number based on the history information, and generates a message for the channel 20 identified by the transmission destination ID.
A cancel request message is transmitted to the adapter 103 connected to No. 9 (step 1201).

Next, it is determined whether the transmission processing of the cancel request message has been completed normally (step 12).
02). If the processing has been completed normally, it is reported to the recovery processing program 116 and the processing ends (step 1203). If the processing has not ended normally, the abnormal end is reported to the recovery processing program 116 and the processing is ended (step 120).
4).

As described above, in this embodiment, if any transaction ends abnormally due to a failure during the execution of a workflow, the recovery operation is determined from the failure correspondence table according to the transaction and the content of the failure, and the recovery operation is determined accordingly. Perform recovery processing.

Therefore, according to the workflow processing system of the present embodiment, it is possible to construct a highly reliable multiple transaction processing system capable of performing a transaction when a failure occurs and a recovery process according to the content of the failure.

[0082]

According to the present invention, when a failure occurs during execution of a workflow, a recovery operation is determined from a failure correspondence table based on the transaction and the content of the failure, and a recovery process is executed in accordance therewith. A highly reliable multiple transaction processing system capable of performing a recovery process according to the content of a failure can be constructed.

[Brief description of the drawings]

FIG. 1 is a diagram showing a software configuration of a workflow control system.

FIG. 2 is a diagram showing a hardware configuration of a workflow control system.

FIG. 3 shows a transaction request processing program 112 to
FIG.

FIG. 4 is a diagram showing an example of a business DB table.

FIG. 5 is a diagram showing an example of a normal processing flow 119.

FIG. 6 shows transaction processing programs 112 to 11.
4 is a diagram showing an example of a processing flow of a normal processing unit 302 of FIG.

FIG. 7 shows a normal processing unit 302 of the response processing program 115.
The figure which shows an example of the processing flow of FIG.

FIG. 8 is a diagram showing an example of the contents of a history information storage queue 117.

FIG. 9 is a diagram showing an example of a failure correspondence table 120.

FIG. 10 is a diagram showing an example of a processing flow of a recovery processing program 116.

FIG. 11 shows transaction processing programs 112-1.
The figure which shows an example of the processing flow of 14 compensation processing parts 303.

FIG. 12 shows a compensation processing unit 30 of the response processing program 115.
The figure which shows an example of the processing flow of No. 3.

FIG. 13 is a diagram showing an example of routing information 121.

[Explanation of symbols]

101: transaction control program, 102: workflow execution program, 103 to 106: adapter, 107: trader, 108: serial number management program
109: Workflow registration processing program, 110: Business DB, 111: Workflow control program, 112
~ 114 ... transaction processing program, 115 ...
Response processing program, 116: recovery processing program, 1
17: history information storage queue, 118: workflow management DB, 119: normal processing flow, 120: failure correspondence table,
121: routing information, 201: workflow control system, 209: channel, 210 to 212: server, 213: input / output device, 214 to 217: network, 400: business DB table.

Claims (5)

[Claims] 1. A transaction processing method for executing a series of transactions according to a workflow,
A multi-transaction processing system, wherein when a failure occurs during execution of a transaction, a failure recovery process is executed in accordance with the content of the transaction and the content of the failure. 2. The multiple transaction processing system according to claim 1, wherein a recovery process is performed in accordance with the content of the failure set in advance for each transaction and a failure recovery operation. 3. The multiple transaction processing system according to claim 1, wherein the contents of the failure are classified according to whether each transaction can be re-executed, and different recovery processing is executed. Characteristic multiple transaction processing system. 4. The multi-transaction processing system according to claim 1, wherein the recovery processing at the time of occurrence of the failure includes re-execution of the failed transaction and compensation processing for the already executed transaction. A multi-transaction processing system wherein recovery processing is executed by classifying the recovery processing into three types: execution and workflow suspension at the time of failure. 5. The multiple transaction processing system according to claim 1, wherein a serial number is assigned to a request message from a client, and the serial number and an identifier of history information are stored. A plurality of transaction processing systems for managing history information corresponding to request messages.