JP2009282581A - Business process performing device and business process performing method - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To avoid a failure in performing a business process concerning a loosely-coupled system. <P>SOLUTION: A business process performing device 200 includes: a service standby time calculating part 243 for calculating a service performance standby time by each service 280, 281 under suspension based on a service performance result by the business process stored in a business process performance history storage part 254; a service operation state analyzing part 242 for determining operation states by each service 280, 281 based on the latest service performance result stored in the business process performance history storage part 254, and obtaining the service performance standby time by each service; and a service performance control part 233 for obtaining the operation states and the service performance standby time of each service 280, 281 before performing the services 280, 281, performing the services when the services 280, 281 are under operation, and postponing the performance of the services during the service performance standby time when the services 280, 281 are under suspension. <P>COPYRIGHT: (C)2010,JPO&INPIT

Description

  The present invention relates to an apparatus and method for reducing the number of service execution failures in a business process that sequentially executes a plurality of services deployed in computers on a network.

In recent years, in a plurality of computers connected via a network, a distributed processing configuration in which an application deployed on the computer transmits and receives processing requests and responses via the network has been widely used.
In this distributed processing configuration, for example, there is a case where the call destination application is under maintenance and the processing request is not accepted, or the server on which the call destination application is deployed is being restarted. You need to consider the possibility that the application is temporarily suspended.

In order to avoid sending a processing request to an application whose call destination is stopped, a method of checking the operating state of the call destination application immediately before sending the processing request and waiting until the application recovers if it is stopped. Conceivable.
Operations such as application startup and server restart are considered to be almost the same every time from start to end, so if the application is stopped, the average time taken to recover for each reason for the stop If only waiting for the execution of the application, it can be expected to recover after a certain period of time and the execution of the application succeeds.

  By the way, until now, when a plurality of applications are linked, a tightly coupled linkage method in which the caller and the callee are aware of each other has often been adopted. In this tightly coupled system, the call source can detect the operation state of the call destination application by, for example, the call destination application notifying the call source application of the operation state. For this reason, when the application at the call destination is stopped due to a failure or the like, it is possible to take measures against the failure such as changing the call destination at the call source. Patent document 1 is an example of such a system.

By the way, a tightly coupled system has a drawback that maintenance work is extensive because the degree of association between the systems is deep, and maintainability is reduced and development cost is increased.
On the other hand, in recent years, an information system design technique called SOA (Service Oriented Architecture) has attracted attention. SOA is a concept of constructing a new information system by calling an application that performs business processing called a service in an order specified by an application that implements a business flow called a business process.

  In the service in the SOA, an interface for executing the service is described in an interface description language, and the service can be executed from any business process as long as the interface is followed. An example of the interface description language specification is WSDL (Web Service Description Language). An example of business process description language specifications is BPEL (Business Process Execution Language).

In the information system based on the SOA, the independence between the business process and the service is high. Therefore, the information system can be rapidly developed at low cost by reusing the existing service. In addition, there is an advantage that it is easy to change the implementation of services and change the calling order for constructing a new information system by combining a plurality of services, and to ensure the flexibility of the information system.
However, in a loosely coupled system in which the caller and callee are unaware of each other, as represented by SOA, the service that is the callee is not aware of the business process that is the caller, so The status cannot be notified.

In this loosely coupled system, a method using a UDDI (Universal Description, Discovery and Integration) as a storage means can be considered as a means for the business process to detect the service operating state. UDDI is a repository in which information such as service processing contents and interfaces for using services is registered. When a business process uses a service, it queries the UDDI about the service information and obtains various information. The UDDI makes an inquiry about the operating status to the service, holds the operating status information of the service, and can provide the operating status information of the service in response to the inquiry from the business process.
JP 2007-25785 A

By the way, in UDDI, since inquiries from multiple business processes and responses of service operating states are concentrated on UDDI, processing becomes heavy, and UDDI may become a bottleneck on the system. In addition, when the UDDI is stopped due to some failure, the business process using the UDDI cannot execute the process, so the range of influence of the failure is likely to be widened.
In addition, every time a service is executed from the business process, the business process inquires about the operating state of the service to UDDI, resulting in inconveniences such as an increase in network traffic, a poor response, and an overcapacity resulting in a system down. For this reason, it is not realistic to apply to a large-scale system in which the amount of access to UDDI is assumed to be excessive.

  When a stopped service is executed from a business process, an exception that the service execution failed occurs in the business process, and abnormal processing such as failure to execute the business process occurs. Actually, business processes receive processing requests from multiple clients at the same time and execute processing in parallel, so if one service stops, there will be an exception for the number of processing requests being processed for one business process. Will occur. Also, when a service is used from multiple business processes, an exception occurs in multiple business processes when the shared service stops. Furthermore, in the case of a multi-stage configuration in which business processes are executed from business processes, one service execution failure spreads to a plurality of business processes, and a large number of exceptions occur.

Hereinafter, an outline of a conventional system will be described with reference to a part of FIG. FIG. 1 is a diagram showing a data flow in the business process processing system according to the first embodiment of the present invention.
The basic flow of business process execution in the conventional business process execution apparatus 200 is as follows.
The client 270 transmits a business process 1 processing request 100 to the business process execution apparatus 200. The business process execution unit 230 of the business process execution apparatus 200 generates business process 1 instances 231 and 232 for each business process 1 processing request 100.

  These business process 1 instances 231 and 232 hold the execution state for each processing request such as the progress state of the business process and the value of a variable used inside the business process, and perform processing according to the execution state and the contents of the business process 1 definition 251. It is a processing unit, and is generated by the business process execution unit 230 for each received business process 1 processing request 100. The business process 1 instances 231 and 232 execute the service A 280 and the service B 281 in accordance with the business process 1 definition 251.

In the conventional method, if the service B281 is stopped due to some failure, both the business process 1 instances 231 and 232 fail to execute the service B281, and the instances end abnormally. When a business process instance ends abnormally, it is necessary to perform a recovery process by comparing the progress state of the instance and the execution state of the service.
In this way, when an exception occurs, the recovery process of the business process requires complicated manual operations by the system administrator, such as comparing the progress status of the service with the progress status of the business process. I have been invited.

This restoration work will be described with reference to FIGS. Note that FIG. 20 is a diagram illustrating a failure occurrence state when the conventional business process has multiple stages.
The system shown in FIG. 20 includes a client 1850 that transmits a processing request to a business process, a business process execution device 200 that executes the business process, and a plurality of services 1860 to 1863 that perform processing in response to the processing request from the business process. Has been. The business process execution apparatus 200 is provided with three business processes: an order business process 1851, an estimate acquisition business process 1852, and a purchase business process 1853.

  The ordering business process 1851 receives an ordering request from the client 1850 and executes an estimate acquisition business process 1852 and a purchase business process 1853 to perform ordering processing. The estimate acquisition business process 1852 executes service a 1860 and service b 1861 to perform estimate acquisition processing. The purchase business process 1853 executes a delivery date confirmation service 1862 and an order service 1863 to perform purchase processing.

  Here, when the order service 1863 is stopped due to some trouble, an exception occurs in the purchase business process 1853 that tried to execute the order service 1863. Further, even in the ordering business process 1851 using the purchasing business process 1853, execution of the purchasing business process 1853 fails and an exception occurs. In this way, when business processes are multi-staged, exceptions occur in a plurality of business processes due to execution failure of one service, resulting in a chain of exceptions.

FIG. 21 is a diagram showing a state of the conventional failure recovery operation shown in FIG.
As shown in FIG. 21, since the business process in which an exception has occurred is suspended in a state in which processing has been executed halfway, processing is resumed from the point of interruption, or processing that has been processed that may cause an error. It is necessary to erase all the results (execute compensation processing) and start the business process from the beginning. Here, as an example, a procedure in which the system administrator executes compensation processing will be described.

  The system administrator detects that a plurality of exceptions have occurred on the system using an operation tool or the like, and searches for a business process in which the exception has occurred. Next, analyze the execution history and check the progress of each business process in which an exception has occurred. As a result, if there is an already executed service or business process, compensation processing for the already executed process is executed. Compensation processing procedures differ for each service and business process, and the system administrator performs processing while referring to an operation manual provided.

