Business integration system and management method for business integration system

Abstract

A business integration system which has an upstream unit configuration 10 and a downstream unit configuration 30 and which executes processing related to prescribed business includes: an instruction part 131 for notifying an execution instruction for the downstream unit configuration 30; a system state determination part 12 for detecting the occurrence of an event that has an impact on the processing related to the business in the business integration system and identifying the impact range of the event; and an arithmetic execution part 132 for executing the processing related to the prescribed business. The instruction part 131 provides a standby instruction for continuing the processing of the downstream unit configuration 30, with respect to the impact range, via a communication part 11, and cancels the standby instruction upon detection of restoration of the event. The arithmetic execution part 132 acquires the result of the related processing in the downstream unit configuration corresponding to the execution instruction, reflects the result of the related processing, and executes processing after the related processing.

Description

Business integrated system and business integrated system management method

[0001] The present invention relates to a technique for managing an integrated business system that is made up of a plurality of devices and systems.

[0002] In recent years, various tasks are often performed in cooperation with multiple devices and systems. For example, a system has been proposed in which a development environment is prepared on a shared cloud, allowing multiple parties to collaborate on development. In such a system, various devices, such as terminal devices used by the parties, are connected via a network. In such a system, if a failure such as a communication failure occurs, tasks such as development can be delayed.

[0003] Patent Document 1 proposes a countermeasure against such failures. Its objective is to provide a failure detection / recovery system that enables failure detection and recovery of network devices without incurring large expenses, even on large-scale networks or wide-area networks. To solve this problem, Patent Document 1 discloses a system that includes a management PC 1 and network devices 2 arranged on a network 4, and a failure detection / recovery device 3 provided in each of the network devices. The failure detection / recovery device 3 supplies power to the network device 2, then transmits a communication confirmation command to the network device 2, and, if there is no response to this transmission, determines that a failure has occurred and stops the power supply to the network device 2. After a predetermined period of time has elapsed since the power supply was stopped, the failure detection / recovery device 3 resumes supplying power to the network device 2 and transmits the communication confirmation command to the network device 2. If there is a response to this transmission, the failure of the network device 2 is determined to have been recovered from and the transmission of the communication confirmation command is resumed.

[0004] Japanese Patent Application Laid-Open No. 2006-293666

[0005] An example of such a system is an integrated business system in which a plurality of unit components work together. The unit components refer to devices such as servers and PCs, or a system made up of a plurality of devices.

[0006] With such an integrated business system, even if the failure is restored as in Patent Document 1, processing may stop during that time, which may result in wasting time until the business is completed. For example, if the integrated business system is used to develop a deliverable such as software, the delivery of the deliverable may be delayed.

[0007] For this reason, business integration systems require processing continuity in the event of a network failure or other problem. However, in the pipeline processing of conventional business integration systems, even if the job execution environment is still operational in the event of a failure, the pipeline management side will force a Fail and treat the execution as unsuccessful. As a result, processing stagnates throughout the business integration system. In other words, if one part of the system stops operating, processing in the business integration system will stagnate, even if other devices are still operational.

[0008] Therefore, an object of the present invention is to continue processing, particularly pipeline processing, as the entire system in an integrated business system even when part of the system stops.

[0009] In order to solve the above problems, the present invention provides an integrated business system that has an upstream unit configuration and a downstream unit configuration and executes processing related to a specified business, where standby processing is performed in response to the occurrence of an event that affects the processing, and subsequent processing is continued in response to recovery from the event.

[0010] A more specific configuration of the present invention is a business integration system having an upstream unit configuration and a downstream unit configuration and executing processing related to a predetermined business, comprising: an instruction unit that notifies the downstream unit configuration of an execution instruction; a system state determination unit that detects the occurrence of an event that affects the processing related to the business in the business integration system and identifies the extent of impact of the event; and an operation execution unit that executes the processing related to the predetermined business, wherein the instruction unit notifies the extent of impact of the downstream unit configuration via a communication unit of a wait instruction to continue processing of the downstream unit configuration, and upon detecting that the event has been recovered from, cancels the wait instruction, and the operation execution unit obtains the result of related processing in the downstream unit configuration in response to the execution instruction and executes processing subsequent to the related processing, reflecting the result of the related processing. The present invention also includes a management method for a business integration system, and an upstream unit configuration and downstream unit that constitute the business integration system.

[0011] According to the present invention, even if a network failure or the like occurs in an integrated business system, the system as a whole can continue processing, particularly pipeline processing, and business in the system can be carried out more efficiently.

[0012] 1 is a time chart of processing in a business integration system according to a conventional technology and an embodiment of the present invention. FIG. 2 is a functional block diagram of a business integration system according to an embodiment of the present invention. FIG. 3 is a flowchart showing a processing flow of a management method for a business integration system according to an embodiment of the present invention. FIG. 4 is a functional block diagram of a business integration system according to Example 1. FIG. 5 is a diagram showing overall pipeline information 500 used in Example 1. FIG. 6 is a diagram showing pipeline information 501 used in Example 1. FIG. 7 is a flowchart showing a process of notifying a pipeline execution instruction from the common cloud 100 to the first cloud 300 according to Example 1. FIG. 8 is a flowchart showing a process of notifying a job execution instruction from the first cloud 300 to the first cloud job execution environment 303 according to Example 1. FIG. 9 is a flowchart showing a processing flow of executing a job in the first cloud job execution environment 303 according to Example 1. FIG. 10 is a flowchart showing a process of waiting / resuming (releasing waiting) in the common cloud 100 when a network failure occurs between the common cloud 100 and the first cloud 300 in Example 1. FIG. 11 is a flowchart showing a process of waiting / resuming (releasing waiting) in the first cloud 300 when a network failure occurs between the common cloud 100 and the first cloud 300 in Example 1. FIG. 12 is a functional block diagram of a business integration system according to Example 2. 1 is a flowchart showing a process standby / return (standby release) process in the first cloud 300 when a network failure occurs between the common cloud 100 and the first cloud 300 in Example 2. FIG. 2 is a functional block diagram of a business integrated system in Example 3. FIG. 3 is a flowchart showing a process standby / return (standby release) process in the first cloud 300 when a network failure occurs between the first cloud 300 and the first cloud job execution environment 303 in Example 3. FIG. 4 is a flowchart showing a process standby / return (standby release) process in the first cloud 300 when a network failure occurs between the first cloud 300 and the first cloud job execution environment 303 in Example 3.

