JP2004157776A - Processing method for application and system - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a processing method for an application and a system which can equally manage commitment/rollback related to a database update and commitment/rollback related to a request for and the execution of asynchronous processing. <P>SOLUTION: Asynchronous processing startup service 2 and an asynchronous processing management table 6 are linked with a relational database and manage progress and faults. The processing method realizes a first function which is realized by the asynchronous processing startup service 2 in which introduced asynchronous processing is called out at least once; a second function which stops subsequent processing so that the introduced asynchronous processing will not be executed doubly; a third function which realizes unified management when a fault occurs, on the basis of information included in the asynchronous processing management table 6; a forth function which can trace back the fault to analyze if the asynchronous processing is called out in nesting; and a fifth function which can request for retry with respect to retrieved asynchronous processing in which an error has occurred. <P>COPYRIGHT: (C)2004,JPO

Description

[0001]
TECHNICAL FIELD OF THE INVENTION
The present invention relates to an application processing method and system that provide a configuration that guarantees the operation of an application that is executed asynchronously.
[0002]
[Prior art]
When developing a very simple system, if the user of the system always checks the normal end of the processing executed by the user, the system can be constructed only by the synchronous processing. In such a simple system, errors are avoided by the human system and the reliability of the system is guaranteed.
In order to avoid double execution of transactions to improve the reliability of such a system, even if the transaction completion notification is lost, check whether there is a record recovered by another host. Japanese Patent Application Laid-Open No. H11-163,086 proposes a technique for preventing the double execution of a transaction and obtaining an opportunity to start an interrupted transaction to improve the reliability of the system.
[0003]
[Patent Document 1]
JP-A-11-291717
[0004]
[Problems to be solved by the invention]
However, when the operator inputs a slip and the system checks the configuration, and then prints out the slip using a printer, it is more efficient to have the operator perform the input work continuously, and for that purpose the configuration check should be performed. When a system is designed to execute as many complex processes as possible per unit time, such as when printing on a printer or a printer needs to be performed asynchronously and in parallel with the input process of the operator, it is necessary to execute the processes in parallel. However, when asynchronous processing is adopted, processing performed asynchronously may cause an error without your knowledge. For this reason, a high level of assurance is required so that asynchronous processing can automatically cope with various errors that occur without your knowledge. However, Java (registered trademark, a language developed by Sun Microsystems) requires asynchronous processing. In order to perform the processing, MDB (Message-driven Bean) can be used, but there is a problem that the operation is not guaranteed as it is.
[0005]
Specifically, the conventional technology has the following problems.
The first problem is that even if it is desired to link asynchronous processing with database update, commit, rollback and asynchronous processing request for database update, commit and rollback for execution cannot be managed in the same manner. is there. The reason is that the asynchronous process start service (queue) is not linked with the database management system or has no asynchronous process management table. Also, even if these services are provided, the asynchronous process start service (queue) and the asynchronous process management table are not managed under the same database management system as general tables.
[0006]
The second problem is that after an asynchronous process is requested, the process cannot be automatically re-executed even if the part that is being executed asynchronously ends abnormally. The reason is that since the asynchronous process start service (queue) is not linked with the database, it is not possible to determine whether the asynchronous process in which the failure has occurred is re-executed as a system.
The third problem is that if the re-execution is requested, but the preceding process has been completed normally, the same asynchronous process will be executed twice.
The reason is that the progress of execution cannot be managed because the asynchronous process management table is not prepared.
[0007]
The fourth problem is that the following information mainly at the time of failure cannot be uniformly managed.
(1) When a failure occurs, it is not possible to uniformly manage which processing has caused an error and in what state, and it is difficult to search for an asynchronous processing that has caused an error.
(2) When asynchronous processing is called in a nested manner such as parent → child → grandchild, it is not possible to chase and analyze a failure.
(3) Even if an asynchronous process causing an error can be found, a retry cannot be easily requested for the asynchronous process. The reason for this is that the asynchronous processing management table as presented in the present invention is not prepared in the first place, or even if it is present, it does not manage enough information to request the retry. .
[0008]
Therefore, an object of the present invention is to provide a processing method and system of an application that can manage commit and rollback related to database update and commit and rollback related to request and execution of asynchronous processing in the same manner.
[0009]
Another object of the present invention is to provide an application processing method and system capable of executing an application asynchronously.
[0010]
Further, according to the present invention, when asynchronous processing is erroneously performed a plurality of times, it is possible to detect that the subsequent processing is a plurality of executions, and to cancel the processing when the execution becomes a double execution. It is an object of the present invention to provide an application processing method and system.
[0011]
Further, the present invention provides an application processing method and system that centrally manages execution information, failure information, and the relationship between parent and child of asynchronous processing, and can easily retry even if a failure occurs from such information. Aim.
[0012]
[Means for Solving the Problems]
An application processing method according to the present invention is an application processing method that guarantees the operation of an application that is executed asynchronously in an asynchronous processing server service in response to a processing request from a client service. An input phase for issuing an asynchronous processing request from the client service to the synchronous processing server service, a processing phase in which the asynchronous processing requested by the asynchronous processing start service is executed by the asynchronous processing server service, A confirmation phase for confirming the execution of the asynchronous processing including the progress and success or failure of the asynchronous processing via the synchronous processing server service, an acquisition phase for capturing information after confirming the end of the processing in the confirmation phase, Previous Asynchronous processing or by linking the necessary phases from among redo phase for abnormal termination after the re-execution, characterized in that it guarantees the operation of the application to be executed asynchronously.
[0013]
The application processing method according to the present invention relates to a required phase among an input phase, a processing phase, a confirmation phase, an acquisition phase, and a re-execution phase, and commits and rolls back a database update, and requests and executes an asynchronous process. The same management of commit and rollback prevents double execution of asynchronous processing, enables re-execution when a failure occurs, executes an application asynchronously, and operates the application executed asynchronously Guarantee.
[0014]
An application processing system according to the present invention includes a client service that receives synchronous and asynchronous services, a synchronous processing server service that performs server processing for the client service, an asynchronous processing server service that executes asynchronous processing, and the asynchronous processing server. Aspects of the asynchronous processing of the service are provided, which are linked with a relational database, manage progress and failures, and assure means for guaranteeing the operation of the application executed asynchronously.
[0015]
The application processing system of the present invention, in conjunction with a relational database, manages progress and failures for asynchronous processing execution of an asynchronous processing server service, commits and rolls back database updates, and commits and executes asynchronous processing requests and executions. Rollback is managed in the same way, double execution of asynchronous processing can be prevented, re-execution in the event of a failure is enabled, applications are executed asynchronously, and operations of the applications executed asynchronously are guaranteed.
[0016]
BEST MODE FOR CARRYING OUT THE INVENTION
Hereinafter, an embodiment of the present invention will be described.
FIG. 1 is a block diagram showing an application processing system according to this embodiment. FIG. 2 is a sequence diagram showing an asynchronous processing operation in the application processing system of this embodiment. A system to which the application processing method according to the present embodiment is applied is configured by each service shown in FIG. 1, and is executed according to the sequence shown in FIG.
The processing system of this application is characterized in that an asynchronous processing start service (queue) indicated by reference numeral 2 in FIG. 1 and FIG. 2 and an asynchronous processing management table indicated by reference numeral 6 are linked with a relational database to manage progress and failures. There is.
Then, the following two functions are provided to execute the asynchronous processing exactly once. The first function is that the input asynchronous processing is called at least once even if a failure occurs. This first function is mainly realized by an asynchronous processing start service (queue) indicated by reference numeral 2 in FIGS. In the second function, if the input asynchronous processing is executed a plurality of times, it is detected that the input asynchronous processing has already been executed, and the subsequent processing is stopped so as not to be executed twice. This second function is mainly realized by the asynchronous processing management table indicated by reference numeral 6 in FIGS. By combining the first function and the second function, it is possible to reliably execute the input asynchronous processing once even in a situation where recovery cannot be generally performed, such as a hardware failure.
Further, the information held in the asynchronous processing management table denoted by reference numeral 6 in FIGS. 1 and 2 realizes a third function that can unifyly manage which processing has failed in which state when a failure has occurred. In addition, even when asynchronous processing is called in a nested manner such as parent → child → grandchild, it is possible to realize a fourth function capable of chasing and analyzing a failure and to search for an asynchronous processing in which an error has occurred. is there. Further, a fifth function capable of requesting a retry for the retrieved asynchronous process that has become an error is realized.
In this way, it is possible to highly guarantee the operation of the application executed asynchronously.
[0017]
In this embodiment, the synchronous processing refers to a processing method in which the calling side waits for the return of the called side processing and continues the processing as shown in the left sequence of FIG. I do. The synchronous processing has a disadvantage that the response to the user is poor and thus hinders the work, but has a merit that the user can confirm the end result of the transaction or the like.
Asynchronous processing refers to processing in which the calling side and the called side operate simultaneously in parallel without the calling side waiting for the called side processing as shown in the right sequence of FIG. It refers to the method. In this asynchronous processing, a screen for confirming the printing status of the printer later or calling a screen for confirming a list of the work so far in subsequent processing is called out. ), Etc., there is a disadvantage that it is necessary to confirm the execution result of the part processed asynchronously later, but there is a merit that a large number of inputs can be performed per unit time because the processing returns quickly.
[0018]
First, each service shown in FIG. 1 that constitutes the application processing system according to this embodiment will be described.
The client service (eg, browser) 1 indicates a client that receives a synchronous or asynchronous service. Examples include browsers and client applications operated by end users. It is assumed that it is mainly used as an online system, but in some cases, batch-based processing may be used as a client service to use synchronous processing or asynchronous processing.
[0019]
Asynchronous processing start service (eg, Java JMS queue, Job management service, UNIX (registered trademark, OS for time-sharing system developed by AT & T), Clone, Windows (registered trademark, OS developed by Microsoft) At command) 2, synchronous processing is actually executed by a request from the user, but in the case of asynchronous processing, only the request is registered from the user, and another service is required to execute the request. Required. An asynchronous process activation service corresponds to this other service. The asynchronous process start service realizes this function. For example, Java JMS (Java Messaging Service), a commercially available Job management tool, UNIX cron, Windows at command, and the like can be the asynchronous process activation service.
[0020]
The synchronous processing server service (eg, Web application server) 3 is a service that handles server processing for a client service. The process between these is a synchronous process. When an asynchronous process is input from the client service, the synchronous process server service is first accessed, and the asynchronous process is requested via the synchronous process server service. For example, ORBs (Object Bank Requests such as Web Application Servers, TP Monitors (Transaction Monitors), Microsoft COM +, CORBA (Common Object Request Broker Architecture), and RMI (Remote Method Invocation).
[0021]
Asynchronous processing server service (eg, Java Message-driven Bean, batch processing such as shell and command) 4 refers to a service that actually executes asynchronous processing. For example, Java MDB (Message-driven Bean) or a service that performs batch processing such as shells and commands corresponds to this.
.
[0022]
The input information (IN) 5 is input information for asynchronous processing of a table (data) and a real file (text, CSV, binary file, etc.). Simple parameters can be managed in the asynchronous process management table. However, when using huge data stored in the database table or when handling text files, CSV (Comma Separated Values) files, and binary files, outside the asynchronous process management table Will be managed. However, in this embodiment, since all information is managed in the database, information held as various files is also stored and managed in the database.
[0023]
FIG. 12 shows an example in which the data of the input information 5 is managed in a database as an extension of the asynchronous processing management table.
The asynchronous process management table 6 is a table for managing information that forms the core of this embodiment. FIGS. 3, 4, 5, 6, 7, 8, 9, 10 and 11 show samples in the case where components are formed by MDB (Message-driven Bean). In this sample, detailed information is managed by a plurality of tables, and is specified in FIGS.
[0024]
The output information (OUT) 7 is divided into a pull type and a push type. A table (data) and a real file (text, CSV, binary file, etc.) are assumed as the pull type, and a printer, mail, log, It assumes failure notification and other system cooperation. The output information (OUT) 7 is output information from the asynchronous processing. Simple parameters, error codes, and error messages are managed in the asynchronous processing management table, but they are necessary when that is insufficient. As described above, it is largely divided into a pull type and a push type.
The pull type is intended for a case where information stored in a table, a file of text, CSV, binary, or the like, which is stored in a database, is taken by a user's action.
On the other hand, the push type is a case where the system automatically sends the information to the user, and includes output to a printer, transfer to an e-mail, log and failure notification, and cooperation with another system. FIG. 12 shows an example in which these data are managed in a database as an extension of the asynchronous processing management table.
[0025]
In the present embodiment, the business database 8 needs to cooperate with the business database and the information on the asynchronous processing. Therefore, the business database 8 is placed under the same database management system.
[0026]
Next, the asynchronous processing phase will be described.
FIG. 2 is a sequence diagram showing the processing content of each phase. As shown in FIG. 2, it can be classified into an input phase, a processing phase, a confirmation phase, an acquisition phase (pull type), and a re-execution phase (push type). The phases work together to assure a high degree of asynchronous application behavior.
The input phase refers to a phase in which the user issues a processing request for asynchronous processing. From the sequence shown in FIG. 2, it can be seen that this input phase operates only by the synchronous processing. Generally, the input to the asynchronous process is a very light process, and when the input is completed, the user can input another asynchronous process regardless of execution of the next processing phase.
[0027]
The processing phase is a part where the asynchronous processing server service 4 actually executes the contents of the asynchronous processing. Only this processing phase is executed from the asynchronous processing start service 4. It is mainly used in check-related work and print work that require a long processing time.
[0028]
The confirmation phase is a phase in which the user confirms the progress, success, or failure of the asynchronous processing. If the processing is being executed (if not completed), it is necessary to repeatedly execute this confirmation phase.
[0029]
In the acquisition phase (pull type), in the case of asynchronous processing having pull-type information, the user needs to capture the information in the acquisition phase after confirming the end of the processing in the confirmation phase.
[0030]
In the re-execution phase (push type), this re-execution phase is performed when asynchronous processing having push-type information or when it is desired to request re-execution due to abnormal termination even in the pull type.
[0031]
Next, the overall operation of this embodiment will be described in detail with reference to the sequence diagram shown in FIG.
First, the details of each phase are described in "Description of Asynchronous Processing Phases", and then, how the individual phases described earlier are linked in "Description of Cooperation of Asynchronous Processing Phases" .
"Description of each asynchronous processing phase"
Hereinafter, description will be given for each of the classified processing phases.
"Input phase"
In step S11 (input), "a request for asynchronous processing" is issued from the client service 1 to the synchronous processing server service 3 as general synchronous processing. In step S12 (parameter, file), the synchronous processing server service 3 registers input information for asynchronous processing such as parameters and files. In step S13 (register a request for asynchronous processing), the synchronous processing server service 3 registers the “request for asynchronous processing” in the asynchronous processing management table 6. In step S14 (notification of registration completion), the user (client service 1) receives a return indicating that the registration processing has been completed from the synchronous processing server service 3. It should be noted that at this point it is only known that only the registration of the asynchronous process has been completed normally. It is necessary to check whether the asynchronous processing itself has been completed normally in a “confirmation phase” described later.
[0032]
"Processing phase"
In step S21 (asynchronous processing request), the asynchronous processing is executed by the "asynchronous processing start service 2". In step S22 (search for a request), the asynchronous processing server service 4 checks the contents of the request with respect to the “asynchronous processing management table 6”. Also, in step S23 (see input contents), the asynchronous processing server service 4 checks the asynchronous processing management table 6 for input information necessary for executing the asynchronous processing. In step S24 (search processing and update processing), the processing is referred to and updated using the "business database 8". In step S25 (save output result), the result of the asynchronous process is saved as output information 7. In step S26 (updating the progress of the request), the progress is stored in the "asynchronous process management table 6" since the asynchronous process has been completed. In step S27 (return asynchronous process end), the asynchronous process ends, and the asynchronous process end is returned to the asynchronous process activation service 2.
[0033]
"Confirmation phase"
In step S31 (request for confirmation screen), the user requests confirmation of asynchronous processing. In step S32 (confirm the progress), the progress is confirmed in the "asynchronous process management table 6". In step S33 (progress and results are listed), the progress is returned. During execution, normal termination, error, etc. are returned.
[0034]
"Acquisition phase (pull type)"
In step S41 (select one from the list display screen), a request is made to obtain necessary information from the information obtained in the “confirmation phase”. In step S42 (obtain the result of the process), the result of the asynchronous process is obtained from “output information 7”. In step S43 (acquisition of data to be used as a result of the processing), if there is necessary information other than “output information 7”, it is acquired from “business database 8”. In step S44 (return of result), the result is returned to the user (client service 1).
[0035]
"Re-execution phase (push type)"
In step S51 (select one from the list display screen), information that needs to be re-executed is selected from the information acquired in the “confirmation phase”. In step S52 (change the status of the asynchronous process management table to re-execution), the status of the “asynchronous process management table 6” is changed to re-execution. In step S53 (notification of re-execution), the fact that re-execution was requested is returned to the user (client service 1).
Asynchronous processing is executed by coordinating the processing for each of the asynchronous processing phases as described below in “Description of Cooperation of Asynchronous Processing Phase”.
[0036]
"Explanation about cooperation of asynchronous processing phase"
Hereinafter, how each function described in the configuration of the above-described embodiment and each asynchronous processing phase described in the above “Description of each asynchronous processing phase” cooperate to form an entire asynchronous process is divided into patterns. explain.
[0037]
In the case of the pull type described in the output information (OUT) 7 of FIG. 2, the phases cooperate, for example, as follows.
For example, when processing that requires a long time is input asynchronously, “input phase” → “processing phase” → “confirmation phase” → “acquisition phase”.
[0038]
In the case of the push type described in “Output information (OUT) 7” in FIG. 2, the phases cooperate, for example, as follows.
For example, when a process that can be separately confirmed, such as printing or an e-mail addressed to the user, is requested, the “input phase” → the “processing phase”.
Or, when confirmation such as mailing to another person or coordination processing to another system is required, "input phase" → "processing phase" → "confirmation phase".
Or, for example, when the failure of asynchronous processing is confirmed and retry is performed, or when a paper jam occurs in printing or the like and reprinting is performed, “input phase” → “processing phase” → “confirmation phase” → "Rerun phase".
[0039]
Next, a case where the asynchronous process is called from the online process and a case where the asynchronous process is called from the batch process will be described.
The operation of the asynchronous processing described above can be called from either online processing or batch processing. FIG. 13 is an explanatory diagram showing a configuration example in a case where a call from online and a call from batch are actually assumed for the operation of asynchronous processing. In the example of FIG. 13, asynchronous processing is implemented by MDB (Message-driven Bean), but the following three types of calls are provided as examples.
[0040]
"(A) Call local asynchronous processing"
When the client service 1 and the synchronous processing server service 3 of FIG. 1 constitute online processing, and the synchronous processing server service 3 and the asynchronous processing server service 4 of FIG. 1 are implemented in the same environment. .
[0041]
"(B) Invoking remote asynchronous processing"
A case where the client service 1 and the synchronous processing server service 3 of FIG. 1 constitute online processing, and a case where the synchronous processing server service 3 and the asynchronous processing server service 4 of FIG. 1 are implemented in different environments.
[0042]
"(C) Call asynchronous processing from batch processing"
A case where the client service 1 and the synchronous processing server service 3 of FIG. 1 constitute online processing. In FIG. 13, when the asynchronous process is called from the batch process, only the remote call is described, but a local call is also possible depending on how the environment is created.
[0043]
As described above, according to this embodiment, the first effect is that the general table and the asynchronous process start service (queue) 2 and the asynchronous process management table 6 are installed under the common database management system. That is, a transaction of a business application using a component using the present invention and a transaction of asynchronous processing using the present invention can be commonly managed as commit and rollback timings as the same transaction.
[0044]
The second effect is that, by writing the asynchronous processing start service (queue) 2 to the database, even after a failure on the system including a hardware failure occurs, the asynchronous processing which is automatically in the unprocessed state after the recovery from the failure. Can be re-executed, and the number of re-executions can be specified as the number of retries in the asynchronous process management table 6, and the application can be executed asynchronously at least once.
[0045]
The third effect is that progress is managed in the asynchronous process management table 6, and by checking the status of the asynchronous process management table 6, whether the process is in a valid execution state or in an abnormal matter state is checked. Since the confirmation can be performed, if the asynchronous processing is executed a plurality of times by mistake, it can be detected that the subsequent processing is a plurality of executions, and if the asynchronous processing is executed twice, the processing can be canceled.
(* Even if the second effect and the third effect are combined and a situation such as a hardware failure seems to be generally unrecoverable, "at least once (second effect)" and "only once ( Third effect) "allows execution of asynchronous processing)
[0046]
A fourth effect is that information such as an execution user ID, a start time, an end time, a status, an error code, and an error message can be managed in the asynchronous process management table. As shown in FIG. Since the specified ID is held, the tree of the entire asynchronous process can be restored by tracing the ID, and all the information necessary for the retry can be extracted by using the asynchronous process management table 6 and its accompanying table. Since it is designed, the execution information, the failure information, and the relationship between the parent and child of the asynchronous processing are unitarily managed, and even if a failure occurs in the asynchronous processing as shown in FIG. 16, the retry can be easily performed.
[0047]
Next, another embodiment of the present invention will be described.
In the above description, the implementation in Java is assumed and the description is made using the image of Java, but the present invention is not limited to Java but can be used as a general service.
[0048]
The asynchronous process start service 2 and the asynchronous process server service 4 in FIG. 1 can be distributed to a plurality of servers to take a load distribution or a distribution configuration (failover) at the time of failure. For example, the asynchronous processing management tables (in the case of Message-driven Bean) shown in FIGS. 3 to 11 are created so as to correspond to the multiple server configuration.
[0049]
It is possible to build a system assuming a browser or a general application as the client service 1 of FIG.
[0050]
As the asynchronous processing start service 2 in FIG. 1, a Java JMS queue (Java Messaging Service Queue), a job management service released as a general product, a UNIX coulomb, an at command of Windows NT or Windows 2000 can be used. . However, it is necessary to construct these queues so as to link with the database. (If there is no other way, it is necessary to make it to look at the database at regular intervals)
[0051]
It is possible to employ a Web application server, a TP monitor (transaction monitor), or the like as the synchronous processing server service 3 in FIG. When a distributed object is used, an EJB container (Enterprise Java Beans container), a CORBA object, and MICROSOFT COM + can be used.
[0052]
As the asynchronous processing server service 4 in FIG. 1, a Java Message-driven Bean, a UNIX shell or command, a Windows batch file, or the like can be used.
[0053]
The input information (IN) 5 in FIG. 1 is directly managed in the asynchronous processing management table 6 in FIG. 1 like the business parameter in FIG. 5, and is also managed as a table (data) in the business database 8 or a real file (text, (CSV, binary file, etc.). If the asynchronous process management table 6 in FIG. 1 has a structure like the business parameters in FIG. 5, the table can be extended as shown in the extension of the asynchronous process management table in FIG. (The table is extended by setting the unique key of the table to be extended in the business parameter in FIG. 6.) When extending the table, a class corresponding to the original asynchronous processing management table 6 in FIG. 1 is created and operated. In this case, it is possible to design so that the extended class is assigned to the extended table by inheriting the class.
[0054]
The asynchronous processing management table 6 in FIG. 1 is generally defined as a table in the business database 8. However, this does not apply when an extended transaction such as a two-phase commit function can be considered. FIGS. 3 to 11 show examples of the asynchronous processing management table in the case where the Message-driven Bean is used. When the asynchronous process management table is extended, it is extended with the image of FIG.
[0055]
The output information (OUT) 7 in FIG. 1 includes a pull type in which information needs to be obtained from the client side and a push type in which information is sent from the server. In the following, each of them will be described separately.
[0056]
As the pull type, a table (data) and a real file (text, CSV, binary file, etc.) can be considered as described in the input information (IN) 5 of FIG. As the push type, printer, mail, log, failure notification, cooperation with other systems, and the like can be considered.
In addition, expansion of the table and the like can be performed in the same manner as described in the input information (IN) 5 in FIG.
[0057]
Although the business database 8 of FIG. 1 is generally managed by a relational database capable of transaction management, the database is not limited to a relational database, and a Kodasil type or an object-oriented database may be used. If the concept of a transaction can be added, it can be managed by a general file or the like. However, since the concept of a transaction is required in the present invention, a technology that cannot use the concept of a transaction cannot be adopted.
[0058]
【The invention's effect】
According to the present invention, a necessary phase is coordinated among an input phase, a processing phase, a confirmation phase, an acquisition phase, and a re-execution phase, and commit and rollback regarding database update, request for asynchronous processing, commit and roll regarding execution are performed. The same back is managed, preventing double execution of asynchronous processing, enabling re-execution in the event of a failure, enabling the application to be executed asynchronously, and has the effect of guaranteeing the operation of the application executed asynchronously. .
[0059]
According to the present invention, a client service that receives synchronous and asynchronous services, a synchronous processing server service that performs server processing for the client service, an asynchronous processing server service that executes asynchronous processing, and an asynchronous processing of the asynchronous processing server service As for execution, it is linked with the relational database, it manages progress and failures, and it has guarantee means to guarantee the operation of the application that is executed asynchronously. Commit and rollback for database updates and asynchronous processing requests, execution commits and rollbacks can be managed in the same way, preventing double execution of asynchronous processing and re-executing when a failure occurs Is possible Ri, execute an application asynchronously, there is an effect that can guarantee the operation of the application executed by the asynchronous.
[Brief description of the drawings]
FIG. 1 is a block diagram showing an application processing system according to an embodiment of the present invention.
FIG. 2 is a sequence diagram illustrating an asynchronous processing operation in the application processing system according to the embodiment of this invention;
FIG. 3 is an explanatory diagram illustrating an example of an asynchronous processing management table in the application processing system according to the embodiment of this invention;
FIG. 4 is an explanatory diagram illustrating an example of an asynchronous processing management table in the application processing system according to the embodiment of this invention;
FIG. 5 is an explanatory diagram illustrating an example of an asynchronous processing management table in the application processing system according to the embodiment of this invention;
FIG. 6 is an explanatory diagram illustrating an example of an asynchronous processing management table in the application processing system according to the embodiment of this invention;
FIG. 7 is an explanatory diagram illustrating an example of an asynchronous process management table in the application processing system according to the embodiment of this invention;
FIG. 8 is an explanatory diagram illustrating an example of an asynchronous processing management table in the application processing system according to the embodiment of this invention;
FIG. 9 is an explanatory diagram illustrating an example of an asynchronous processing management table in the application processing system according to the embodiment of this invention;
FIG. 10 is an explanatory diagram illustrating an example of an asynchronous processing management table in the application processing system according to the embodiment of this invention;
FIG. 11 is an explanatory diagram illustrating an example of an asynchronous processing management table in the application processing system according to the embodiment of this invention;
FIG. 12 is an explanatory diagram showing an example of a case where data of input information is managed in a database as an extension of an asynchronous processing management table in the application processing system according to the embodiment of this invention;
FIG. 13 is an explanatory diagram showing a configuration example of an asynchronous processing operation of the application processing system according to the embodiment of the present invention in a case where a call from online and a call from batch are assumed;
FIG. 14 is a sequence diagram illustrating a comparison between asynchronous processing and synchronous processing in the application processing system according to the embodiment of this invention;
FIG. 15 is an explanatory diagram showing an asynchronous process management table capable of managing information such as an execution user ID, a status, an error code, and an ID for identifying a previous asynchronous process in the application processing system according to the embodiment of this invention; is there.
FIG. 16 is an explanatory diagram showing that in an application processing system according to an embodiment of the present invention, retry can be easily performed even when a failure occurs in asynchronous processing based on a tree of the entire restored asynchronous processing. .
[Explanation of symbols]
1 ... Client service, 2 ... Asynchronous processing start service (guaranteing means), 3 ... Synchronous processing server service, 4 ... Asynchronous processing server service, 6 ... Asynchronous processing management table (guaranteing means), 8 ... Business Database (guarantee means).

Claims (6)

An application processing method for guaranteeing the operation of an application executed asynchronously in an asynchronous processing server service in response to a processing request from a client service,
Operate only by synchronous processing, the input phase for issuing an asynchronous processing request from the client service to the synchronous processing server service, the asynchronous processing requested by the asynchronous processing start service asynchronous processing is executed by the asynchronous processing server service A confirmation phase for confirming the execution of the asynchronous processing including the progress, success, and failure of the asynchronous processing via the synchronous processing server service by the client service. A method of processing an application that guarantees the operation of an application that is executed asynchronously by linking a necessary phase among an acquisition phase for capturing a program, a re-execution phase for re-execution after an abnormal termination, and an asynchronous process. The input phase includes an input step of requesting the synchronous processing server service to perform the asynchronous processing from the client service as a synchronous processing, and an input in which the synchronous processing server service registers input information to the asynchronous processing such as parameters and files. An information registration step, an asynchronous processing registration step in which the synchronous processing server service registers a request for the asynchronous processing in an asynchronous processing management table, and a return indicating that the registration processing has been completed is returned from the synchronous processing server service by the client service. Receiving the registration completion notification step, wherein the processing phase includes an asynchronous processing requesting step in which the asynchronous processing requested by the asynchronous processing starting service is executed by the asynchronous processing starting service; and Asynchronous processing A request search step for checking the request content for the management table, and an input content reference for checking input information required when the asynchronous processing server service executes the asynchronous process on the asynchronous process management table Step, a search / update step in which reference and update are performed using a business database, a save step of saving the result of the asynchronous process as output information, and a progress of saving the progress of the asynchronous process in the asynchronous process management table 2. The application processing method according to claim 1, further comprising: a status update step; and an asynchronous process end step of terminating the asynchronous process and returning an asynchronous process end to the asynchronous process start service. An application processing system that provides a configuration that guarantees the operation of an application executed asynchronously,
Client services that receive synchronous and asynchronous services,
A synchronous processing server service responsible for server processing for the client service;
An asynchronous processing server service that executes asynchronous processing,
Assurance means for performing asynchronous processing execution of the asynchronous processing server service in cooperation with a relational database, managing progress and failure, and guaranteeing operation of an application executed asynchronously;
An application processing system comprising: 4. The assurance means according to claim 3, wherein the assurance means is provided with an asynchronous processing start service and an asynchronous processing management table for executing a request from a user in the case of asynchronous processing in cooperation with a relational database. Application processing system. 5. The application processing system according to claim 4, wherein said assurance means includes a business database placed under the same database management system in cooperation with information related to asynchronous processing. The assurance means cancels a first function realized by an asynchronous process start service in which the input asynchronous process is called at least once and a subsequent process so that the input asynchronous process is not double-executed. A second function implemented based on the asynchronous process management table, a third function implemented based on information held in the asynchronous process management table, and a third function implemented unified management in the event of a failure. When the process is called in a nested manner, a fourth function capable of analyzing the failure by tracing the failure and a fifth function capable of requesting a retry for the asynchronous process that has been found as an error are realized. Item 6. The application processing system according to item 4 or 5.

Images