As compensation processing, as shown in FIG. 21, for example, the processing data is deleted from the database used by the service a1860, or the client 1850 that sent the processing request to the ordering business process is notified of the processing failure. The work of sending an e-mail can be considered. Further, regarding the order service 1863 which is the cause of the exception occurrence, it is necessary to confirm the progress of processing in the order service 1863 and perform compensation processing.
Thus, when the business process is multistage, a great effort is spent on the recovery work. For this reason, it is considered that the number of exception occurrences in the entire system can be suppressed and the work amount of the system administrator can be reduced by preventing the execution of the service from failing.

  In view of the above circumstances, an object of the present invention is to provide a business process execution apparatus and a business process execution method capable of avoiding a business process execution failure in a loosely coupled system.

  In order to achieve the above object, a business process execution apparatus according to the first aspect of the present invention is a business process execution apparatus that executes a plurality of services on a network in the order described in a business process definition in response to a processing request from a client. A service standby time calculation unit for calculating a service execution standby time for each stopped service from a service execution result by a business process stored in the business process execution history storage unit, and a latest stored in the business process execution history storage unit A service operation state analysis unit that determines an operation state for each service from a service execution result of the service and obtains a service execution standby time for each stopped service; and an operation state and a service execution standby time of the service before the service is executed If the service is in operation, the service While performing the screws, the service is provided between the service execution waiting time when it is stopped, and a service execution control unit to delay the execution of the service.

  A business process execution method according to the second aspect of the present invention is a business process execution method for executing a plurality of services on a network in the order described in a business process definition in response to a processing request from a client. The service execution standby time is calculated for each stopped service from the service execution result of the business process stored in the business process execution history storage unit, and the service execution standby time is calculated for each service from the latest service execution result stored in the business process execution history storage unit. The service execution standby time is acquired for each service that is stopped, and the service operation state and the service execution standby time are acquired before executing the service. Runs the service while the service is down The case between the service execution standby time, has postponed the execution of the service.

  According to the present invention, it is possible to realize a business process execution apparatus and a business process execution method capable of avoiding a business process execution failure in a loosely coupled system.

Embodiments of the present invention will be described below with reference to the accompanying drawings.
First, a first embodiment will be described with reference to FIGS.
<< First Embodiment >>
<Outline of configuration of business process processing system S>
FIG. 1 is a diagram illustrating a data flow in the business process processing system S according to the first embodiment.
The business process processing system S of the first embodiment includes a client 270 that transmits a processing request to the business process execution device 200, a business process execution device 200 that performs processing in response to a processing request from the client 270, and a business process execution device 200. Software A set of services A280 and B281 that perform processing in response to a processing request from.

A service is a processing unit that is arranged on a service execution device, receives a processing request via a network, and responds to an execution result.
Hereinafter, the expression “execute a service” means that the service processing request transmission source sends an execution request to the service, the service executes the requested processing, and the processing result is received by the service processing request transmission source. This means a series of processes. The service A280 and the service B281 are executed by the business process execution unit 230 of the business process execution device 200.

The business process execution unit 230 is a processing unit that executes processing described in the business process definition.
The business process definition is a description of processing performed by the business process execution unit 230 such as execution of a plurality of services and generation of processing data to be transmitted to the service as a flow using a business process description language. A general example of a business process description language is BPEL (Business Process Execution Language).
The business process 1 definition 251 shown in FIG. 1 describes a process for executing the service A 280 and the service B 281. The definition contents of the business process 1 definition 251 and the processing executed by the business process execution unit 230 will be described later.

<Outline of business process processing system S>
The business process processing system S according to the first embodiment determines a service operating state based on information held by the business process side in a loosely coupled system, and controls the execution timing of the service according to the service operating state. The purpose is to avoid execution failure.
As shown in FIG. 1, when a business process request is sent from the client 270 to the business process execution apparatus 200, the business process processing system S immediately before executing a service by the service execution control unit 233 and the service state management unit 240. Check the operating status of the service, decide whether to execute the service according to the operating status of the service or postpone the execution for a certain period of time, and if postponing, the business process according to the service to be executed and the fault type The service execution standby time calculated from the information stored in the execution history 254 is set.

And, by executing the service after the service execution waiting time that is likely to be recovered by avoiding the execution of the stopped service, the business process execution device 200 as a whole reduces the number of business process execution failures. ing.
Here, the business process execution history 254 held by the business process execution device 200 is used as a means for the service state management unit 240 to detect the service operating state. Therefore, unlike the conventional case, it is not necessary to have a close coupling in which the business process execution device 200 and each service recognize the mutual location, and the service side notifies the business process execution device 200 of its own operating state.

Therefore, with this configuration, in a loosely coupled system in which the service side such as the services A280 and B281 is unaware of the location of the business process execution device 200, the operating state of the service can be detected from the business process execution device 200 side.
This will be specifically described below with reference to FIG.

<Specific example>
As shown in FIG. 1, when the service B281 is stopped due to some failure, the business process 1 instance 231 that executes the service B281 immediately after the service B281 stops fails to execute the service B281. When information indicating that the execution has failed is recorded in the business process execution history 254 of the business process execution device 200, the service state management unit 240 analyzes the business process execution history 254 and operates the recorded service B281. Update state. The business process 1 instance 232 that executes the service B281 after the business process 1 instance 231 acquires the operating state of the service B281 from the service state management unit 240, and postpones the service execution for a certain time because the service B281 is stopped.

As a result of the above processing, service execution has failed in both business process 1 instances 231 and 232, whereas in the case of this business process processing system S, the preceding business process 1 instance 231 has failed in service execution. By using this information, the execution of the service in which the subsequent business process 1 instance 232 is stopped is avoided.
Further, the service state management unit 240 analyzes the service B281 execution failure data recorded in the business process execution history 254 to obtain the service execution standby time of the service B281, and the service execution standby time of the business process 1 instance 231, 232 Set as. Thereby, it is possible to dynamically set an appropriate standby time for each service and each failure type based on the past performance.

<Hardware configuration of business process processing system S>
FIG. 2 is a diagram illustrating an example of a hardware configuration of the business process processing system S according to the first embodiment.
The business process processing system S includes a client execution device 201 that issues a processing request for services such as services A280 and B281, a business process execution device 200 that executes the requested processing, and a service execution device 202 that actually executes the service A280. And a service execution device 203 that actually executes the service B281.

Here, all the processing units arranged on the client execution device 201, the business process execution device 200, and the service execution devices 202 and 203 may be realized as dedicated hardware, or a CPU (Central Processing Unit) However, in the following, a case where the program is realized will be described.
The client execution device 201, business process execution device 200, and service execution devices 202 and 203 are connected to each other via a network 204. The network 204 may be a local network such as a LAN (Local Area Network) or an intranet, or a global network such as the Internet, and is not limited. Needless to say, any number of client execution devices 201 and service execution devices 202 and 203 may exist.

<Client execution device 201>
As shown in FIG. 2, the client execution device 201 includes a CPU 210, a main storage device 211, a network interface 213, and a system bus 214 for connecting them.
The main storage device 211 is provided with a client 270 that executes the program by the CPU 210 as necessary. The network interface 213 communicates with other devices on the network 204 via the network 204 in accordance with instructions from the CPU 210.
However, the configuration illustrated in FIG. 2 is an example, and a plurality of clients 270 may be provided in the client execution device 201.

<Service execution devices 202 and 203>
The service execution devices 202 and 203 include a CPU 210, a main storage device 211, a network interface 213, and a system bus 214 that connects them.
A service A280 is provided in the main storage device 211 of the service execution device 202, a service B281 is provided in the main storage device 211 of the service execution device 203, and the corresponding programs are executed and deployed by the CPU 210 as necessary. . The network interface 213 communicates with other devices on the network 204 via the network 204 in accordance with instructions from the CPU 210.
However, the configuration in FIG. 2 is an example, and services other than the service A 280 and the service B 281 may be provided in the service execution apparatuses 202 and 203.

<Business process execution device 200>
The business process execution device 200 shown in FIG. 2 includes a CPU 210, a main storage device 211, a secondary storage device 212, a network interface 213, and a system bus 214 that connects them.
A business process execution program 220 is executed and deployed in the main storage device 211 by the CPU 210.
As described above, each processing unit of the business process execution program 220 arranged on the main storage device 211 shown in FIG. 2 stores a corresponding target program in the secondary storage device 212, and is executed by the CPU 210 as necessary. The main memory 211 is read, executed, and deployed.

The secondary storage device 212 includes business process 1 definition 251, service A interface definition 252 (hereinafter referred to as service AIF definition 252), service B interface definition 253 (hereinafter referred to as service BIF definition 253), business process execution history. An operation state management table 261, a standby time management table 262, and the like are arranged.
The secondary storage device 212 is realized by a storage device such as a memory or a hard disk built in the business process execution device 200, an external memory or hard disk device, a database connected via a network, a database server, or the like. May be.
The network interface 213 communicates with other devices on the network 204 via the network 204 in accordance with instructions from the CPU 210.

<Business process execution program 220>
As shown in FIG. 2, the business process execution program 220 includes a business process execution unit 230 and a service state management unit 240.
As shown in FIG. 1, the business process execution unit 230 executes the process described in the business process 1 definition 251 in response to the business process 1 process request 100 from the client 270, and displays the process status and process result as a business process. A processing unit that records the execution history 254.

  As shown in FIG. 2, the business process execution unit 230 includes business process 1 instances 231 and 232 and a service execution control unit 233. However, the configuration shown in FIG. 2 is an example, and a plurality of business process definitions other than the business process 1 definition 251 may be deployed in the business process execution unit 230, and a business process instance that executes each definition is arbitrary. There may be more than one.