[0013] An embodiment of the present invention will be described below. First, an overview of this embodiment will be described using FIG. 1. FIG. 1 shows a time chart of processing in a business integration system according to the prior art and this embodiment. The business integration system of FIG. 1 is composed of an upstream unit configuration 10 and a downstream unit configuration 30, which work together to execute processing for various business operations, such as pipeline processing. To this end, an execution instruction is sent from the upstream unit configuration 10 to the downstream unit configuration 30, and processing according to the execution instruction is executed in the downstream unit configuration 30. At this time, processing is also executed in the upstream unit configuration 10, and processing for the desired business operation is executed by reflecting the results of the processing in the downstream unit configuration 30. Furthermore, the upstream unit configuration 10 and the downstream unit configuration 30 can each be realized by a device represented by a single computer such as a server (cloud) or a PC, or by various systems composed of multiple devices.

[0014] As described above, the upstream unit configuration 10 notifies the downstream unit configuration 30 of instructions and accepts the results. The downstream unit configuration 30 executes various processes such as pipeline processing and jobs in response to instructions from the upstream unit configuration 10. Therefore, when the business integrated system develops software or the like as a business, the upstream unit configuration 10 can be called a pipeline management system. In this case, the downstream unit configuration 30 can be called a development pipeline execution device.

[0015] First, the upper part of Figure 1 shows a time chart of processing in a business integration system in the prior art. The upstream unit configuration 10 starts processing for a specific task. The upstream unit configuration 10 then issues an instruction to the downstream unit configuration 30 to execute the processing it is responsible for. If a system failure (e.g., a network failure) is detected while the downstream unit configuration 30 is executing processing in response to this execution instruction, the processing currently being executed by the upstream unit configuration 10 and the downstream unit configuration 30 is forcibly stopped (Failed). Then, once the system failure is resolved, the processing is restarted from the beginning. In other words, the upstream unit configuration 10 starts processing for the specific task again, and then issues an instruction to the downstream unit configuration 30 to execute the processing it is responsible for. As a result, the processing from the initial processing to the forced stop is wasted, and it takes a long time to complete the processing.

[0016] In contrast, the lower part of Figure 1 shows a time chart of the processing of the business integrated system in this embodiment. As with the prior art (upper part of Figure 1), processing for a specified task is initiated in the upstream unit configuration 10. The upstream unit configuration 10 then notifies the downstream unit configuration 30 of an instruction to execute the processing it is responsible for. Furthermore, while the downstream unit configuration 30 is executing processing in response to the execution instruction, a system failure (e.g., a network failure) is detected. Up to this point, it is the same as the prior art.

[0017] However, in this embodiment, when a system failure is detected, a standby process is performed until recovery from the failure is detected. Then, when recovery is detected, the downstream unit configuration 30 notifies the upstream unit configuration 10 of the processing result. In response to this, the upstream unit configuration 10 reflects the processing result and executes processing. As a result, in this embodiment, processing time can be shortened (by the amount indicated by the left and right arrows in the figure) compared to conventional technology.

[0018] Next, the configuration of this embodiment will be described. FIG. 2 is a functional block diagram of a business integration system according to this embodiment. The business integration system is used in so-called software and system development work. In FIG. 2, the business integration system includes an upstream unit configuration 10 and a downstream unit configuration 30 connected via a network 20. As described above, the upstream unit configuration 10 notifies the downstream unit configuration 30 of an execution instruction. In response to this, the downstream unit configuration 30 executes processing according to the execution instruction. As a result, the upstream unit configuration 10 and the downstream unit configuration 30 cooperate by executing the processing that they should each perform, thereby executing processing to realize the business.

[0019] For this purpose, the upstream unit configuration 10 has a communication unit 11, a system state determination unit 12, and a management unit 13. The communication unit 11 communicates with the downstream unit configuration 30 via a network 20. For example, the communication unit 11 notifies the downstream unit configuration 30 of an execution instruction, or the communication unit 11 receives a processing result from the downstream unit configuration 30.

[0020] The system status determination unit 12 determines the status of the integrated business system. The status indicates whether or not an event that affects the continuation of processing, such as a network failure or other system failure, has occurred. The management unit 13 has a function for managing processing in the integrated business system.

[0021] For this purpose, the management unit 13 has an instruction unit 131 and an operation execution unit 132. The instruction unit 131 creates and outputs various instructions for processing in the business integrated system. More preferably, the instruction unit 131 creates instructions according to the state of the business integrated system. These instructions include an execution instruction, a standby instruction, and a standby release instruction.

[0022] The calculation execution unit 132 also executes processing in the business integrated system. More specifically, the calculation execution unit 132 performs its own processing in the business integrated system, as well as identifies the extent of impact in the event of a failure or the like, and acquires the progress and processing results of processing in the downstream unit configuration 30.

[0023] Furthermore, the downstream unit configuration 30 executes processing in accordance with an execution instruction from the upstream unit configuration 10. To this end, the downstream unit configuration 30 includes a communication unit 31, a system state determination unit 32, and a management unit 33.

[0024] The communication unit 31 communicates with the upstream unit configuration 10 via the network 20. For example, the communication unit 31 receives an execution instruction, and the communication unit 31 notifies the upstream unit configuration 10 of a processing result.

[0025] Furthermore, the system status determination unit 32 determines the status of the business integrated system in the same manner as the system status determination unit 12. Note that the system status determination unit 32 can be omitted. The management unit 33 has a management function for processing in the business integrated system. For this purpose, the management unit 33 has an operation execution unit 331. The operation execution unit 331 executes processing in response to an execution instruction from the upstream unit configuration 10. This concludes the description of the configuration of this embodiment, and next, the processing flow will be described.

[0026] 3 is a flowchart showing the processing flow of the management method for a business integrated system according to this embodiment. The processing flow of FIG. 3 is premised on the fact that a user inputs a processing request for realizing a desired task to the upstream unit configuration 10 via a terminal device or input device. The processing request may also be received based on a source other than input from the user. For example, the upstream unit configuration 10 itself may identify the processing request based on a schedule or the like.

[0027] In response to the above input, in step S11, the instruction unit 131 of the upstream unit configuration 10 creates an execution instruction corresponding to the processing request. Then, the instruction unit 131 notifies the downstream unit configuration 30 of the execution instruction using the communication unit 11.

[0028] In step S31, the communication unit 31 of the downstream unit configuration 30 receives an execution instruction. In step S32, the calculation execution unit 331 starts executing processing in accordance with the execution instruction. Hereinafter, the processing in the downstream unit configuration 30 is referred to as related processing. The related processing includes pipeline processing and job execution linked with downstream unit configurations further downstream, and management processing for jobs, etc.

[0029] In step S12, the system status determination unit 12 determines the status of the process execution in the business integrated system. For example, it determines whether a network failure has occurred. This step is executed periodically or continuously. If the result of step S12 is that a failure has been detected, that is, an event that affects the execution of the process has occurred (Yes), the process proceeds to step S13. If the result of step S12 is that no failure has been detected, that is, an event that affects the execution of the process has not occurred (No), the process continues to execute step S12.

[0030] Furthermore, in step S13, the calculation execution unit 132 identifies the scope of impact due to the occurrence of an event such as a failure. For example, if the event in question is a failure in the network 20, the upstream unit configuration 10 and downstream unit configuration 30 connected thereto are identified as being within the scope of impact. Note that in this embodiment, only the upstream unit configuration 10 and the downstream unit configuration 30 are shown, but if the upstream unit configuration 10 is connected to a network other than the network 20 or to another unit configuration, this will be outside the scope of impact. Also, if the upstream unit configuration 10 is composed of multiple devices, these will also be outside the scope of impact. Furthermore, if another unit configuration is connected to the network 20, this unit configuration will be identified as being within the scope of impact.

[0031] Furthermore, in step S14, the instruction unit 131 executes standby processing for the identified affected range. The instruction unit 131 creates a standby instruction for the affected range and puts processing in the affected range into a standby state. In this embodiment, the instruction unit 131 manages and stores the processing in the upstream unit configuration 10 and the downstream unit configuration 30 as being on standby. Note that the standby instruction is an instruction to continue processing in the downstream unit configuration 30 and the upstream unit configuration 10.

[0032] In step S15, the system state determination unit 12 determines whether the failure (event) detected in step S12 has been restored. If the failure (event) has been restored (Yes), the process proceeds to step S16. If the failure (event) has not been restored (No), the process repeats the determination of whether the failure has been restored (step S15). This step is executed periodically or continuously.

[0033] Furthermore, in step S16, the management unit 13 cancels the standby process performed in step S14. This cancellation includes the instruction unit 131 creating and outputting an instruction to cancel the standby of the upstream unit configuration 10 itself, as well as the operation execution unit 132 obtaining the related processing results from the downstream unit configuration 30. As a result, the operation execution unit 132 obtains the related processing results from the downstream unit configuration 30 using the communication unit 11 as follows.

[0034] First, the operation execution unit 132 notifies the downstream unit configuration 30 of an acquisition request using the communication unit 11. Then, in step S33, the communication unit 31 of the downstream unit configuration 30 accepts the acquisition request. Then, the operation execution unit 331 notifies the upstream unit configuration 10 of the related processing results that it has executed after step S32 using the communication unit 31. In response to this, in step S17, the operation execution unit 132 acquires the related processing results via the communication unit 11.

[0035] Then, in step S18, the calculation execution unit 132 executes and completes processing to realize the business, reflecting the acquired related processing results. That is, processing after the related processing is executed based on the acquired related processing results. Here, in step S18, the calculation execution unit 132 may execute on the condition that the related processing in the downstream unit configuration 30 is successful. Furthermore, in step S18, the configuration may be such that it is acquired that the related processing in the downstream unit configuration 30 has failed. The same applies to each of the following embodiments.

[0036] As a result, the processing time can be reduced as shown in Fig. 1. This completes the description of this embodiment, and next, a specific example of this embodiment will be described.

[0037] The first embodiment is directed to a business integrated system having, as unit configurations, a common cloud 100, a first cloud 300, a first cloud job execution environment 303, a second cloud 400, and a second cloud job execution environment 403. Furthermore, in the first embodiment, pipeline processing is executed as processing, and a network failure is taken as an example of an event that has an impact. Figure 4 is a functional block diagram of the business integrated system in the first embodiment.

[0038] 4, the common cloud 100 can be realized as a so-called server, and notifies the first cloud 300 and the second cloud 400 of execution instructions. Therefore, the common cloud 100 corresponds to an upstream unit configuration 10 for the first cloud 300 and the second cloud 400. The common cloud 100 has a network status determination unit 101 and an overall pipeline management unit 102. Note that each unit configuration, including the common cloud 100, has a communication unit, but since this is the same as each communication unit in the embodiments, a description thereof will be omitted.

[0039] Furthermore, the common cloud 100 is connected to the first cloud 300 and the second cloud 400 via networks 200 and 202, respectively, and communicates with each other. Note that these networks 200 and 202, as well as networks 201 and 203 described below, correspond to the network 20 in Fig. 2. The network status determination unit 101 checks the communication status of the networks 200 and 202 to which the common cloud 100 is connected, and checks whether communication with the first cloud 300 and the second cloud 400 is possible, i.e., detects the occurrence of a network failure.

[0040] The overall pipeline management unit 102 also manages overall pipeline information 500 to be executed in the first cloud 300 and the second cloud 400. In other words, it corresponds to the management unit 13 in FIG. 2 . Specifically, the overall pipeline management unit 102 issues pipeline execution instructions to the first cloud 300 and the second cloud 400, respectively, via the network 200 and the network 202, monitors the execution progress, and obtains the execution results. Furthermore, if there are files necessary for starting the pipeline, the overall pipeline management unit 102 can transmit them using the communication unit when notifying the pipeline execution instruction or at another time. The common cloud 100 can be provided with a storage unit (not shown) to store the overall pipeline information 500.

[0041] Furthermore, network 200 is a network that connects common cloud 100 and first cloud 300. Then, first cloud 300 receives execution instructions from common cloud 100 via network 200 and executes related processing in response to the instructions. In other words, first cloud 300 corresponds to a downstream unit configuration with respect to common cloud 100, and can be referred to as a first downstream unit configuration. Therefore, first cloud 300 has a network status determination unit 301 and a pipeline management unit 302. Then, first cloud 300 is connected to common cloud 100 and first cloud job execution environment 303 via network 200 and network 201, respectively, and communicates with them.

[0042] Furthermore, the network status determination unit 301 checks the communication status of networks connected to the first cloud 300, such as the network 200 and the network 201, and detects the occurrence of a network failure. More specifically, the network status determination unit 301 checks whether communication with the common cloud 100 and the first cloud job execution environment 303 is possible.

[0043] The pipeline management unit 302 also manages job information to be executed in the first cloud job execution environment 303. The pipeline management unit 302 then issues job execution instructions, monitors the execution progress, and acquires the execution results to the first cloud job execution environment 303 via the network 201. These job execution instructions, execution progress monitoring, and acquisition of execution results are performed based on pipeline information 501 that has received an execution instruction from the overall pipeline management unit 102. The first cloud 300 can be provided with a storage unit (not shown) to store the pipeline information 501.

[0044] Furthermore, the pipeline management unit 302 transmits the acquired progress status to the overall pipeline management unit 102 during pipeline execution. Furthermore, after the pipeline execution is completed, the pipeline management unit 302 transmits the execution result to the overall pipeline management unit 102. Each of these processes corresponds to the related processes of the embodiment, and the pipeline management unit 302 corresponds to the management unit 33 in FIG. 2. As a result, the first cloud 300 corresponds to a downstream unit configuration with respect to the common cloud 100, but corresponds to an upstream unit configuration of the first cloud job execution environment 303.