<Processing contents of business process 1 definition 251>
An example of the processing contents of the business process 1 definition 251 used in the first embodiment is shown in the business process 1 definition 251 shown in FIG. The business process 1 definition 251 describes a procedure of processing executed by the business process execution unit 230 as a flow using a business process definition language.
The business process definition is composed of a plurality of steps, and each step is a step ID that is a unique identifier in the business process definition, a step type that represents the type of processing performed in the step, and a step that represents details of the processing content. Contains detailed information.

  The business process 1 definition 251 is a step ID1 that receives the business process 1 processing request 100 shown in FIG. 1 and extracts data and has a step type that is the start step, step 300, and a step ID2 that executes the service A280, and the step type Step 301 is a service execution step, Step ID3 is for executing service B281 and the step type is Step 302 for service execution step, and Step ID4 is a post-processing step ID4 and Step 303 is the end step. It is configured. However, the above content is an example of a business process definition, and it is a matter of course that any processing flow may be defined as long as it can be described in the business process definition language.

The business process 1 processing request 100 shown in FIG. 1 is data transmitted when the client 270 requests the business process execution unit 230 of the business process execution device 200 to execute the business process 1 definition 251 of the business process execution device 200. .
The business process 1 processing request 100 (see FIG. 1) includes an update time threshold value 101 used in the service execution control unit 233, in addition to the business process definition name to be executed and the input data required to execute the business process 1 definition 251. And a maximum waiting time 102. As shown in FIG. 1, the business process 1 instances 231 and 232 pass the update time threshold value 101 and the maximum standby time 102 to the service execution control unit 233 in addition to information necessary for service execution, and request the service execution. A method of using the update time threshold 101 and the maximum standby time 102 in the service execution control unit 233 will be described later.

<Business process execution history 254>
FIG. 3 is a diagram showing an example of the configuration of the business process execution history 254. As shown in FIG.
The business process execution history 254 shown in FIG. 3 is a storage unit such as a database or a file, a business process name 400 that is an identifier of a business process definition, an instance ID 401 that is an identifier of a business process instance that has performed processing, and a processing target step Step ID 402, step type 403 that is the step type of the step of step ID 402, step start time 404 that is the process start time of step ID 402 by the business process instance, and step end time 405 that is the process end time, It consists of a step state 406 that is a step processing state, an execution result 407 that is a processing result, and a failure type 408 that is the type of failure that occurred when a failure occurred during step processing.
However, the configuration illustrated in FIG. 3 is an example, and information other than the information illustrated in FIG. 3 may be included.

<Service execution control unit 233>
The service execution control unit 233 shown in FIGS. 1 and 2 is a processing unit that executes a service at an appropriate timing according to the service operating state, and performs the service execution by the business process 1 instances 231 and 232. Details of the processing in the control unit 233 will be described later.

<Service AIF definition 252 and Service BIF definition 253>
The service AIF definition 252 and the service BIF definition 253 shown in FIGS. 1 and 2 describe information necessary for executing the service A280 and the service B281, respectively. The information necessary for executing the service is information such as a destination URL of the service processing request, a data structure of data to be included in the service processing request, and a data structure of result data included in a response from the service. .
As shown in FIG. 1, when executing the service A280, the service execution control unit 233 refers to the service AIF definition 252 and generates a service A processing request 110 including the processing data 111 and transmits it to the service A280. Similarly, when the service B281 is executed, a service B processing request 120 including the processing data 121 is generated with reference to the service BIF definition 253 and transmitted to the service B281.

The data included in the response from the service differs depending on whether the service has been successfully executed or failed.
When the service A is successfully executed, the service A process response 112 includes a process result 113 indicating that the process has been successful and result data 114 that is the process result data. On the other hand, when execution of service B fails, the service B processing response 122 includes a processing result 123 indicating that the processing has failed, and a failure type 124 indicating a failure type such as service B stop or service B execution device stop. Is included.
The business process 1 definition 251, service AIF definition 252, and service BIF definition 253 are created by a business process developer using a tool for a business process development environment and deployed to the business process execution apparatus 200. Since the development tool and the deployment method can be realized by the conventional technology, detailed description thereof is omitted.

<Service status management unit 240>
The service state management unit 240 shown in FIG. 1 and FIG. 2 is a processing unit that holds information necessary for service execution control, such as service operation status, and provides information in response to an inquiry from the service execution control unit 233. And a service state determination unit 241 for performing service state management processing.
As shown in FIG. 1, the service state determination unit 241 includes a service operation state analysis unit 242 that records the latest operation state of a service, and a service standby time calculation unit 243 that calculates and records a standby time until the service is executed. It is configured.
The service operation state analysis unit 242 is a processing unit that analyzes the business process execution history 254 and records the latest operation state of the service in the operation state management table 261.

FIG. 4 is a diagram showing the configuration of the operating state management table 261.
The operation state management table 261 shown in FIG. 4 is a table that stores the operation state of each service for each service, the cause when the service is stopped, and the waiting time until the service is executed.
The operation state management table 261 includes a service name 500 that is an identifier of the service, an operation state 501 that indicates the operation state of the service, a failure type 502 that indicates the cause when the service is stopped, and the service has caused the failure In this case, the service execution control unit 233 (see FIG. 1) includes a waiting time 503 that is a time interval for waiting for service execution, and an update time 504 that is an update time of each entry.

  The service standby time calculation unit 243 illustrated in FIG. 1 analyzes the log execution history information recorded in the business process execution history 254, calculates the standby time until the service is executed, and records it in the standby time management table 262. It is a processing unit.

FIG. 5 is a diagram showing the configuration of the standby time management table 262. As shown in FIG.
The standby time management table 262 shown in FIG. 5 is a table that holds the standby time until the service for each service and each failure type is executed.
The standby time management table 262 includes a service name 600 that is a service identifier, a failure type 601 that indicates a cause of a failure that has occurred in the service, and a service execution control when a failure of the failure type 601 occurs in the service The unit 233 includes a waiting time 602 that is a time interval for waiting for service execution.

<< Business Process Execution Processing by Business Process Execution Unit 230 >>
Next, business process execution processing by the business process execution unit 230 shown in FIGS. 1 and 2 will be described with reference to FIG.
FIG. 6 is a flowchart showing the flow of business process execution processing by the business process execution unit 230.
The business process execution unit 230 originally can simultaneously receive a plurality of business process execution requests from the client 270 and execute a plurality of business process instances in parallel. In FIG. The flow of processing is shown. Referring to FIG.

(Step 700 in FIG. 6) As shown in FIG. 1, the business process execution unit 230 receives the business process 1 processing request 100 transmitted from the client 270.
(Step 701) As shown in FIG. 1, the business process execution unit 230 generates a business process 1 instance 231 having an instance ID: 10001 in response to the business process 1 processing request 100.
(Step 702) The business process 1 instance 231 reads the business process 1 definition 251 as shown in FIG.
(Step 703) 1 is substituted into a variable i indicating the step ID being executed.

(Step 704) The business process 1 instance 231 acquires the step type of step ID i from the business process 1 definition 251 (see FIG. 1), determines whether or not the step type is “end step”, and the step type is “end”. If “step”, the process proceeds to step 715; otherwise, the process proceeds to step 705.
(Step 705) As shown in FIG. 1, the business process 1 instance 231 records the following data in the business process execution history 254 (see FIG. 3). Business process name 400: business process 1, instance ID 401: 10001, step ID 402: i, step type 403: step type of step IDi, step start time 404: current time, step end time 405: character string “-”, step state 406: Character string “executing”, execution result 407: Character string “−”, Failure type 408: Character string “−”.

(Step 706) It is determined whether or not the step type of step ID i acquired in step 704 is “service execution step”. If it is “service execution step”, the process proceeds to step 707. Otherwise, the process proceeds to step 712. To do.
(Step 707) The business process 1 instance 231 requests the service execution control unit 233 (see FIG. 1) for service execution processing. Details of this processing will be described later.
(Step 708) As shown in FIG. 1, a response from the service is received from the service execution control unit 233, and it is checked whether an exception has occurred. That is, the processing result 113 included in the service A processing response 112 is analyzed, and if the service has been successfully executed, the process proceeds to step 709, and if it has failed, the process proceeds to step 714.

(Step 709) The character string “success” and the result data 114 (see FIG. 1) acquired from the service processing response are stored in the variable r representing the service execution result. Further, the character string “-” is stored in the variable e representing the service failure type.
(Step 710) The business process 1 instance 231 shown in FIG. 1 updates the data recorded in the business process execution history 254 (see FIG. 3) in step 705 with the following data. Step end time 405: current time, step state 406: character string “completed”, execution result 407: content of variable r, failure type 408: content of variable e.
(Step 711) As shown in FIG. 1, the business process 1 instance 231 acquires the step ID of the next step after the step ID i from the business process 1 definition 251, stores it in i, and proceeds to step 704.