[0045] The first cloud job execution environment 303 also has a network status determination unit 304 and a job execution unit 305. The first cloud job execution environment 303 is also connected to the first cloud 300 via the network 201, and communicates with the first cloud 300. The network status determination unit 304 also checks the communication status of the network 201 to determine whether communication with the first cloud 300 is possible, that is, detects the occurrence of a network failure. Therefore, the network status determination unit 304 corresponds to the system status determination unit 32 in FIG. 2 .

[0046] Furthermore, the job execution unit 305 executes the processing of a job for which it has received an execution instruction from the pipeline management unit 302 as a related process. After completing the job processing, the job execution unit 305 sends the execution result to the pipeline management unit 302. Therefore, the job execution unit 305 corresponds to the management unit 33, particularly the calculation execution unit 331, in FIG. 2. As described above, the first cloud job execution environment 303 corresponds to the downstream unit configuration of the embodiment and can be referred to as a second downstream unit configuration. Furthermore, the network 201 is a network that connects the first cloud 300 and the first cloud job execution environment 303 and corresponds to the network 20 in FIG. 2.

[0047] Next, the second cloud 400, like the first cloud 300, receives execution instructions from the common cloud 100 via the network 202 and executes related processing in response to the instructions. In other words, the second cloud 400 corresponds to a downstream unit configuration relative to the common cloud 100, and can be referred to as a first downstream unit configuration. For this reason, the second cloud 400 has a network status determination unit 401 and a pipeline management unit 402. The second cloud 400 is connected to the common cloud 100 and the second cloud job execution environment 403 via the network 200 and the network 202, respectively, and communicates with them.

[0048] Similarly to the network status determination unit 301, the network status determination unit 401 checks the communication status of networks connected to the second cloud 400, such as the network 202 and the network 203, and detects the occurrence of a network failure. More specifically, the network status determination unit 401 checks whether communication with the common cloud 100 and the second cloud job execution environment 403 is possible.

[0049] Similarly to the pipeline management unit 302, the pipeline management unit 402 manages job information to be executed in the second cloud job execution environment 403. The pipeline management unit 402 issues job execution instructions, monitors execution progress, and acquires execution results to the second cloud job execution environment 403 via the network 203. These job execution instructions, execution progress monitoring, and acquisition of execution results are performed based on pipeline information 502 for which execution instructions have been received from the overall pipeline management unit 102. The second cloud 400 may be provided with a storage unit (not shown) to store the pipeline information 502.

[0050] Similarly to the pipeline management unit 302, the pipeline management unit 402 transmits a progress status to the overall pipeline management unit 102 during pipeline execution. Furthermore, after the pipeline execution is completed, the pipeline management unit 402 transmits the execution result to the overall pipeline management unit 102. Each of these processes corresponds to the related processes of the embodiment, and the pipeline management unit 402 corresponds to the management unit 33 in FIG. 2. As a result, the second cloud 400 also corresponds to a downstream unit configuration with respect to the common cloud 100, but corresponds to an upstream unit configuration of the second cloud job execution environment 403.

[0051] The second cloud job execution environment 403 also has a network status determination unit 404 and a job execution unit 405. Similar to the first cloud job execution environment 303, the second cloud job execution environment 403 is connected to the second cloud 400 via the network 203 and communicates with it. The network status determination unit 404 checks the communication status of the network 203 to determine whether communication with the second cloud 400 is possible, that is, detects the occurrence of a network failure. Therefore, the network status determination unit 404 also corresponds to the system status determination unit 32 in FIG. 2 .

[0052] Similarly to the job execution unit 305, the job execution unit 405 executes the processing of a job instructed to be executed by the pipeline management unit 402 as a related process. After completing the job processing, the job execution unit 405 transmits the execution result to the pipeline management unit 402. Therefore, the job execution unit 405 also corresponds to the management unit 33, particularly the calculation execution unit 331, in FIG. 2. As described above, the second cloud job execution environment 403 also corresponds to the downstream unit configuration of the embodiment and can be referred to as the second downstream unit configuration. The network 203 is a network that connects the second cloud 400 and the second cloud job execution environment 403, and corresponds to the network 20 in FIG. 2.

[0053] Note that downstream unit configurations such as clouds connected to the common cloud 100 are not limited to the first cloud 300 and the second cloud 400; multiple clouds may be connected in a similar manner, or only a single cloud may be connected. Furthermore, the job execution environment for each downstream unit configuration such as each cloud may be connected in a similar manner, or multiple job execution environments may be connected in a similar manner. The configuration of the above-described first embodiment is an example in which upstream unit configurations and downstream unit configurations are configured in multiple layers. The number of layers is not limited to the three layers illustrated, and may be more than one. Furthermore, each layer may be configured to have multiple layers (unit configurations) connected.

[0054] Next, the overall pipeline information 500 and the pipeline information 50x, which are information used in the first embodiment, will be described. FIG. 5A is a diagram showing the overall pipeline information 500 used in the first embodiment. The overall pipeline information 500 is information that the overall pipeline management unit 102 uses to execute related processes in the first cloud 300 and the second cloud 400. Therefore, the overall pipeline information 500 includes pipeline information and pipeline information 502 for each of the first cloud 300 and the second cloud 400 (see FIG. 1). These pieces of pipeline information can be collectively referred to as pipeline information 50x. The overall pipeline information 500 indicates the execution order and combination of the pipeline information 50x for each cloud (downstream unit configuration) connected to the common cloud 100. Note that while FIG. 5A shows two pieces of pipeline information 50x, the number varies depending on the unit configuration, such as the clouds connected to the common cloud 100.

[0055] Next, the pipeline information 50x will be described. Fig. 5B is a diagram showing the pipeline information used in the first embodiment. Note that Fig. 5B shows the pipeline information as a representative of the pipeline information 50x, but the pipeline information 502 has a similar configuration.

[0056] The pipeline information is pipeline information for related processes in the first cloud 300, and includes first cloud job information 1 (601) to first cloud job information M (60M). These indicate the execution order and combination of jobs to be executed in the first cloud job execution environment 303, and each of first cloud job information 1 (601) to first cloud job information M (60M) is information on the jobs to be executed in the first cloud job execution environment 303. This concludes the explanation of the information used in the first embodiment, and next, the processing flow of the first embodiment will be explained. Note that first cloud job information 1 (601) to first cloud job information M (60M) will also be simply referred to as first cloud job information 601 below.

[0057] 6A is a flowchart showing a process of notifying a pipeline execution instruction from the common cloud 100 to the first cloud 300 in the first embodiment. Note that, similar to FIG. 3, this flowchart also assumes that the common cloud 100 has accepted a processing request.

[0058] First, in step S900, the overall pipeline management unit 102 notifies the first cloud of an instruction to execute the pipeline. Then, in step S901, the overall pipeline management unit 102 transmits overall pipeline information 500 to the pipeline management unit 302. At this time, the overall pipeline management unit 102 may notify only the pipeline information corresponding to the first cloud 300.