(Step 712) The step of step ID i is executed, the character string “-” is stored in the variable r indicating the service execution result and the variable e indicating the service failure type, and the process proceeds to step 710.
(Step 713) The character string “failure” is stored in the variable r representing the service execution result. Further, the failure type 124 acquired from the service B processing response (see FIG. 1) is stored in the variable e representing the service failure type.

  (Step 714) The business process 1 instance 231 shown in FIG. 1 updates the data recorded in the business process execution history 254 (see FIG. 3) in step 705 with the following data, and ends. Step end time 405: current time, step state 406: character string “error end”, execution result 407: content of variable r, failure type 408: content of variable e.

  (Step 715) The business process 1 instance 231 shown in FIG. 1 updates the data recorded in the business process execution history 254 (see FIG. 3) in step 705 with the following data, and ends the processing. Step end time 405: current time, step state 406: character string “completed”, execution result 407: character string “−”, failure type 408: character string “−”.

<< Service execution control processing by service execution control unit 233 >>
Next, service execution control processing by the service execution control unit 233 shown in FIGS. 1 and 2 will be described with reference to FIG.
FIG. 7 is a flowchart showing details of service execution control processing by the service execution control unit 233 in step 707 of FIG.
The service execution control unit 233 obtains the operating status of services such as the service A280 and the service B281 requested to be executed by the business process 1 instance 231 and 232 from the service status management unit 240 (see FIG. 1). If the service is operating, the service is executed. If the service is not operating and stopped, the service is postponed for the standby time 503 in the operation state management table 261 shown in FIG.

The update time threshold 101 and the maximum standby time 102 shown in FIG. 1 can be designated as parameters for controlling the operation of the service execution control unit 233.
The update time threshold 101 is a restriction on the freshness of the information held in the operation state management table 261 shown in FIG. 4, and the information registered in the operation state management table 261 is information older than the update time threshold 101. The service is executed even if the service operation state 501 indicated by the operation state management table 261 is “stopped”.

  The maximum standby time 102 is an upper limit value of the standby time in the service execution control unit 233. When the standby time 503 in the operation state management table 261 exceeds the maximum standby time 102, the maximum standby time is used as an actual standby time used for processing. Adopt 102. As a result, the client 270 (see FIGS. 1 and 2) that has a high response time request waits for a longer time than the client 270 expects in the service execution control unit 233 by setting the maximum standby time 102 short. Can be prevented.

In the present embodiment, as shown in FIG. 1, the update time threshold 101 and the maximum standby time 102 are set by the client 270 and included in the business process 1 processing request 100 and transmitted to the business process execution unit 230. The update time threshold 101 and the maximum standby time 102 may be set to different values for each service.
However, the configuration of FIG. 1 is an example, and for example, it can be realized by a method in which a developer sets the business process 1 definition 251 or an operator sets in the business process execution unit 230, and the setting method is not limited. .

  The business process 1 instances 231 and 232 shown in FIG. 1 send the processing data 111 and 121, the execution target business process definition name, and the execution target service name to the services A280 and B281, respectively, when requesting the processing to the service execution control unit 233. Information necessary for service execution, such as instance ID, step ID, step start time, update time threshold 101, and maximum standby time 102, is passed to the service execution control unit 233. Then, the service execution control unit 233 performs the following processing using these pieces of information. With reference to FIG.

(Step 800) The operating status 501 and update time 504 of the execution target service are acquired from the operating status management table 261 shown in FIG.
(Step 801) It is determined whether or not the operating state 501 acquired in Step 800 is stopped. If it is stopped, the process proceeds to Step 802, and if it is operating or there is no corresponding data, the process proceeds to Step 807.
(Step 802) It is determined whether or not the value obtained by subtracting the update time 504 acquired in Step 800 from the current time is smaller than the update time threshold 101. If smaller, the process proceeds to Step 803. To do.
(Step 803) The standby time of the execution target service is acquired from the standby time 503 of the operating state management table 261 shown in FIG. 4, and stored in the variable t representing the standby time.

(Step 804) If the standby time t acquired in step 803 is smaller than the maximum standby time 102 (see FIG. 1), the process proceeds to step 806, and if it is greater, the process proceeds to step 805.
(Step 805) The maximum standby time 102 is stored in the standby time t.
(Step 806) The process waits for the waiting time t. When the standby time t has elapsed, the routine proceeds to step 807.
(Step 807) As shown in FIG. 1, the service A processing request 110 and the like are obtained based on the service IF definition such as the service AIF definition 252 of the execution target service and the information acquired from the business process instance such as the business process 1 instance 231. A service processing request is generated, transmitted to a service such as service A280, and a response is received.

<< Update processing of waiting time management table 262 by service waiting time calculation unit 243 >>
Next, update processing of the standby time management table 262 (see FIG. 5) by the service standby time calculation unit 243 shown in FIGS. 1 and 2 will be described with reference to FIG.
FIG. 8 is a flowchart showing a flow of processing in which the service standby time calculation unit 243 of the service state determination unit 241 shown in FIG. 1 analyzes the business process execution history 254 and updates the standby time management table 262.
In the present embodiment, the processing shown in FIG. 8 is executed by detecting the update of the business process execution history 254 executed in step 705, step 710, step 711, and step 714 in FIG. 6, but this timing is an example. For example, only the update in steps 710 and 714 may be detected and the process of FIG. 8 may be performed, or the process of FIG. 8 may be performed at regular intervals regardless of the process of FIG.

  Further, in this embodiment, every business process execution history 254 (see FIG. 1) is read and processed every time the process of FIG. 8 is performed, but when the process shown in FIG. Processing may be performed by reading only the difference from the business process execution history 254. Referring to FIG.

(Step 900) The service state determination unit 241 shown in FIG. 1 detects the update of the business process execution history 254.
(Step 901) The service state determination unit 241 acquires information stored in the business process execution history 254 shown in FIG.

(Step 902) The service standby time calculation unit 243 shown in FIG. 1 analyzes the business process execution history 254 and acquires the service execution standby time for each service and each failure type.
The service execution standby time for each service and each failure type is calculated from the business process execution history 254 as follows. For a service, obtain the step start time Tstart of the entry whose service execution result is “failure”. Next, an entry having the same service execution result “success”, a step end time Tend newer than Tstart, and the closest time is searched. A value obtained by subtracting Tstart from Tend corresponds to one data of a time when the service cannot be executed due to the failure type of the service. In this way, the service execution impossible time is acquired for each service and each failure type, and the average value is set as the service execution standby time for each service and each failure type.

  In the example shown in FIG. 3, it can be seen from the entry 421 that the service execution of the service A 280 has failed. At this time, the failure type 408 is “service stop”, and the step start time 404 is 16:00:02. The entry whose service execution result of the service A280 closest to the entry 421 is successful is the entry 425, and the step end time 405 at this time is 16:10:35. From the above, one data of the service non-executable time in the failure type “service stop” of the service A280 is 16: 10: 35-16: 00: 02 = 10 minutes 33 seconds.

  (Step 903) The service standby time calculator 243 shown in FIG. 1 records the service execution standby time for each service and failure type calculated in Step 902 in the standby time 602 of the standby time management table 262 shown in FIG.

<< Update processing of the operation state management table 261 by the service operation state analysis unit 242 >>
Next, update processing of the operation state management table 261 by the service operation state analysis unit 242 illustrated in FIGS. 1 and 2 will be described with reference to FIG.
FIG. 9 is a flowchart showing a flow of processing in which the service operation state analysis unit 242 of the service state determination unit 241 (see FIGS. 1 and 2) analyzes the business process execution history 254 and updates the operation state management table 261. It is.

  In the present embodiment, the processing shown in FIG. 9 is executed by detecting the update of the business process execution history 254 executed in step 705, step 710, step 711, and step 714 in FIG. 6, but this timing is an example. For example, only the update in steps 711 and 714 may be detected and the process of FIG. 9 may be performed, or the process of FIG. 9 may be performed at regular intervals regardless of the process of FIG. Further, in the present embodiment, every business process execution history 254 is read and processed every time the processing of FIG. 9 is performed, but when the processing of FIG. 9 is performed twice or more, from the business process execution history 254 read last time. It is also possible to perform processing by reading only the difference. Referring to FIG.

(Step 1000) The service state determination unit 241 shown in FIG. 1 detects the update of the business process execution history 254.
(Step 1001) The service state determination unit 241 acquires information stored in the business process execution history 254.
(Step 1002) The service operation state analysis unit 242 shown in FIG. 1 analyzes the business process execution history 254 (see FIG. 3), and the latest execution result 407 and the step end times of the entries 420 to 426,. Get 405.

(Step 1003) It is determined whether or not the service execution result 407 is successful. If the execution result 407 is “failure”, the process proceeds to step 1004, and if “success”, the process proceeds to step 1007.
(Step 1004) The character string “stop” is stored in the variable s representing the operating state. Further, the failure type 408 of the entry acquired in step 1002 is stored in the variable e representing the failure type.
(Step 1005) The service operating state analysis unit 242 acquires the standby time 602 for the failure type of the service from the standby time management table 262 shown in FIG. 5, and stores it in the variable t representing the standby time. If there is no corresponding entry in the standby time management table 262, the default value set by the system operator is stored in the variable t representing the standby time.

  (Step 1006) The service operation state analysis unit 242 shown in FIG. 1 acquires the service name of each service acquired in Step 1002 as the service name 500 in the operation state management table 261 (see FIG. 4), the variable s, the failure as the operation state 501 The variable e is stored as the type 502, the variable t is set as the standby time 503, and the step end time 405 acquired in step 1002 is stored as the update time 504.

(Step 1007) The service operating state analysis unit 242 shown in FIG. 1 sets the character string “active” in the variable s indicating the operating state, the character string “−” in the variable e indicating the failure type, and the variable t indicating the standby time. Each of the character strings “-” is stored in, and the process proceeds to step 1006.
As described above, according to the service execution control unit 233 and the service state management unit 240 according to the first embodiment, the service is executed in the business process execution apparatus 200 (see FIGS. 1 and 2) that is the processing request transmission source in the loosely coupled system. The operating status of each service such as A280 can be detected.

Further, it is determined whether to execute the service immediately or wait for a certain period of time depending on the operating state of the service. When waiting, the service execution standby time for each service and failure type calculated from the business process execution history 254 shown in FIG. 3 is set as the standby time 602 (see FIG. 5).
As a result, the business process execution apparatus 200 as a whole can reduce the number of business process execution failures.

The effect of reducing the number of exception failures will be described below.
As shown in FIG. 1, it is assumed that one business process 1 instance executes service B281 and fails to execute because service B281 is stopped. The service state management unit 240 detects that the service B281 is stopped from the business process execution history 254, and postpones the execution of the service B281 by another instance.

  From the standby time 602 of the entry related to service B in the standby time management table 262 shown in FIG. 5, it can be seen that it takes 30 seconds on average until the service B 281 becomes executable. The service execution control unit 233 avoids the execution of the service B281 for a period estimated to be stopped from the past performance by postponing the execution of the service B281 by the instance for 30 seconds. As a result, the number of execution failures of the service B281 can be reduced. If the service B281 is executed after 30 seconds and fails, the postponement time is extended based on the information.

  In the first embodiment, a system in which a large number of business process execution requests from a client for one business process are generated at relatively short intervals, or a single service is used in a plurality of business processes. It is particularly effective in the system. This is because service execution requests are frequently generated, so that the service operating state is easily updated, and in addition, since the sampling interval is short, the accuracy of the postponement time is increased.

<< Second Embodiment >>
Next, a business process processing system 2S according to the second embodiment will be described with reference to FIGS.
<Features of Business Process Processing System 2S of Second Embodiment>
In the business process definition (see FIG. 1) used in the first embodiment, since each service is directly executed from the business process definition, the operating state of each service is simply confirmed.

FIG. 10 is a diagram illustrating a data flow in the business process processing system according to the second embodiment.
Incidentally, for example, as shown in FIG. 10, when the business process 2 instance 1201 requests the service execution control unit 233 to execute the business process 1 definition 251, the business process 1 is executed only on the deployment state of the business process 1 itself. Execute. However, if the service B281 is stopped due to some failure, the execution of the business process 1 fails and the business process 2 instance 1201 ends abnormally.

  Therefore, when executing another business process definition from the business process definition, in order to determine whether or not the business process definition on the side to be executed can be executed, it is executed in addition to the deployment state of the business process definition on the side to be executed. It is also necessary to check the operating status of each service used by the business process definition on the other side.

  Here, “execute another business process definition b from business process definition a” means that the business process instance of business process definition a sends a processing request to the business process execution part where business process definition b is deployed. This means a series of processing until the business process instance of the business process definition b performs processing and the processing result is received by the business process instance of the business process definition a which is the processing request transmission source.

The business process processing system 2S of the second embodiment is provided with a business process 2 definition 1220 that executes the business process 1 definition 251 and applies the present invention to processing when executing another business process definition from one business process definition. It is possible.
In the business process processing system 2S of the second embodiment, as shown in FIG. 10, the client 1240 transmits a business process 2 processing request 1101 to the business process execution unit 230. The business process execution unit 230 generates a business process 2 instance 1201. The business process 2 instance 1201 executes processing according to the business process 2 processing request 1101 and the business process 2 definition 1220. The business process 2 definition 1220 executes the business process 1 definition 251, and the business process 1 definition 251 executes the service A 280 and the service B 281 as in the first embodiment. Since the operation related to the business process 1 definition 251 is the same as that of the first embodiment, the description thereof is omitted.

<< Outline of Business Process Processing System 2S of Second Embodiment >>
The business process processing system 2S of the second embodiment shown in FIG. 10 has a complicated configuration in which a business process is executed from the business process, and the business process is processed in consideration of the operating state of the service on which the business process depends. The purpose is to avoid business process execution failure by determining the operating state and controlling the execution timing of the business process.
As shown in FIG. 10, in the business process processing system 2S of the second embodiment, the dependency analysis unit 1210 newly provided in the service state management unit 240 analyzes the business process 1 definition 251, and the business process 1 definition A list of services used by 251 is recorded in the dependency management table 1232. The service execution control unit 233 inquires the deployment status of the business process 1 definition 251 immediately before the business process 1 definition 251 is executed.

The business process status determination unit 1211 determines whether or not the business process 1 definition 251 itself can be executed, including not only the deployment status of the business process 1 definition 251 itself, but also answers to the service execution control unit 233 To do.
Thereby, it is possible to appropriately determine whether or not execution is possible even in a complicated configuration in which another business process is executed from a certain business process. Also, when analyzing the dependency between business processes and services, the structure of the business process such as conditional branching is considered in order to avoid determining that the operation rate of the business process is unnecessarily low.

<Hardware configuration>
FIG. 11 is a diagram illustrating an example of a hardware configuration in the business process processing system 2S of the second embodiment.
As shown in FIG. 11, the business process processing system 2S of the second embodiment includes a client execution device 201 that performs a processing request, a business process execution device 200 that executes the processing, and services A280 and B281 related to the processing request. It comprises service execution devices 202 and 203 to be executed.

All processing units arranged on the client execution device 201, the business process execution device 200, and the service execution devices 202 and 203 may be realized as dedicated hardware or as a program executed by the CPU. However, a case where it is realized as a program will be described below.
The client execution device 201, business process execution device 200, and service execution devices 202 and 203 are connected via a network 204. The network 204 may be a local network such as a LAN or an intranet, or a global network such as the Internet. Further, a plurality of client execution devices 201 and service execution devices 202 and 203 may exist.

The client execution device 201 is substantially the same as that of the first embodiment, except that the client 1240 is provided in the main storage device 211. As illustrated in FIG. 10, the client 1240 is a processing unit that transmits a business process 2 processing request 1101 to the business process execution apparatus 200, and a corresponding program is executed and deployed by the CPU 210.
Since the service execution apparatuses 202 and 203 shown in FIG. 11 have the same configuration as that of the first embodiment, description thereof is omitted.

<Business process execution device 200>
As illustrated in FIG. 11, the business process execution device 200 includes a business process 2 instance 1201 and a business process 1 instance 1202 in the business process execution unit 230 in the main storage device 211. Further, the service state management unit 240 is provided with a dependency relationship analysis unit 1210 and a business process state determination unit 1211 according to the second embodiment.
It should be noted that the business process execution program 220 is executed by the CPU 210 in each processing unit such as the business process execution unit 230 and the service state management unit 240 in the main storage device 211 and is deployed.

In addition, the secondary storage device 212 includes a business process 2 definition 1220, a business process 1 interface definition 1221 (hereinafter referred to as a business process 1IF definition 1221), a business process management table 1223, and a dependency management table according to the second embodiment. 1232 is provided. Since the configuration other than this is the same as that of the first embodiment, the description thereof is omitted.
The configuration of each part of the business process execution device 200 will be described below.

<Business process 2 instance 1201>
The business process 2 instance 1201 shown in FIG. 10 holds the execution state for each processing request such as the progress state of the business process and the value of the variable used in the business process, and performs processing according to the execution state and the contents of the business process 2 definition 1220. The business process execution unit 230 generates a request for each business process 2 processing request 1101 received by the business process execution unit 230.

<Business process 2 definition 1220>
An example of processing contents of the business process 2 definition 1220 used in the second embodiment is shown in the business process 2 definition 1220 shown in FIG.
The business process 2 definition 1220 is a step ID1 that receives the business process 2 processing request 1101 (see FIG. 10) and extracts data and the step type is the start step, step 1300, and the step ID2 that executes the business process 1 definition 251. Step 1301 is a service execution step, and step 1302 is post-processing step ID3 and step type is an end step.

However, the above content is an example of a business process definition, and any processing flow may be defined as long as it can be described in the business process definition language.
Since the business process 1 definition 251 (see FIGS. 10 and 11) executed by the business process 2 definition 1220 is the same as that shown in the first embodiment, the description thereof is omitted.

<Business process 1IF definition 1221>
Information required for executing the business process 1 definition 251 is described in the business process 1IF definition 1221 shown in FIGS. For example, the data structure of data required as input or the data structure of data to which the business process 1 definition 251 responds. The service execution control unit 233 (see FIG. 10) that has received an instruction to execute the business process 1 from the business process 2 instance 1201 generates a business process 1 processing request 1102 in accordance with the business process 1 IF definition 1221, and the business process execution unit 230 Send to. The business process execution unit 230 that has received the business process 1 processing request 1102 generates a business process 1 instance 1202. The business process 1 instance 1202 performs processing according to the business process 1 processing request 1102 and the business process 1 definition 251.