[0059] In step S902, the overall pipeline management unit 102 issues an execution instruction for the pipeline information to the pipeline management unit 302 to execute pipeline processing, which is an example of related processing, in the first cloud 300. In step S903, the overall pipeline management unit 102 transmits files necessary for executing the pipeline information. Step S903 may be executed in step S902.

[0060] Furthermore, in step S904, the overall pipeline management unit 102 monitors the progress of the pipeline processing for the pipeline information for which execution has been instructed. This is preferably performed continuously, and can be achieved, for example, by the overall pipeline management unit 102 notifying the first cloud 300 of a confirmation notification. Furthermore, in step S905, the overall pipeline management unit 102 determines whether the pipeline processing for the pipeline information has been completed. As a result, if it has been completed (Yes), the process proceeds to step S906. If it has not been completed (No), the process proceeds to step S904, where the progress of the pipeline processing for the pipeline information is monitored until execution is completed.

[0061] Then, in step S906, the overall pipeline management unit 102 receives the execution result of the pipeline processing from the pipeline management unit 302. This completes the description of FIG. 6A.

[0062] 6B is a flowchart showing a process of notifying a job execution instruction from the first cloud 300 to the first cloud job execution environment 303 in Example 1. First, in step S907, the pipeline management unit 302 starts a process of notifying the first cloud job execution environment 303 of a job execution instruction.

[0063] Furthermore, in step S908, the pipeline management unit 302 receives the overall pipeline information 500 from the overall pipeline management unit 102. Furthermore, in step S909, the pipeline management unit 302 receives the pipeline information from the overall pipeline management unit 102. Steps S908 and S909 may be executed together.

[0064] In step S910, the pipeline management unit 302 receives a file required for executing pipeline processing of the pipeline information from the overall pipeline management unit 102. This step S910 may be executed together with step S908 or step S909.

[0065] In step S911, the pipeline management unit 302 acquires first cloud job information 601 from the pipeline information. Then, in step S912, the pipeline management unit 302 sequentially notifies the first cloud job execution environment 303 of execution instructions for the first cloud job information 601 in the execution order indicated by the pipeline information. In other words, after the execution of one piece of first cloud job information 601 is completed, the pipeline management unit 302 notifies the execution instruction for the job corresponding to the next job information 602. Note that this notification method is just an example, and multiple pieces of job information may be notified at once, or the next job information may be notified before the execution of the job of the previous job information is completed.

[0066] In step S913, the pipeline management unit 302 transmits files necessary for executing the first cloud job information 601 to the first cloud job execution environment 303. In step S914, the pipeline management unit 302 monitors the progress of the job for the first cloud job information 601. For example, the pipeline management unit 302 notifies the first cloud job execution environment 303 of a confirmation notification to monitor the progress.

[0067] In step S915, the pipeline management unit 302 calculates the progress of the pipeline processing of the pipeline information from the progress of the job in the first cloud job information 601 that it is monitoring. Then, the pipeline management unit 302 transmits the calculated progress to the overall pipeline management unit 102. In step S916, the pipeline management unit 302 determines whether the execution of the job in each of the first cloud job information 601 included in the pipeline information has been completed. As a result, if the execution is completed (Yes), the process proceeds to step S917. If the execution is not completed (No), the process returns to step S914. Therefore, the processes of steps S914 and S915 are repeated until the execution of the pipeline processing of the pipeline information is completed.

[0068] In step S917, the pipeline management unit 302 transmits the execution result of the pipeline processing of the pipeline information to the overall pipeline management unit 102. This concludes the description of FIG. 6B.

[0069] 6C is a flowchart showing a processing flow for executing a job in the first cloud job execution environment 303 in Example 1. First, in step S918, the job execution unit 305 starts executing a job according to the first cloud job information 601. Then, in step S919, the job execution unit 305 receives an execution instruction for the job in the first cloud job information 601 from the pipeline management unit 302. That is, the job execution unit 305 receives an execution instruction similar to the execution instruction received by the pipeline management unit 302 in step S912.

[0070] In step S920, the job execution unit 305 receives, from the pipeline management unit 302, a file required to execute the job of the first cloud job information 601. That is, the job execution unit 305 receives the file received by the pipeline management unit 302 in step S913.

[0071] In step S921, the job execution unit 305 starts processing the job in accordance with the first cloud job information 601. Then, in step S922, the job execution unit 305 transmits the progress status of the job in the first cloud job information 601 to the pipeline management unit 302. As a result, step S914 can be executed.

[0072] In step S923, the job execution unit 305 determines whether execution of the job of the first cloud job information 601 has been completed. If the job has been completed (Yes), the process proceeds to step S924. If the job has not been completed (No), the process returns to step S922. As a result, the process of step S922 is repeated until the job is completed.

[0073] In step S924, the job execution unit 305 transmits the execution result of the job in the first cloud job information 601 to the pipeline management unit 302. As a result, the determination in step S916 can be made.

[0074] Next, FIG. 6D is a flowchart showing standby / recovery (standby release) processing of processing in the shared cloud 100 in the first embodiment when a network failure occurs between the shared cloud 100 and the first cloud 300.

[0075] In step S1000, a standby / recovery (standby release) process is started when a network failure occurs in the network 200 between the common cloud 100 and the first cloud 300. To this end, in step S1000, the network status determination unit 101 periodically (for example, periodically) checks the communication status of the network 200. A known method can be used to check the network communication status.

[0076] In step S1001, the network status determination unit 101 determines whether a communication failure has occurred in the network 200. As a result, if a failure has occurred (Yes), the process proceeds to step S1002. If a failure has not occurred (No), the process proceeds to step S1004.

[0077] In step S1002, the overall pipeline management unit 102 determines whether pipeline processing related to the first cloud 300 is currently running when a communication failure occurs in the network 200. If the result shows that the pipeline processing is currently running (Yes), the process proceeds to step S1003. If the pipeline processing is not currently running (No), the process of this flowchart ends.

[0078] Also, in step S1003, the overall pipeline management unit 102 waits for progress monitoring (step S904) of the pipeline processing of the first cloud 300. That is, the overall pipeline management unit 102 maintains the pipeline processing so that it is not forcibly stopped (Failed).

[0079] In step S1004, the overall pipeline management unit 102 determines whether progress monitoring of the pipeline processing of the first cloud 300 is on standby. If the result shows that progress monitoring is on standby (Yes), the process proceeds to step S1005. If the result shows that progress monitoring is not on standby (No), the process of this flowchart ends.

[0080] In step S1005, the overall pipeline manager 102 releases the standby process for monitoring the progress of the pipeline processing of the first cloud 300. As a result, the common cloud 100 becomes able to obtain the processing results of the pipeline processing of the first cloud 300.