<Dependency analysis unit 1210>
The dependency analysis unit 1210 shown in FIGS. 10 and 11 analyzes the business process 1 definition 251 and the business process 2 definition 1220, acquires a list of services used by each business process definition, and registers them in the dependency management table 1232. Is a processing unit. Details of the processing in this processing unit will be described later.

<Dependency management table 1232>
FIG. 12 is a diagram showing a configuration of the dependency management table 1232.
The dependency relationship management table 1232 illustrated in FIG. 12 is a table that holds, for each business process definition, a business process name and a service name executed by the business process definition.
The dependency management table 1232 includes a business process name 1400 that is an identifier of a business process definition, and a dependency service (business process) name 1401 that is a list of services and business process identifiers used by the business process definition.

<Business process status determination unit 1211>
The business process state determination unit 1211 shown in FIGS. 10 and 11 is a processing unit that determines the operating state of a business process from information held by the service state management unit 240 and registers it in the operation state management table 1230. Details of the processing in this processing unit will be described later.

<Business process management table 1223>
FIG. 13 is a diagram showing an example of the configuration of the business process management table 1223.
The business process management table 1223 shown in FIG. 13 is a table that holds the deployment status of the business process definition itself, and includes a business process name 1500 that is an identifier of the business process definition and a business process definition status 1501.
The business process definition state 1501 includes “deployed” that has been deployed to the business process execution device 200 but not accepted a processing request, and has been deployed to the business process execution device 200 and can accept a processing request. There is a state such as “in operation”.

  The configuration of FIG. 13 is an example, and information other than the above may be included. Registration of information in the business process management table 1223 may be performed by a processing unit included in the business process execution program 220 or may be performed by another processing unit. Omitted.

<Operation status management table 1230>
FIG. 14 is a diagram showing the configuration of the operating state management table 1230.
The operation state management table 1230 shown in FIG. 14 has the same configuration as the operation state management table 261 (see FIG. 4) exemplified in the first embodiment, but includes not only services but also business processes as management targets. The points are different (see service (business process) name 1600 in FIG. 14).
When the target is a business process, whether or not the business process can be executed is in the active state 1601, the failure that causes the business process to not be executed is in the failure type 1602, the business process execution standby time is in the standby time 1603, The update time is stored in the update time 1604.

<Standby time management table 1231>
FIG. 15 is a diagram showing the configuration of the standby time management table 1231. As shown in FIG.
The standby time management table 1231 shown in FIG. 15 has the same configuration as the standby time management table 262 (see FIG. 5) exemplified in the first embodiment, but includes not only services but also business processes as management targets. The points are different (see service (business process) name 1700 in FIG. 15). When the target is a business process, a failure that is a cause when the business process cannot be executed is stored in the failure type 1701, and the business process execution standby time is stored in the standby time 1702.

<< Business Process Execution Processing by Business Process Execution Unit 230 >>
The flow of business process execution processing by the business process execution unit 230 in the second embodiment is substantially the same as that in FIG. 6 of the first embodiment, and thus the description is omitted, but the following points are different. (a) The business process definition to be executed is changed from the business process 1 definition 251 (see FIG. 1) to the business process 2 definition 1220 (see FIG. 10), and (b) the business process 1 processing request 100 (see FIG. 1). Change to business process 2 processing request 1101 (see FIG. 10), (c) Change business process 1 instance 2311 (see FIG. 1) to business process 2 instance 1201 (see FIG. 10).

<< Update processing of dependency management table 1232 by dependency analysis unit 1210 >>
Next, update processing of the dependency relationship management table 1232 by the dependency relationship analyzing unit 1210 will be described with reference to FIG.
FIG. 16 is a flowchart showing the flow of processing in which the dependency relationship analysis unit 1210 shown in FIG. 10 analyzes the business process 1 definition 251 and the business process 2 definition 1220 and updates the dependency relationship management table 1232.
In this process, by analyzing the business process definition and the service IF definition, a service used from the business process is registered in the dependency management table 1232 as a dependent service of the business process. Only when all the dependent services are operating, the business process is determined to be executable. Here, if all services executed from a business process are unconditionally registered as dependent services, it is assumed that the operation rate of the business process is judged to be uselessly low.

Therefore, in the second embodiment, focusing on conditional branching and execution of asynchronous services in the structure of business processes, by limiting the services registered as dependent services, the operation rate is determined to be low. It is avoiding.
Specifically, when analyzing a business process definition in order from the top of the flow, if any of the following two points is met, the analysis is stopped at that point. Only services executed before the stop point are registered as dependent services, and services executed after the stop point are not counted as dependent services.

(a) Conditional branch step When a conditional branch step exists, the path actually executed is unknown until the business process is executed. For this reason, when all the services arranged at the branch destination are registered as dependent services, a service that is not actually executed may be registered as a dependent service. In order to avoid this, for business processes in which conditional branches exist, the steps up to the step before the conditional branch are subject to dependency analysis.

(b) Execution of Asynchronous Service Some services have a relatively long execution time (several hours to several days). For example, it is a service that performs a manual application-approval process. These are called asynchronous services because they respond asynchronously to processing requests from business processes.
Because execution of an asynchronous service takes time, services that are executed in the steps after the asynchronous service change the operating state when the service is actually executed even if the operating state is determined at the start of business process execution. Probability is high.

In order to avoid this, for business processes where asynchronous service execution exists, the processes up to the step prior to asynchronous service execution are subject to dependency analysis.
Whether the service to be executed is an asynchronous service can be identified from the service IF definitions such as the service AIF definition 252 and the service BIF definition 253 shown in FIGS. Specifically, only the data type of the processing request is defined as the definition of the execution method of the service, and those having no definition regarding the processing response can be determined as an asynchronous service.
Based on the above, the update process of the dependency management table 1232 will be described based on FIG.
Referring to FIG.

(Step 1800) Business process 1 definition 251, business process 2 definition 1220, service AIF definition 252 and service BIF definition in which dependency analysis unit 1210 of service state management unit 240 shown in FIG. 10 is deployed on business process execution device 200 Get 253.
(Step 1801) Steps 1802 to 1809 are executed for all the acquired business process definitions.
(Step 1802) The business process definition to be processed is read.
(Step 1803) 1 is substituted into the variable i representing the processing step ID.

(Step 1804) It is determined whether the step type of step IDi of the business process definition to be processed is an end step or a branch step. If it is an end step or a branch step, the process proceeds to step 1809. Otherwise, the process proceeds to step 1805. To do.
(Step 1805) It is determined whether or not the step type of step IDi of the business process definition to be processed is a service execution step. If it is a service execution step, the process proceeds to step 1806. Otherwise, the process proceeds to step 1808.
(Step 1806) It is determined whether the service to be executed is an asynchronous service. If it is not an asynchronous service, the process proceeds to Step 1807, and if it is an asynchronous service, the process proceeds to Step 1809.

(Step 1807) The service name (business process name) executed at step ID i is added to the dependency service name 1401 as the dependency service of the business process being analyzed in the dependency relationship management table 1232 shown in FIG.
(Step 1808) The step ID of the next step after step IDi is acquired from the processing target business process definition, substituted into i, and the process proceeds to step 1804.
(Step 1809) It is determined whether or not the processing has been completed for all the acquired business process definitions, and if the processing has been completed for all the acquired business process definitions, the process proceeds to Step 1810. Move to 1802.

  (Step 1810) When all the entries in the dependency management table 1232 shown in FIG. 12 are searched and a business process is registered in the dependent service (business process) name 1401, all the services on which the business process depends ( Business process) is added as dependent service (business process) name 1401. For example, in the second embodiment, as shown in FIG. 12, the business process 2 uses a business process 1, and the business process 1 uses a service A280 and a service B281. At this time, as shown in FIG. 12, service A280 and service B281 are registered in the dependency management table 1232 as business service 1 dependent services, and business process 1 and business process 1 depend as business service 2 dependent services. Service A280 and Service B281 are registered.

<< Registration processing in the operation status management table 1230 by the business process status determination unit 1211 >>
Next, registration processing in the operation state management table 1230 by the business process state determination unit 1211 shown in FIGS. 10 and 11 will be described with reference to FIG.
In FIG. 17, the business process state determination unit 1211 determines the operation state of the business process from information registered in the operation state management table 1230, the standby time management table 1231, the business process management table 1223, and the dependency relationship management table 1232. 10 is a flowchart showing a flow of processing for registration in an operation state management table 1230.

A method for determining the operating status 1601 and standby time 1603 of the business process registered in the operating status management table 1230 shown in FIG. 14 will be briefly described.
The business process definition such as the business process 1 definition 251 shown in FIG. 10 and FIG. 11 is deployed in the business process execution apparatus 200 and can accept requests, and all the services used by the business process are operating. If it is, the business process is determined to be executable, and “operation” is registered as the operation state 1601 in FIG. If the business process definition does not accept the request or one or more of the services to be used are stopped, it is determined that the business process cannot be executed, and “stopped” is registered as the operation state 1601 in FIG. The When the operating state 1601 is stopped, all service execution standby times of the services used by the business process are acquired, and the longest standby time among them is registered as the standby time 1603 in FIG. .

  In the second embodiment, the processing shown in FIG. 17 is executed by detecting the update of the operating state management table 1230 or the standby time management table 1231. This timing is an example, and for example, the processing of the tables 1230 and 1231 is performed. Regardless of the update, the processing of FIG. 17 may be performed at regular intervals. Further, in the second embodiment, every time the processing of FIG. 17 is performed, the business process execution history 254 shown in FIGS. 10 and 11 is read and processed. However, when the processing of FIG. 17 is performed twice or more, Alternatively, only the difference from the previously read business process execution history 254 (see FIG. 3) may be read for processing.

With reference to FIG.
(Step 1900) The service state management unit 240 shown in FIG. 10 detects the update of the operation state management table 1230 or the standby time management table 1231.
(Step 1901) The business process entry in the operating state management table 1230 shown in FIG. 14 is initialized with the following data. Service (business process) name 1600: (no change), operation status 1601: character string "active", failure type 1602: character string "-", standby time 1603: character string "-", update time 1604: character string "-".
(Step 1902) The processing from step 1903 to step 1907 is executed for all the services Sstop whose operation state 1601 is “stopped” among the entries registered in the operation state management table 1230.

(Step 1903) The service name 1600 and failure type 1602 of the service Sstop which is “stopped” are acquired from the operating state management table 1230 shown in FIG. 14, and stored in the variable e representing the failure type. Also, the standby time 1603 is acquired and stored in a variable t1 representing the standby time. Also, the update time 1604 is acquired and stored in a variable tr representing the update time.
(Step 1904) All the business processes bp depending on the service Sstop which is “stop” are acquired from the dependency management table 1232 shown in FIG.
(Step 1905) Whether or not the standby time 1603 is smaller than the character string “-” or the standby time variable t1 for the entry whose service (business process) name 1600 is the business process bp in the operating state management table 1230 (see FIG. 14) If the waiting time 1603 is smaller than the character string “-” or the waiting time variable t1, the process proceeds to step 1906. If the waiting time 1603 is greater than t1, the process proceeds to step 1907.

(Step 1906) The entry whose service (business process) name 1600 is the business process bp in the operating state management table 1230 shown in FIG. 14 is updated with the following data. Operating state 1601: Character string “stopped”, failure type 1602: failure type variable e, standby time 1603: standby time variable t1, update time 1604: update time variable tr.
(Step 1907) Of the entries registered in the operating state management table 1230 shown in FIG. 14, it is determined whether or not the processing has been completed for all services Sstop whose operating state 1601 is stopped. If so, the process proceeds to step 1908, and if not completed, the process proceeds to step 1903.

(Step 1908) The processing from Step 1909 to Step 1913 is executed for all business processes BPstop whose status 1501 is stopped among the business processes registered in the business process management table 1223 shown in FIG.
(Step 1909) The standby time 1702 of the stopped business process BPstop is acquired from the standby time management table 1231 shown in FIG. 15, and stored in a variable t2 representing the standby time. Further, the failure type 1602 of the operating state management table 1230 shown in FIG. 14 is acquired and stored in the variable e2 representing the failure type. Also, the update time 1604 is acquired and stored in a variable tr2 representing the update time.

(Step 1910) Acquire all business processes (business process name 1400) including the business process BPstop that is stopped in the dependency service (business process) name 1401 from the dependency management table 1232 shown in FIG. Is stored in the variable bp representing.
(Step 1911) Whether or not the waiting time 1603 is smaller than the character string “-” or t2 for the entry in which the service (business process) name 1600 of the operation state management table 1230 shown in FIG. 14 is included in the variable bp of the business process name If the waiting time 1603 is smaller than the character string “−” or t2, the process proceeds to step 1912. If the waiting time 1603 is equal to or greater than t2, the process proceeds to step 1913.

(Step 1912) The entry whose service (business process) name 1600 is the variable bp of the business process name in the operation state management table 1230 shown in FIG. 14 is updated with the following data. Operating state 1601: Character string “stopped”, failure type 1602: failure type variable e2, standby time 1603: standby time variable t2, update time 1604: update time variable tr2.
(Step 1913) Among the business processes registered in the business process management table 1223 shown in FIG. 13, it is determined whether or not the processing has been completed for all business processes BPstop whose status 1501 is stopped. If so, exit. If not completed, the process proceeds to step 1909.
The above is the registration process to the operation state management table 1230 by the business process state determination unit 1211 shown in FIG.

  According to the dependency relationship analysis unit 1210 and the business process state determination unit 1211 (see FIGS. 10 and 11) according to the second embodiment, a business process can be performed even in a complicated configuration in which another business process is executed from a certain business process. Can be determined. Moreover, it is possible to avoid determining the operation rate of the business process lower than necessary by analyzing the dependency relationship in consideration of the structure of the business process such as conditional branching. Thereby, the execution timing of the business process can be controlled according to the operating state of the business process, and the business process execution apparatus 200 as a whole can reduce the number of business process execution failures.

<< Summary >>
The present invention controls a service execution timing according to a service operating state in a business process processing system in which a business process executes a plurality of services on a network in a defined order to perform a business.
For this reason, in the present invention, as shown in FIG. 1, the business process execution history 254 held by the business process execution apparatus 200 is analyzed, and the operating status of services such as services A280, B281, etc. Get the service execution waiting time. The service operating state is checked immediately before executing the service, and it is determined whether to execute the service immediately according to the service operating state or to execute after waiting for a certain time.

  As the standby time for standby, the service execution standby time for each service and each failure type is used. The business process execution history 254 used for acquiring the service operating state includes the execution history of all business processes deployed in the business process execution apparatus 200. Therefore, in the present invention, the execution result of a service by a certain business process is shared by all the business processes deployed in the business process execution apparatus 200 via the business process execution history 254.

  In addition, the business process and service dependency is obtained from the business process definition, and the business process operating state is determined from information such as the dependency, business process structure, and service operating state, and according to the business process operating state. Determine whether to execute the business process immediately or after waiting for a certain time.

The outline of the solving means will be described with reference to FIG.
FIG. 18 is a conceptual diagram of processing for controlling the execution timing of a business process according to the service operating state when the business process has multiple stages.
The service execution control unit 233 according to the present invention performs the processing of executing the purchase business process 1853 from the order business process 1851. The service execution control unit 233 acquires the operating state of the purchase business process from the service state management unit 240 according to the present invention. The service state management unit 240 determines whether or not the purchase business process 1853 can be executed from the dependency relationship information indicating which service the purchase business process 1853 uses and the service operation information indicating the operation state of each service.

  The purchase business process 1853 uses a delivery date confirmation service 1862 and an order service 1863. When the two services are operating, the service execution control unit 233 immediately executes the purchase business process 1853. If one of the services is stopped, it is determined that the purchase business process 1853 cannot be executed, and the service execution control unit 233 waits for a certain period of time to wait for service recovery, and then executes the purchase business process 1853. Through the above processing, the execution timing is controlled in accordance with the operating state of the business process, and the business process is prevented from failing effectively.

Also, when analyzing the dependency between business processes and services, it is necessary to consider the structure of the business process. This will be described with reference to FIG.
FIG. 19 is a diagram showing the dependency analysis range according to the structure of the business process, (a) is a diagram showing a business process including a conditional branch in the middle of processing, and (b) is a diagram showing It is a figure which shows the business process in which execution of the asynchronous service c is included in the middle of a process.

  In the business process shown in FIG. 19A, it cannot be determined whether the service c or the service d is executed until the branch result is determined. In this case, if the operation of both services c and d is used as the condition for determining the operating state of the business process, there is a possibility that the operating rate of the business process is unnecessarily determined low. For this reason, in the case of FIG. 19 (a), the part before the branch is set as the dependency analysis target.

  Further, the business process shown in FIG. 19B includes the execution of the asynchronous service c in the middle of processing. An asynchronous service is a service that takes a relatively long time from the start to the end of processing. There is a high possibility that the operating state of the synchronous service d executed after the asynchronous service c is different from that at the start of business process processing. In this case, if the operation of the synchronous service d is used as the condition for determining the operating state of the business process, there is a possibility that the operating rate of the business process is unnecessarily determined low. For this reason, in the case shown in FIG. 19B, the object before the asynchronous service c is set as the dependency analysis target.

Thus, in the present invention, the business process and service dependency are determined in consideration of the structure of the business process.
According to the present invention, a business process processing system detects that a service has stopped due to a business process failing to execute a service, and temporarily postpones execution of the stopped service by a subsequent business process. Overall, the number of business process execution failures can be reduced.

  Furthermore, in a complex configuration where a business process is executed from a business process, the business process processing system as a whole is determined by determining the operating state of the business process in consideration of the operating state of the service on which the business process depends. The number of business process execution failures can be reduced.