[0081] 6E is a flowchart showing a standby / return (standby release) process for processing in the first cloud 300 in the event of a network failure between the common cloud 100 and the first cloud 300 in the first embodiment. First, in step S2000, a standby / return (standby release) process for processing in the event of a network failure in the network 200 between the common cloud 100 and the first cloud 300 is started. For this purpose, the network status determination unit 301 periodically (for example, periodically) checks the communication status of the network 200. A known method can be used to check the network communication status.

[0082] In step S2001, the network status determination unit 301 determines whether a communication failure has occurred in the network 200. As a result, if a failure has occurred (Yes), the process proceeds to step S2002. If a failure has not occurred (No), the process proceeds to step S2005.

[0083] In step S2002, the network status determination unit 301 determines whether pipeline processing related to the first cloud 300 is currently running when a communication failure occurs in the network 200. If the pipeline processing is currently running (Yes), the process proceeds to step S2003. If the pipeline processing is not currently running (No), the process of this flowchart ends.

[0084] Also, in step S2003, if a pipeline in the first cloud 300 is running when a communication failure occurs in the network 200, the pipeline management unit 302 temporarily suspends transmission of progress information from itself to the overall pipeline management unit 102 (step S915).

[0085] In step S2004, the pipeline management unit 302 waits for the transmission of the execution results of the pipeline processing in the first cloud 300 to the overall pipeline management unit 102 (step S917). In step S2005, the pipeline management unit 302 determines whether the transmission of the execution results of the pipeline processing in the first cloud 300 is temporarily stopped. As a result, if it is temporarily stopped (Yes), the process proceeds to step S2006. If it is not temporarily stopped (No), the process proceeds to step S2007.

[0086] In step S2006, the pipeline management unit 302 releases the temporary suspension of the transmission of progress status to the overall pipeline management unit 102 and resumes the transmission of progress status. In step S2007, the pipeline management unit 302 determines whether it is waiting to transmit the execution result to the overall pipeline management unit 102. If it is waiting (Yes), the process proceeds to step S2008. If it is not waiting (No), the process ends this flowchart.

[0087] Then, in step S2008, the pipeline management unit 302 cancels the wait for transmission of the execution result to the overall pipeline management unit 102. As a result of the above (particularly, FIGS. 6D and 6E ), in the first embodiment, when the network failure is recovered, the pipeline processing and job processing results in each unit configuration can be reflected, making it possible to avoid restarting each process from scratch and enabling efficient execution of the processes. Note that the first cloud 300 in the first embodiment can also be used for processing any cloud connected to the common cloud 100, and can also be realized similarly for the second cloud 400 and the second cloud job execution environment 403 connected thereto.

[0088] The second embodiment is an embodiment in which pipeline processing continues even when a network failure occurs between the common cloud 100 and the Xth cloud (such as the first cloud 300 or the second cloud 400). In the first embodiment, when executing a pipeline in the Yth cloud (such as the first cloud 300 or the second cloud 400) after the pipeline execution in the Xth cloud is completed, it is necessary to wait for recovery from the network failure between the common cloud 100 and the Xth cloud.

[0089] In contrast, in the second embodiment, processing can be continued without waiting for recovery from the network failure by transmitting the files required for pipeline execution via the network connecting cloud X and cloud Y. In other words, processing continuity can be improved.

[0090] For this reason, in the second embodiment, a network between the Xth cloud and the Yth cloud is used. The configuration for this purpose is shown in FIG. 7. FIG. 7 is a functional block diagram of a business integration system in the second embodiment. Compared to the configuration of the business integration system in FIG. 7 in the first embodiment (FIG. 4), a network 204 is added. The network 204 connects the first cloud 300 and the second cloud 400, which are examples of the Xth cloud and the Yth cloud. The other configurations are the same as in the first embodiment, and therefore a description thereof will be omitted. Furthermore, in the second embodiment, the overall pipeline information 500 and the pipeline information 50x are used, as in the first embodiment. Therefore, a description thereof will also be omitted.

[0091] Next, the processing flow of the second embodiment will be described. In the second embodiment, as in the first embodiment, the processing flow shown in the flowcharts of FIGS. 6A to 6D is executed. However, in the second embodiment, the standby / return (standby release) processing of processing in the first cloud 300 when a network failure occurs between the common cloud 100 and the first cloud 300 is different from that in the first embodiment (FIG. 6E). Therefore, this processing will be described in the first embodiment. FIG. 8 is a flowchart showing the standby / return (standby release) processing of processing in the first cloud 300 when a network failure occurs between the common cloud 100 and the first cloud 300 in the second embodiment.

[0092] 8, steps S2000 to S2008 are processed in the same manner as in the first embodiment (FIG. 6E), and therefore a description thereof will be omitted. Steps S2009 and onward that differ from the first embodiment will be described below.

[0093] First, in step S2009, the network status determination unit 301 determines whether the pipeline in the first cloud has completed execution and is currently in standby mode when a network failure occurs. If the pipeline is currently in standby mode (Yes), the process proceeds to step S2010. If the pipeline is not currently in standby mode (No), the process ends.

[0094] In step S2010, the network state determination unit 301 acquires other pipeline information other than the pipeline information 501 of the first cloud 300 from the overall pipeline information 500. In step S2011, the network state determination unit 301 determines whether the second cloud 400 has pipeline information of a pipeline process subsequent to the pipeline process of the acquired other pipeline information. As a result, if there is such pipeline information (Yes), the process proceeds to step S2012. If there is not such pipeline information (No), the process ends this flowchart.

[0095] In step S2012, the network status determination unit 301 transmits the entire pipeline information 500, an execution instruction for the pipeline information 501, and files necessary for the pipeline processing of the pipeline information 501 to the pipeline management unit 402 of the second cloud 400. In response to this, the pipeline management unit 402 starts pipeline processing in a manner similar to that shown in the flowchart in Fig. 6A. Note that in step S2012, the entire pipeline information 500, the execution instruction for the pipeline information 501, and files necessary for the pipeline processing of the pipeline information 501 may be transmitted separately.

[0096] In the second embodiment described above, the first cloud 300 and the second cloud 400 are used, but the second embodiment can be applied to any cloud connected to the common cloud 100 .

[0097] Next, a third embodiment is an example in which the first cloud 300 is an upstream unit configuration and the first cloud job execution environment 303 is a downstream unit configuration. That is, the third embodiment is an example in which job processing continues even in the event of a network failure between the first cloud 300 and the first cloud job execution environment 303. Note that the third embodiment can also be applied to other clouds and cloud job execution environments, such as the second cloud 400 and the second cloud job execution environment 403.

[0098] First, the configuration of the third embodiment will be described. Fig. 9 is a functional block diagram of a business integrated system in the third embodiment. Fig. 9 shows a configuration in which the first cloud 300, the first cloud job execution environment 303, and the network 201 are extracted from the configuration of the business integrated system in the first embodiment (Fig. 4). Each of these components has already been explained, so a description thereof will be omitted. Furthermore, the information used in the third embodiment is also common to the first and second embodiments, so a description thereof will also be omitted.

[0099] Next, a processing flow of the third embodiment will be described. Fig. 10A is a flowchart showing a standby / recovery (standby release) process of processing in the first cloud 300 when a network failure occurs between the first cloud 300 and the first cloud job execution environment 303 in the first cloud 300 according to the third embodiment. That is, Fig. 10A corresponds to Fig. 6D of the first embodiment. Each step in Fig. 10A will be described below.

[0100] First, in step S3000, the network status determination unit 301 starts a standby / recovery (standby release) process for processing in the event of a network failure in the network 201 between the first cloud 300 and the first cloud job execution environment 303. For this purpose, in step S3000, the network status determination unit 301 periodically (for example, periodically) checks the communication status of the network 201. A known method can be used to check the network communication status.

[0101] In step S3001, the network status determination unit 301 determines whether a communication failure has occurred in the network 201. As a result, if a failure has occurred (Yes), the process proceeds to step S3002. If a failure has not occurred (No), the process proceeds to step S3004.

[0102] In step S3002, the pipeline management unit 302 determines whether a job is being executed in the first cloud job execution environment 303 when a communication failure occurs in the network 201. If the job is being executed (Yes), the process proceeds to step S3003. If the job is not being executed (No), the process of this flowchart ends.

[0103] In step S3003, the pipeline management unit 302 waits for progress monitoring (step S914) of the job in the first cloud job execution environment 303. That is, the pipeline management unit 302 maintains the job so that it is not forcibly stopped (Failed).

[0104] In step S3004, the pipeline management unit 302 determines whether job progress monitoring in the first cloud job execution environment 303 is on standby. If the result shows that the job is on standby (Yes), the process proceeds to step S3005. If the job is not on standby (No), the process of this flowchart ends.

[0105] In step S3005, the pipeline management unit 302 releases the standby process for monitoring the progress of the job in the first cloud job execution environment 303. As a result, the first cloud 300 becomes able to obtain the processing result of the job in the first cloud job execution environment 303.

[0106] Next, Fig. 10B is a flowchart showing a standby / recovery (standby release) process of processing in the first cloud 300 when a network failure occurs between the first cloud 300 and the first cloud job execution environment 303 in the first cloud 300 according to the third embodiment. That is, Fig. 10B corresponds to Fig. 6E in the first embodiment. Each step in Fig. 10B will be described below.

[0107] First, in step S4000, a process for waiting / recovering (releasing waiting) processing is started when a network failure occurs in the network 201 between the first cloud 300 and the first cloud job execution environment 303. For this purpose, the network status determination unit 304 periodically (for example, periodically) checks the communication status of the network 201. A known method can be used to check the network communication status.

[0108] In step S4001, the network status determination unit 304 determines whether a communication failure has occurred in the network 201. As a result, if a failure has occurred (Yes), the process proceeds to step S4002. If a failure has not occurred (No), the process proceeds to step S4005.

[0109] In step S4002, the network status determination unit 304 determines whether a job is currently running in the first cloud job execution environment 303 when a communication failure occurs in the network 201. If the job is currently running (Yes), the process proceeds to step S4003. If the job is not currently running (No), the process of this flowchart ends.

[0110] Also, in step S4003, if a job in the first cloud job execution environment 303 is being executed when a communication failure occurs on the network 201, the job execution unit 305 temporarily suspends sending of progress information from itself to the pipeline management unit 302 (step S922).

[0111] In step S4004, the job execution unit 305 waits for transmission of the job execution results in the first cloud job execution environment 303 to the pipeline management unit 302 (step S924). In step S4005, the job execution unit 305 determines whether transmission of the job execution results in the first cloud job execution environment 303 is paused. As a result, if it is paused (Yes), the process proceeds to step S4006. If it is not paused (No), the process proceeds to step S4007.

[0112] In step S4006, the job executing unit 305 releases the temporary suspension of the transmission of the progress status to the pipeline managing unit 302 and resumes the transmission of the progress status. In step S4007, the job executing unit 305 determines whether it is waiting to transmit the execution result to the pipeline managing unit 302. If it is waiting (Yes), the process proceeds to step S4008. If it is not waiting (No), the process ends this flowchart.

[0113] Then, in step S4008, the job execution unit 305 cancels the wait for transmission of the execution result to the pipeline management unit 302. As a result, in the third embodiment, when the network failure is recovered, the job processing result can be reflected, and it is possible to avoid restarting each process from the beginning, thereby enabling efficient execution of the process. Note that the first cloud 300 and the first cloud job execution environment 303 in the third embodiment are merely examples, and can also be applied to configurations other than those shown in FIG. 9. For example, a plurality of cloud job execution environments can be connected to the first cloud 300, and the third embodiment can be applied to these.

[0114] Although the description of the embodiment and examples has been completed, the present invention is not limited to these. For example, the following aspects in which the present invention is applied to development work are also included in the present invention.

[0115] (1) A pipeline management system on the cloud connected to a software development pipeline execution device via a network, in which if an abnormality occurs in network communication after issuing a pipeline execution processing instruction to the development pipeline execution device, the system will wait until network communication is restored, and after network communication is restored, the system will check the status of the development pipeline execution device, reflect the execution results of the pipeline processing by the development pipeline execution device, and move on to the next pipeline processing.

[0116] (2) After the recovery in (1), the state of the development pipeline execution device is checked, and if the check result indicates that the pipeline processing of the development pipeline execution device has been successful, the pipeline processing is continued.

[0117] (3) In (1) or (2), after recovery, the state of the development pipeline execution device is checked, and if the check result indicates that the pipeline processing of the development pipeline execution device has failed, information about the failure is obtained.

[0118] (4) The software development pipeline execution device includes a first development pipeline execution device and a second development pipeline execution device, the first development pipeline execution device and the second development pipeline execution device are capable of communicating with each other via a network, and the pipeline processing of the second development pipeline execution device uses the results of the pipeline processing of the first development pipeline execution device, and if an abnormality occurs in the network communication between the first development pipeline execution device and a pipeline management system on the cloud, the first development pipeline execution device transmits the results of the pipeline processing to the second development pipeline execution device, and the second development pipeline execution device executes the pipeline processing using the results of the first development pipeline execution device.

[0119] (5) In (4), when network communication between the first development pipeline execution device and the pipeline management system on the cloud is restored, the pipeline management system obtains information about the status of pipeline processing from the first development pipeline execution device.