It is a figure which shows the flow of the data in the business process processing system of 1st Embodiment in connection with this invention. It is a figure which shows an example of the hardware constitutions of the business process processing system of 1st Embodiment. It is a figure which shows an example of a structure of a business process execution log | history. It is a figure which shows the structure of an operation state management table. It is a figure which shows the structure of a waiting time management table. It is a flowchart which shows the flow of the business process execution process by a business process execution part. It is a flowchart which shows the detail of the service execution control process by a service execution control part. It is a flowchart which shows the flow of the process in which a service waiting time calculation part updates a waiting time management table. It is a flowchart which shows the flow of a process in which a service operation state analysis part updates an operation state management table. It is a figure which shows the flow of the data in the business process processing system of 2nd Embodiment. It is a figure which shows an example of the hardware constitutions in the business process processing system of 2nd Embodiment. It is a figure which shows the structure of a dependence relationship management table. It is a figure which shows an example of a structure of a business process management table. It is a figure which shows the structure of an operation state management table. It is a figure which shows the structure of a waiting time management table. It is a flowchart which shows the flow of a process in which a dependence analysis part updates a dependence management table. It is a flowchart which shows the flow of the process which a business process state determination part registers into an operation state management table. It is a conceptual diagram of the process which controls the execution timing of a business process according to the operation state of a service, when a business process is multistage. (a) is a figure which shows the business process in which the conditional branch is included in the middle of a process, (b) is a figure which shows the business process in which execution of an asynchronous service is included in the middle of a process. It is the figure which showed the failure occurrence condition in case the conventional business process is multistage. It is the figure which showed the mode of the recovery operation | work of the conventional fault.

Explanation of symbols

200 Business process execution device
204 network
230 Business Process Execution Department
233 Service execution control section
242 Service Operating State Analysis Department
243 Service waiting time calculator
251 Business process 1 definition (business process definition, other business process definition)
254 Business process execution history (business process execution history storage)
261 Operating status management table (Service operating status analyzer)
270, 1240 clients
280 Service A
281 Service B
503 Waiting time (Service execution waiting time of Claim 1)
602 waiting time (service execution waiting time for each cause of execution failure of each service of claim 3)
1210 Dependency analyzer
1211 Business process status judgment part
1220 Business process 2 definition (a business process definition)
1230 Operating status management table (Service operating status analysis part)
1862 Delivery Confirmation Service (service used by other business process definitions)
1863 Order service (service used by other business process definitions)
a Service (service executed before the conditional branch in claims 7 and 17)
b Service (service executed before the conditional branch in claims 7 and 17)
c Asynchronous services (asynchronous services of claims 8 and 18),

Claims (20)

A business process execution device that executes a plurality of services on a network in the order described in a business process definition in response to a client processing request,
A service standby time calculation unit that calculates a service execution standby time for each stopped service from a service execution result by a business process stored in the business process execution history storage unit;
A service operation state analysis unit that determines an operation state for each service from the latest service execution result stored in the business process execution history storage unit and obtains a service execution standby time for each stopped service;
Before executing the service, obtain the operating state of the service and the service execution waiting time, and execute the service when the service is in operation, while the service is stopped A business process execution apparatus comprising: a service execution control unit that postpones execution of the service during the service execution standby time. The business process execution device according to claim 1,
The service waiting time calculation unit
For each service, the difference between the service execution failure time and the service execution success time of the same service immediately after the service execution failure time is acquired from the business process execution history storage unit, and the average is calculated as the service execution waiting time. A business process execution device characterized by that. In the business process execution device according to claim 1,
The service waiting time calculation unit
For each cause of execution failure of each service, the difference between the service execution failure time and the service execution success time of the same service immediately after the service execution failure time is obtained from the business process execution history storage unit, and the average is A business process execution device characterized in that the service execution standby time is calculated for each cause of execution failure of each service. The business process execution device according to claim 1,
The service execution control unit
The update time of the service operation state is compared with the time at which the service execution control unit is executing the process. If the difference is equal to or greater than a predetermined value, the service is updated regardless of the service operation state. A business process execution device characterized by executing. The business process execution device according to claim 1,
The service execution control unit
When the service execution standby time is a predetermined value or more, the service is executed regardless of the operation state of the service. The business process execution device according to claim 1,
A dependency analysis unit that analyzes the other business process definition when a business process definition executes another business process definition and obtains a list of services used by the other business process definition;
It is determined whether or not the other business process definition can be executed from the operating state of all services used by the other business process definition and the deployment state of the other business process definition, and the other business process definition uses A business process state determination unit that obtains the service execution waiting time of a service to be executed from the service operating state analysis unit and determines a business process execution waiting time of the other business process definition. apparatus. The business process execution device according to claim 6,
The dependency analysis unit
When the other business process definition includes a conditional branch, a service executed before the conditional branch is acquired as a service used by the other business process definition. The business process execution device according to claim 6,
The dependency analysis unit
In the case of including a process for executing a service in which a response is asynchronously returned to the other business process definition, the other business process definition uses all services executed before the execution process of the asynchronous service. A business process execution device characterized by being acquired as a service to perform. The business process execution device according to claim 6,
The business process state determination unit
A list of services used by the other business process definition is acquired from the dependency analysis unit, and an operation state of the acquired service is acquired from the service operation state analysis unit, and the other business process is acquired. Obtain the deployment status of the definition from the business process execution device,
Determining that other business process definitions can be executed when all the services included in the service list are in an active state and the other business process definitions are deployed on the business process execution device. Business process execution device characterized by The business process execution device according to claim 6,
The business process state determination unit
When the operating state of one or more services used by the other business process definition is stopped, the service execution waiting time of the stopped service is acquired from the service operating state analysis unit, and the acquired service A business process execution apparatus characterized in that the longest service execution waiting time among the execution waiting times is set as the execution waiting time of the other business process definition. A business process execution method for executing a plurality of services on a network in the order described in a business process definition in response to a client processing request,
Business process execution device
Calculate the service execution waiting time for each stopped service from the service execution result by the business process stored in the business process execution history storage unit,
Determining an operating state for each service from the latest service execution result stored in the business process execution history storage unit and obtaining a service execution waiting time for each stopped service;
Before the service is executed, the service is executed when the service is in operation by acquiring the operation state and the service execution waiting time of the service, and when the service is stopped Execution of the service is postponed during the service execution waiting time. The business process execution method according to claim 11,
The service execution waiting time is calculated as follows:
For each service, the difference between the service execution failure time and the service execution success time of the same service immediately after the service execution failure time is acquired from the business process execution history storage unit, and the average is calculated as the service execution standby time. A business process execution method characterized by that. The business process execution method according to claim 11,
The service execution waiting time is calculated as follows:
For each cause of execution failure of each service, the difference between the service execution failure time and the service execution success time of the same service immediately after the service execution failure time is acquired from the business process execution history storage unit, and the average is A business process execution method, wherein the service execution standby time is calculated for each cause of execution failure of each service. The business process execution method according to claim 11,
The business process execution device includes:
The update time of the service operation state is compared with the time when the process is executed, and if the difference is equal to or greater than a predetermined value, the service is executed regardless of the service operation state. Business process execution method. The business process execution method according to claim 11,
When the service execution standby time is equal to or greater than a predetermined value, the service is executed regardless of the operation state of the service. The business process execution method according to claim 11,
The business process execution device includes:
When a business process definition executes another business process definition, the other business process definition is analyzed to obtain a list of services used by the other business process definition,
It is determined whether or not the other business process definition can be executed from the operating state of all services used by the other business process definition and the deployment state of the other business process definition, and the other business process definition uses A business process execution method comprising: obtaining the service execution waiting time of a service to be performed and determining a business process execution waiting time of the other business process definition. The business process execution method according to claim 16, wherein
When analyzing the other business process definition and obtaining a list of services used by the other business process definition,
When a conditional branch is included in the other business process definition, a service executed before the conditional branch is acquired as a service used by the other business process definition. The business process execution method according to claim 16, wherein
When analyzing the other business process definition and obtaining a list of services used by the other business process definition,
In the case of including a process for executing a service in which a response is asynchronously returned to the other business process definition, the other business process definition uses all services executed before the execution process of the asynchronous service. A business process execution method characterized by being acquired as a service. The business process execution method according to claim 16, wherein
The business process execution device includes:
Obtain a list of services used by the other business process definition, obtain an operating state of the obtained service, and obtain a deployment state of the other business process definition from the business process execution device. ,
Determining that another business process definition can be executed when all the services included in the service list are in an active state and the other business process definition is deployed on the business process execution device. Business process execution method characterized by The business process execution method according to claim 16, wherein
The business process execution device includes:
When the operation state of one or more services used by the other business process definition is stopped, the service execution waiting time of the stopped service is acquired, and the longest service execution waiting time is acquired. A business process execution method characterized in that a service execution standby time is set as an execution standby time of the other business process definition.

Images