[0120] (6) A pipeline management system connected to a software development processing execution device via a network, in which if an abnormality occurs in network communication after issuing a pipeline execution processing instruction to the development processing execution device, the system will wait until network communication is restored, and after network communication is restored, the system will check the status of the development processing execution device, reflect the execution results of the pipeline processing by the development processing execution device, and proceed to the next pipeline processing.

[0121] (7) After the recovery in (6), the state of the development process execution device is checked, and if the check result shows that the pipeline processing of the development process execution device has been successful, the pipeline processing is continued.

[0122] (8) In (6) or (7), after recovery, the state of the development process execution device is checked, and if the check result indicates that the pipeline processing of the development process execution device has failed, information about the failure is obtained.

[0123] Furthermore, the present invention can be applied to various operations other than development, such as accounting processing, sales operations, etc. Furthermore, the unit configuration is not limited to the configurations of the above-described embodiments and examples, and the number of units is not limited to those exemplified.

[0124] 10...upstream unit configuration, 11...communication unit, 12...system state determination unit, 13...management unit, 131...instruction unit, 132...operation execution unit, 20...network, 30...downstream unit configuration, 31...communication unit, 32...system state determination unit, 33...management unit, 331...operation execution unit, 100...common cloud, 101...network state determination unit, 102...overall pipeline management unit, 200-204...network, 300...first cloud, 301...network state determination unit, 302...pipeline management unit, 303...first cloud job execution environment, 304...network state determination unit, 305...job execution unit, 400...second cloud, 401...network state determination unit, 402...pipeline management unit, 403...second cloud job execution environment, 404...network state determination unit, 405...job execution unit, 500...overall pipeline information, 501, 502...pipeline information

Claims

1. A business integration system having an upstream unit configuration and a downstream unit configuration, and executing processing related to a specified business, comprising: an instruction unit that notifies execution instructions to the downstream unit configuration; a system status judgment unit that detects the occurrence of an event that affects processing related to the specified business in the business integration system and identifies the scope of impact of the event; and an operation execution unit that executes processing related to the specified business, wherein the instruction unit notifies the scope of impact of a wait instruction to continue processing of the downstream unit configuration via a communication unit, and when it detects that the event has been recovered from, it cancels the wait instruction, and the operation execution unit obtains the results of related processing in the downstream unit configuration in accordance with the execution instruction, and executes processing subsequent to the related processing, reflecting the results of the related processing.

2. A business integrated system according to claim 1, wherein the event is a network failure in a network connecting the upstream unit configuration and the downstream unit configuration.

3. A business integrated system as claimed in claim 1, wherein the business is software development work, the downstream unit configuration is a development pipeline execution device that executes pipeline processing in the development of the software, the upstream unit configuration is a pipeline management system connected to the downstream unit configuration via a network, and the calculation execution unit reflects the results of pipeline processing executed by the development pipeline execution device and moves on to the next pipeline processing of the pipeline processing.

4. A business-use integrated system according to claim 3, wherein the operation execution unit executes the next pipeline processing of the pipeline processing in the development pipeline execution device when the pipeline processing in the development pipeline execution device is successful.

5. An integrated business system according to claim 3, wherein the operation execution unit acquires information indicating that pipeline processing in the development pipeline execution device has failed.

6. In the business integrated system according to any one of claims 1 to 5, the downstream unit configurations are a first downstream unit configuration connected to the upstream unit configuration and a second downstream unit configuration connected to the first downstream unit configuration, the upstream unit configuration has: a first instruction unit that notifies the first downstream unit configuration of an execution instruction, notifies the affected area of ​​a wait instruction to continue processing of the first downstream unit configuration via a communication unit, and cancels the wait instruction when it is detected that the event has been recovered from; and a first operation execution unit that obtains a result of related processing in the first downstream unit configuration in response to the execution instruction, reflects the result of the related processing, and executes processing subsequent to the related processing, the first downstream unit configuration has: a second instruction unit that notifies the second downstream unit configuration of an execution instruction, notifies the affected area of ​​a wait instruction to continue processing of the second downstream unit configuration via the communication unit, and cancels the wait instruction when it is detected that the event has been recovered from; A business integrated system having a second calculation execution unit that acquires the results of related processing in the second downstream unit configuration in response to the execution instruction, reflects the results of the related processing, and executes processing subsequent to the related processing.

7. A method for managing a business integrated system that has an upstream unit configuration and a downstream unit configuration and executes processing related to a specified business, wherein an instruction unit issues an execution instruction to the downstream unit configuration, a system status determination unit detects the occurrence of an event that affects processing related to the business in the business integrated system and identifies the scope of impact of the event, an operation execution unit executes processing related to the specified business, the instruction unit issues a wait instruction to the scope of impact via a communication unit to continue processing of the downstream unit configuration, and when it detects that the event has been resolved, it cancels the wait instruction, and the operation execution unit obtains the results of related processing in the downstream unit configuration in accordance with the execution instruction, and executes processing subsequent to the related processing, reflecting the results of the related processing.

8. A management method for a business integrated system according to claim 7, wherein the event is a network failure in a network connecting the upstream unit configuration and the downstream unit configuration.

9. A method for managing a business integrated system as set forth in claim 7, wherein the business is software development work, the downstream unit configuration is a development pipeline execution device that executes pipeline processing in the development of the software, the upstream unit configuration is a pipeline management system connected to the downstream unit configuration via a network, and the calculation execution unit reflects the execution results of the pipeline processing by the development pipeline execution device and moves on to the next pipeline processing of the pipeline processing.

10. A method for managing a business integrated system according to claim 9, wherein the operation execution unit executes the next pipeline processing of the pipeline processing in the development pipeline execution device if the pipeline processing in the development pipeline execution device is successful.

11. A method for managing a business integrated system according to claim 9, wherein the operation execution unit acquires information indicating that pipeline processing in the development pipeline execution device has failed.

12. A method for managing a business integrated system according to any one of claims 7 to 11, wherein the downstream unit configurations are a first downstream unit configuration connected to the upstream unit configuration and a second downstream unit configuration connected to the first downstream unit configuration, the upstream unit configuration having a first instruction unit that notifies the first downstream unit configuration of an execution instruction and notifies the affected area of ​​a wait instruction to continue processing of the first downstream unit configuration via a communication unit, and cancels the wait instruction when it is detected that the event has been recovered from, and a first execution unit that acquires a result of related processing in the first downstream unit configuration in response to the execution instruction and executes processing subsequent to the related processing, reflecting the result of the related processing, the first downstream unit configuration having a second instruction unit that notifies the second downstream unit configuration of an execution instruction and notifies the affected area of ​​a wait instruction to continue processing of the second downstream unit configuration via the communication unit, and cancels the wait instruction when it is detected that the event has been recovered from, A management method for a business integrated system having a second calculation execution unit that acquires the results of related processing in the second downstream unit configuration in response to the execution instruction, reflects the results of the related processing, and executes processing subsequent to the related processing.

Images