WO2010018637A1 - 業務フロー分散処理システム及び方法 - Google Patents

業務フロー分散処理システム及び方法 Download PDF

Info

Publication number
WO2010018637A1
WO2010018637A1 PCT/JP2008/064628 JP2008064628W WO2010018637A1 WO 2010018637 A1 WO2010018637 A1 WO 2010018637A1 JP 2008064628 W JP2008064628 W JP 2008064628W WO 2010018637 A1 WO2010018637 A1 WO 2010018637A1
Authority
WO
WIPO (PCT)
Prior art keywords
server
event data
servers
inquiry
storage unit
Prior art date
Application number
PCT/JP2008/064628
Other languages
English (en)
French (fr)
Inventor
佳秀 野村
Original Assignee
富士通株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 富士通株式会社 filed Critical 富士通株式会社
Priority to PCT/JP2008/064628 priority Critical patent/WO2010018637A1/ja
Priority to JP2010524648A priority patent/JP5024453B2/ja
Priority to EP08809000A priority patent/EP2325791A4/en
Publication of WO2010018637A1 publication Critical patent/WO2010018637A1/ja
Priority to US13/023,118 priority patent/US8583754B2/en

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling

Definitions

  • This technology relates to a technology for generating a business flow, and more particularly to a technology for generating a business flow by distributing processing to a plurality of servers.
  • an object of the present technology is to enable a complete process instance to be generated in a distributed manner on each of a plurality of servers.
  • This distributed business flow processing system includes a plurality of process servers each having means for generating a process instance in which a series of executed business events are arranged in time series, and an identifier for identifying an event name, a processing time, and a process instance And a master server that sequentially reads event data related to a business event from an event data storage unit and allocates the event data to any one of a plurality of process servers. Then, the master server described above has a means for outputting a process instance holding status query corresponding to the identifier included in the event data read from the event data storage unit to a plurality of process servers, and a query from the plurality of process servers.
  • each of the plurality of process servers described above includes a process instance data storage unit that stores a process instance including event data corresponding to an identifier, and a process instance data storage unit when an inquiry is received from a master server.
  • FIG. 1 is a diagram for explaining a problem when the processing load of a process server is distributed.
  • FIG. 2 is a diagram for explaining a problem when the processing load of the process server is distributed.
  • FIG. 3 is a diagram for explaining processing when the number of process instances is totaled.
  • FIG. 4 is a diagram showing an overview of the business flow distributed processing system according to the embodiment.
  • FIG. 5 is a diagram illustrating an example of data stored in the event data storage unit.
  • FIG. 6 is a diagram for explaining the overall flow of the business flow distributed processing system according to the embodiment.
  • FIG. 7 is a diagram for explaining the overall flow of the business flow distributed processing system according to the embodiment.
  • FIG. 8 is a diagram for explaining the overall flow of the business flow distributed processing system according to the embodiment.
  • FIG. 1 is a diagram for explaining a problem when the processing load of a process server is distributed.
  • FIG. 2 is a diagram for explaining a problem when the processing load of the process server is distributed.
  • FIG. 3 is
  • FIG. 9 is a diagram for explaining the overall flow of the business flow distributed processing system according to the embodiment.
  • FIG. 10 is a diagram for explaining the overall flow of the business flow distributed processing system according to the embodiment.
  • FIG. 11 is a diagram for explaining the overall flow of the business flow distributed processing system according to the embodiment.
  • FIG. 12 is a diagram for explaining the overall flow of the business flow distributed processing system according to the embodiment.
  • FIG. 13 is a diagram for explaining the overall flow of the business flow distributed processing system according to the embodiment.
  • FIG. 14 is a diagram for explaining the overall flow of the business flow distributed processing system according to the embodiment.
  • FIG. 15 is a diagram for explaining the overall flow of the business flow distributed processing system according to the embodiment.
  • FIG. 16 is a diagram for explaining the overall flow of the business flow distributed processing system according to the embodiment.
  • FIG. 17 is a diagram for explaining the overall flow of the business flow distributed processing system according to the embodiment.
  • FIG. 18 is a diagram for explaining the overall flow of the business flow distributed processing system according to the embodiment.
  • FIG. 19 is a diagram illustrating a processing flow of the master server.
  • FIG. 20 is a diagram illustrating a processing flow of the master server.
  • FIG. 21 is a diagram showing a processing flow of the master server.
  • FIG. 22 is a diagram illustrating a process flow of the process server.
  • FIG. 23 is a diagram illustrating a process flow of the process server.
  • FIG. 24 is a diagram illustrating a process flow of the process server.
  • FIG. 25 is a diagram illustrating a process flow of the process server.
  • FIG. 26 is a diagram illustrating a process flow of the process server.
  • FIG. 27 is a functional block diagram of a computer.
  • a plurality of process servers that generate process instances in which a series of executed business events are arranged in time series are provided (process servers A and B in FIG. 1), and the processing load of the process servers is distributed. It is possible to make it. In this case, it is necessary for the master server to appropriately distribute processing to each process server according to a predetermined condition. For example, in FIG. 1, since the process instance is generated using the order ID as a key, the master server specifies a business event (for example, order, production, shipment, etc.) having the same order ID as a specific. It needs to be distributed to process servers.
  • a business event for example, order, production, shipment, etc.
  • the number of occurrences of process instances is counted.
  • the identity between process instances is because if the business event sequence in the process instance is the same, the calculated hash value is the same value.
  • a complete process instance cannot be generated, there is a case where a correct aggregation result cannot be obtained.
  • FIG. 4 a configuration as shown in FIG. 4 is adopted.
  • a master server 3 and a plurality of process servers 5 are connected to a network 1 such as an in-house LAN (Local Area Network).
  • a business system is also connected.
  • the master server 3 includes an event data storage unit 31 that stores event data related to a business event performed in the business system, and an event data extraction unit that extracts event data from the event data storage unit 31 periodically or at an arbitrary timing 33, an inquiry unit 35 that inquires each process server 5 about the holding status of a process instance (hereinafter also referred to as flow data) and obtains a hash value, and event data extracted by the event data extraction unit 33. And a storage destination determination unit 37 that performs processing such as determination of a transmission destination.
  • the process server 5A includes an event data receiving unit 51 that receives event data from the master server 3, a flow data processing unit 53 that performs processing such as generating flow data, and a flow generated by the flow data processing unit 53. It has a flow data storage unit 55 that stores data, and a merge processing unit 57 that merges flow data. Although not shown in FIG. 4, the process server 5B has the same configuration as the process server 5A.
  • FIG. 5 shows an example of data stored in the event data storage unit 31.
  • the event data storage unit 31 includes a record number (No.) column, an event name column, an identifier (ID) column for identifying a process instance, and a processing date / time column. Is included.
  • data collected from a business system (not shown) is registered. The collection process itself is not the main part of the technology and will not be described further.
  • the event data storage unit 31 is assumed to store data as shown in FIG. Further, for convenience of explanation, the case where there are two process servers 5 (process servers 5A and 5B) will be described as an example, but the same processing is basically performed when there are three or more process servers.
  • the event data extraction unit 33 of the master server 3 extracts unprocessed event data from the event data storage unit 31 periodically or at an arbitrary timing (FIG. 6: step (1)).
  • the event data (event name “order received”, ID “P01”) of record number 1 (FIG. 5) is extracted.
  • the inquiry unit 35 of the master server 3 extracts the ID (P01) from the event data (step (2)), and outputs an inquiry about the flow data holding status related to the ID (P01) to the process servers 5A and 5B. (Step (3)).
  • each flow data processing unit 53 of the process servers 5A and 5B receives an inquiry about the holding status of the flow data related to the ID (P01) from the master server 3, and the flow data storage unit uses the ID (P01) related to the inquiry. 55 is searched (step (4)). Then, each flow data processing unit 53 of the process servers 5A and 5B responds whether or not the flow data related to the ID (P01) is held (step (5)). In this case, since the process server 5A and the process server 5B do not hold the flow data related to the ID (P01), a response indicating that they are not held is returned. Then, the inquiry unit 35 of the master server 3 receives a response to the inquiry from the process servers 5A and 5B.
  • the storage destination determination unit 37 of the master server 3 determines the event data transmission destination (FIG. 7: step (6)). Although details will be described later, when there is no process server 5 holding the flow data related to the inquiry, the transmission destination of the event data is determined from all the process servers 5. When there is one process server 5 that holds the flow data related to the inquiry, the process server 5 is determined as the event data transmission destination. Further, when there are a plurality of process servers 5 holding the flow data related to the inquiry, the merge destination of the flow data is determined from among the process servers 5 holding the flow data. Here, it is assumed that the process server 5A is determined as the transmission destination.
  • the storage destination determination unit 37 of the master server 3 transmits the event data (event name “order received”, ID “P01”) to the process server 5A (step (7)).
  • the flow data processing unit 53 of the process server 5A receives event data from the master server 3. Then, flow data including the event data is generated and stored in the flow data storage unit 55 (step (8)).
  • the event data extraction unit 33 of the master server 3 extracts the next event data from the event data storage unit 31 (FIG. 8: step (9)).
  • the event data (event name “order received”, ID “P02”) of record number 2 (FIG. 5) is extracted.
  • the inquiry unit 35 of the master server 3 extracts the ID (P02) from the event data (step (10)), and outputs an inquiry about the flow data holding status related to the ID (P02) to the process servers 5A and 5B. (Step (11)).
  • Each flow data processing unit 53 of each of the process servers 5A and 5B receives an inquiry about the holding status of the flow data related to the ID (P02) from the master server 3, and the flow data storage unit uses the ID (P02) related to the inquiry. 55 is searched (step (12)). Then, each flow data processing unit 53 of the process servers 5A and 5B responds whether or not the flow data relating to the ID (P02) is held (step (13)). In this case, since neither the process server 5A nor the process server 5B holds the flow data related to the ID (P02), a response indicating that it is not held is returned. Then, the inquiry unit 35 of the master server 3 receives a response to the inquiry from the process servers 5A and 5B.
  • the storage destination determination unit 37 of the master server 3 determines the transmission destination of the event data (FIG. 9: Step (14)).
  • the process server 5B is determined as the transmission destination.
  • the storage location determination unit 37 of the master server 3 transmits the event data (event name “order received”, ID “P02”) to the process server 5B (step (15)).
  • the flow data processing unit 53 of the process server 5B receives event data from the master server 3. Then, flow data including the event data is generated and stored in the flow data storage unit 55 (step (16)).
  • the event data extraction unit 33 of the master server 3 extracts the next event data from the event data storage unit 31 (FIG. 10: step (17)).
  • the event data (event name “production”, ID “P01”) of record number 3 (FIG. 5) is extracted.
  • the inquiry unit 35 of the master server 3 extracts the ID (P01) from the event data (step (18)), and outputs an inquiry about the flow data holding status related to the ID (P01) to the process servers 5A and 5B. (Step (19)).
  • the process server 5A is assumed to be temporarily unavailable (for example, occurrence of a failure).
  • the flow data processing unit 53 of the process server 5B receives an inquiry about the holding state of the flow data related to the ID (P01) from the master server 3, and searches the flow data storage unit 55 using the ID (P01) related to the inquiry. (Step (20)). Then, the flow data processing unit 53 of the process server 5B responds whether or not the flow data relating to the ID (P01) is held (step (21)). Here, since the process server 5B does not hold the flow data related to the ID (P01), it responds that it is not held. Since the process server 5A is temporarily unavailable, there is no response from the process server 5A. Then, the inquiry unit 35 of the master server 3 receives a response to the inquiry from the process server 5B.
  • the storage destination determination unit 37 of the master server 3 determines the transmission destination of the event data (FIG. 11: Step (22)).
  • the process server 5B is determined as the transmission destination.
  • the storage destination determination unit 37 of the master server 3 transmits the event data (event name “production”, ID “P01”) to the process server 5B (step (23)).
  • the flow data processing unit 53 of the process server 5B receives event data from the master server 3.
  • flow data including the event data is generated and stored in the flow data storage unit 55 (step (24)). That is, the flow data related to ID (P01) is distributed and stored in the process servers 5A and 5B.
  • the event data extraction unit 33 of the master server 3 extracts the next event data from the event data storage unit 31 (FIG. 12: step (25)).
  • the event data (event name “delivery”, ID “P01”) of record number 4 (FIG. 5) is extracted.
  • the inquiry unit 35 of the master server 3 extracts the ID (P01) from the event data (step (26)), and outputs an inquiry about the flow data holding status related to the ID (P01) to the process servers 5A and 5B. (Step (27)). It is assumed that the process server 5A has recovered to a usable state at the time of step (27).
  • each flow data processing unit 53 of the process servers 5A and 5B receives an inquiry about the holding status of the flow data related to the ID (P01) from the master server 3, and the flow data storage unit uses the ID (P01) related to the inquiry. 55 is searched (step (28)). Then, each flow data processing unit 53 of the process servers 5A and 5B responds whether or not the flow data relating to the ID (P01) is held (step (29)). Here, since both the process server 5A and the process server 5B hold the flow data relating to the ID (P01), a response to the effect that they are held is returned. Then, the inquiry unit 35 of the master server 3 receives a response to the inquiry from the process servers 5A and 5B.
  • the storage destination determination unit 37 of the master server 3 determines the flow data merge destination (FIG. 13: step (30)).
  • the process server 5A is determined as the merge destination.
  • the storage location determination unit 37 of the master server 3 transmits a flow data merge instruction related to the ID (P01) to the process server 5B (step (31)).
  • the merge instruction includes the ID and information of the merge destination process server 5.
  • the merge processing unit 57 of the process server 5B receives the merge instruction from the master server 3.
  • the merge processing unit 57 of the process server 5B reads the flow data related to the ID (P01) included in the merge instruction from the flow data storage unit 55 and transmits it to the process server 5A (step (32)). Instead of the flow data, event data related to ID (P01) may be transmitted.
  • the merge processing unit 57 of the process server 5A receives the flow data (or event data) related to the ID (P01) from the process server 5B and merges it with the flow data held by itself (step (33)). . Then, the merge processing unit 57 of the process server 5A transmits a merge completion notification to the process server 5B (step (34)).
  • the merge processing unit 57 of the process server 5B receives the merge completion notification from the process server 5A, and deletes the flow data (or event data) related to the ID (P01) from the flow data storage unit 55 (step (35)). ). That is, the flow data related to ID (P01) is stored only in the process server 5A.
  • the storage location determination unit 37 of the master server 3 transmits the event data (event name “delivery”, ID “P01”) extracted in step (25) to the process server 5A ( FIG. 14: Step (36)). Then, the flow data processing unit 53 of the process server 5A receives the event data from the master server 3 and updates the flow data related to the ID (P01) (step (37)). Specifically, the business event of the event data is added to the flow data related to ID (P01).
  • the event data extraction unit 33 of the master server 3 extracts the next event data from the event data storage unit 31 (FIG. 15: step (38)).
  • the event data (event name “production”, ID “P02”) of record number 5 (FIG. 5) is extracted.
  • the inquiry unit 35 of the master server 3 extracts the ID (P02) from the event data (step (39)), and outputs an inquiry about the flow data holding status related to the ID (P02) to the process servers 5A and 5B. (Step (40)).
  • Each flow data processing unit 53 of each of the process servers 5A and 5B receives an inquiry about the holding status of the flow data related to the ID (P02) from the master server 3, and the flow data storage unit uses the ID (P02) related to the inquiry. 55 is searched (step (41)). Then, each flow data processing unit 53 of the process servers 5A and 5B responds whether or not the flow data related to the ID (P02) is held (step (42)). Here, since the process server 5A does not hold the flow data related to the ID (P02), the process server 5A responds that it is not held. On the other hand, since the process server 5B holds the flow data related to the ID (P02), it responds that it is held. Then, the inquiry unit 35 of the master server 3 receives a response to the inquiry from the process servers 5A and 5B.
  • the storage destination determination unit 37 of the master server 3 determines the transmission destination of the event data (FIG. 16: step (43)). Since only the process server 5B holds the flow data related to the ID (P02), the process server 5B is determined as the transmission destination. Then, the storage location determination unit 37 of the master server 3 transmits the event data (event name “production”, ID “P02”) to the process server 5B (step (44)). The flow data processing unit 53 of the process server 5B receives the event data from the master server 3 and updates the flow data related to the ID (P02) (step (45)). Specifically, the business event of the event data is added to the flow data related to the ID (P02).
  • the event data extraction unit 33 of the master server 3 extracts the next event data from the event data storage unit 31 (FIG. 17: step (46)).
  • the event data (event name “production”, ID “P02”) of record number 6 (FIG. 5) is extracted.
  • the inquiry unit 35 of the master server 3 extracts the ID (P02) from the event data (step (47)), and outputs an inquiry about the flow data holding status related to the ID (P02) to the process servers 5A and 5B. (Step (48)).
  • Each flow data processing unit 53 of each of the process servers 5A and 5B receives an inquiry about the holding status of the flow data related to the ID (P02) from the master server 3, and the flow data storage unit uses the ID (P02) related to the inquiry. 55 is searched (step (49)). Then, each flow data processing unit 53 of the process servers 5A and 5B responds whether or not the flow data related to the ID (P02) is held (step (50)). Here, since the process server 5A does not hold the flow data related to the ID (P02), the process server 5A responds that it is not held. On the other hand, since the process server 5B holds the flow data related to the ID (P02), it responds that it is held. Then, the inquiry unit 35 of the master server 3 receives a response to the inquiry from the process servers 5A and 5B.
  • the storage destination determination unit 37 of the master server 3 determines the transmission destination of the event data (FIG. 18: step (51)). Since only the process server 5B holds the flow data related to the ID (P02), the process server 5B is determined as the transmission destination. Then, the storage location determination unit 37 of the master server 3 transmits the event data (event name “production”, ID “P02”) to the process server 5B (step (52)). The flow data processing unit 53 of the process server 5B receives the event data from the master server 3 and updates the flow data related to the ID (P02) (step (53)). Specifically, the business event of the event data is added to the flow data related to the ID (P02).
  • each of the process servers 5A and 5B calculates a hash value for each flow data.
  • Each of the process servers 5A and 5B may transmit a hash value related to each flow data to the master server 3 in response to a request from the master server 3, for example.
  • FIGS. 19 and 21 show the processing flow of the master server 3.
  • processing when event data is extracted will be described with reference to FIGS. 19 and 20.
  • the master server 3 performs processing as shown in FIGS. 19 and 20 periodically or at an arbitrary timing.
  • the event data extraction unit 33 determines whether unprocessed event data is stored in the event data storage unit 31 (FIG. 19: step S1). If unprocessed event data is not stored in the event data storage unit 31 (step S1: No route), the process ends. On the other hand, when unprocessed event data is stored in the event data storage unit 31 (step S1: Yes route), the event data extraction unit 33 extracts unprocessed event data from the event data storage unit 31 (step S1). S3). And the event data extraction part 33 extracts ID from event data (step S5). And the inquiry part 35 transmits the flow data inquiry request
  • step S9 determines whether or not responses have been received from all the process servers 5 (step S9). If a response from any of the process servers 5 has not been received yet (step S9: No route), the process returns to step S9 and waits for a response from the process server 5. On the other hand, when responses are received from all the process servers 5 (step S9: Yes route), the process proceeds to step S11 (FIG. 20) via the terminal A. For example, when a certain process server 5 is temporarily unavailable, no response is transmitted from the process server 5. Therefore, even if a response from any of the process servers 5 has not been received yet, when a certain time has elapsed, the process proceeds to the process of step S11 (FIG. 20) via the terminal A.
  • the storage location determination unit 37 determines whether there is a process server 5 that holds the flow data corresponding to the extraction ID (FIG. 20: step S11). If there is no process server 5 holding the flow data corresponding to the extraction ID (step S11: No route), the storage destination determination unit 37 determines a storage destination from among all the process servers 5 (step S13). . For example, the process server 5 that is the previous storage destination is stored, the storage destination is changed in order, or the data amount of the flow data storage unit 55 is returned together with the response to the inquiry, so that the process with a small amount of data is performed. The server 5 is determined as a storage destination. Any other method may be adopted as long as it can be appropriately distributed. Then, the storage destination determination unit 37 transmits event data to the process server 5 serving as the storage destination (step S15). Thereafter, the process returns to the process of step S1 (FIG. 19) via the terminal B.
  • step S11 when it is determined in step S11 that there is a process server 5 holding the flow data corresponding to the extraction ID (step S11: Yes route), the storage destination determination unit 37 sets the flow data corresponding to the extraction ID. It is determined whether or not there are a plurality of process servers 5 that hold (step S17). When the number of process servers 5 holding the flow data corresponding to the extraction ID is one (step S17: No route), the storage destination determination unit 37 holds the flow data corresponding to the extraction ID. Is determined as the storage destination (step S19). Thereafter, the process proceeds to step S15, and event data is transmitted to the process server 5 serving as a storage destination.
  • step S17 when it is determined in step S17 that there are a plurality of process servers 5 holding the flow data corresponding to the extraction ID (step S17: Yes route), the storage destination determination unit 37 determines the flow corresponding to the extraction ID.
  • a merge destination is determined from the process servers 5 holding the data (step S21). For example, the data amount of the flow data storage unit 55 is returned together with the response to the inquiry, and the process server 5 having a small data amount is determined as the merge destination. Any other method may be adopted as long as it can be appropriately distributed.
  • the storage destination determination unit 37 transmits a flow data merge instruction including the extraction ID and information of the process server 5 to be merged to the process server 5 holding the flow data corresponding to the extraction ID (step S23). ). Thereafter, the process proceeds to step S15, and event data is transmitted to the process server 5 serving as a storage destination.
  • the master server 3 performs processing as shown in FIG. 21 periodically or at an arbitrary timing.
  • the inquiry unit 35 transmits a hash value acquisition request to each process server 5 (FIG. 21: step S25). Then, the inquiry unit 35 receives a hash value from each process server 5 (step S27). And the inquiry part 35 counts the number of the cases of the flow data which concern on the said hash value for every same hash value, and stores a total result in a memory
  • the event data receiving unit 51 receives event data from the master server 3 (FIG. 22: step S31) and temporarily stores it in the storage device. Then, the flow data processing unit 53 extracts the ID from the event data (step S33). Then, the flow data processing unit 53 determines whether the flow data corresponding to the extraction ID is stored in the flow data storage unit 55 (step S35). When the flow data corresponding to the extraction ID is stored (step S35: Yes route), the flow data corresponding to the extraction ID is read, and the business event of the received event data is added to the flow data (step S37).
  • step S39 new flow data including the business event of the received event data is generated (step S39).
  • the flow data processing unit 53 stores the flow data in the flow data storage unit 55 after the process of step S37 or step S39 (step S41). Specifically, the flow data after adding the business event in step S37 or the flow data generated in step S39 is stored. Further, the flow data processing unit 53 calculates a hash value from the flow data (step S43), and stores it corresponding to the flow data. Thereafter, the process ends.
  • the flow data processing unit 53 receives the flow data inquiry request from the master server 3 (FIG. 23: step S51), and extracts the ID from the flow data inquiry request (step S53). Then, the flow data processing unit 53 searches the flow data storage unit 55 based on the extraction ID (step S55), and determines whether the flow data corresponding to the extraction ID is stored (step S57). When the flow data corresponding to the extraction ID is stored (step S57: Yes route), the flow data processing unit 53 transmits a response to the effect that the flow data is retained to the master server 3 (step S59).
  • step S57 if the flow data corresponding to the extraction ID is not stored (step S57: No route), the flow data processing unit 53 transmits a response to the effect that the flow data is not held to the master server 3 (step S61). ). Then, the process ends.
  • the merge processing unit 57 receives the flow data merge instruction from the master server 3 (FIG. 24: Step S71), and extracts the ID and information of the process server 5 that is the merge destination from the flow data merge instruction (Step S73). Although not shown in the figure, when the server itself is designated as the merge destination process server 5, the subsequent processing is skipped and the processing is terminated. Then, the merge processing unit 57 reads out the flow data corresponding to the extraction ID from the flow data storage unit 55 and transmits it to the merge destination process server 5 (step S75). Instead of transmitting flow data, event data used to generate the flow data may be transmitted.
  • the merge processing unit 57 waits to receive a merge completion notification from the merge destination process server 5.
  • the merge processing unit 57 deletes the flow data corresponding to the extraction ID from the flow data storage unit 55 (step S79). Thereafter, the process ends.
  • step S79 when a merge completion notification is not received from the merge destination process server 5 even after a predetermined time has elapsed, or when an error notification is received from the merge destination process server 5 (step S77: No route), step S79. The process is skipped and the process is terminated. In other words, if merging is not possible for some reason, the flow data is not deleted from the flow data storage unit 55.
  • the merge processing unit 57 receives the flow data (or event data) from the other process server 5 (FIG. 25: Step S91) and temporarily stores it in the storage device. Further, the merge processing unit 57 extracts an ID from the flow data (step S93). Then, the merge processing unit 57 determines whether the flow data corresponding to the extraction ID is stored in the flow data storage unit 55 (step S95). When the flow data corresponding to the extraction ID is stored in the flow data storage unit 55 (step S95: Yes route), the merge processing unit 57 reads the flow data corresponding to the extraction ID from the flow data storage unit 55 and receives it. The flow data is merged (step S97).
  • the merge processing unit 57 stores the merged flow data in the flow data storage unit 55 (step S99).
  • the flow data processing unit 53 calculates a hash value from the merged flow data (step S101), and stores the hash value corresponding to the merged flow data.
  • the merge processing unit 57 transmits a merge completion notification to the flow data transmission source (step S103). Thereafter, the process ends.
  • step S95 when it is determined in step S95 that the flow data corresponding to the extraction ID is not stored in the flow data storage unit 55 (step S95: No route), the merge processing unit 57 determines that the flow data to be merged is Since it does not exist, an error notification is transmitted to the flow data transmission source (step S105). Then, the process ends.
  • the process server 5 performs processing as shown in FIG. 26 periodically or at an arbitrary timing.
  • the flow data processing unit 53 reads the hash value stored corresponding to the flow data, counts the number of pieces of flow data related to the hash value for each identical hash value, and stores the total result in the storage device (see FIG. 26: Step S111).
  • the flow data processing unit 53 determines whether a hash value acquisition request has been received from the master server 3 (step S113). When the hash value acquisition request has been received (step S113: Yes route), the hash value stored corresponding to the flow data is read and transmitted to the master server 3 (step S115). Thereafter, the process ends. On the other hand, if the hash value acquisition request has not been received (step S113: No route), the process of step S115 is skipped and the process ends.
  • the present technology has been described above, but the present technology is not limited to this.
  • the functional block diagrams of the master server 3 and the process server 5 described above do not necessarily correspond to an actual program module configuration.
  • the processing order can be changed if the processing result does not change. Further, it may be executed in parallel.
  • the method for determining the storage destination and the merge destination is not limited to the method described above.
  • the response to the inquiry may be delayed according to the amount of data in the flow data storage unit 55, and the process server 5 that returned the response earliest may be determined as the storage destination or merge destination.
  • event data IDs allocated in the past to each process server 5 are stored in a table or the like, and the process server 5 having a small number of allocations is determined as a storage destination or a merge destination. You may do it.
  • the merge source and the merge destination process server 5 related to the merge instruction are within the predetermined period since the previous merge instruction was transmitted, the merge process is being performed. You may make it remove.
  • the flow data holding status is inquired. For example, if there is a process server 5 that is temporarily unavailable, the master server 3 It is also possible to store the ID of the event data that has been allocated before the return of the process, and make an inquiry about the retention status of the flow data related to the stored ID to the process server after the return.
  • each process server 5 has transmitted a hash value to the master server 3, but instead of the hash value, the number of pieces of each flow data counted in step S111 is transmitted to the master server 3. Also good. In this case, the master server 3 may count the number of flow data from each process server 5 to obtain the total count result.
  • This distributed business flow processing system includes a plurality of process servers each having means for generating a process instance in which a series of executed business events are arranged in time series, and an identifier for identifying an event name, a processing time, and a process instance And a master server that sequentially reads event data related to a business event from an event data storage unit and allocates the event data to any one of a plurality of process servers. Then, the master server described above has a means for outputting a process instance holding status query corresponding to the identifier included in the event data read from the event data storage unit to a plurality of process servers, and a query from the plurality of process servers.
  • each of the plurality of process servers described above includes a process instance data storage unit that stores a process instance including event data corresponding to an identifier, and a process instance data storage unit when an inquiry is received from a master server.
  • the merging means described above may have means for outputting a merge completion notification to the event data transmission source.
  • Each of the plurality of process servers described above further includes means for deleting the process instance corresponding to the merge instruction from the process instance data storage unit when the merge completion notification is received from the second process server. Also good.
  • each of the plurality of process servers described above further includes means for calculating a hash value from each process instance stored in the process instance data storage unit and storing the hash value in the storage device. May be.
  • each of the plurality of process servers described above may further include means for counting the number of process instances related to the hash value for each identical hash value.
  • the master server described above may further include means for acquiring a hash value from each of a plurality of process servers and counting the number of process instances related to the hash value for each same hash value. .
  • this business flow distributed processing system can be realized by causing a program to execute the above processing in hardware, and the program is, for example, a flexible disk, a CD-ROM, a magneto-optical disk, a semiconductor memory, a hard disk, or the like. It is stored in a computer-readable storage medium or storage device. In some cases, digital signals are distributed over a network. Note that data being processed is temporarily stored in a storage device such as a computer memory.
  • the master server 3 and the process server 5 are computer devices as shown in FIG. 27, and are connected to a memory 2501 (storage device), a CPU 2503 (processing device), a hard disk drive (HDD) 2505, and a display device 2509.
  • a display control unit 2507, a drive device 2513 for a removable disk 2511, an input device 2515, and a communication control unit 2517 for connecting to a network are connected by a bus 2519.
  • An operating system (OS: Operating System) and an application program for performing the processing in the present embodiment are stored in the HDD 2505, and are read from the HDD 2505 to the memory 2501 when executed by the CPU 2503.
  • OS Operating System
  • the CPU 2503 controls the display control unit 2507, the communication control unit 2517, and the drive device 2513 to perform necessary operations. Further, data in the middle of processing is stored in the memory 2501 and stored in the HDD 2505 if necessary.
  • an application program for performing the processing described above is stored in a computer-readable removable disk 2511 and distributed, and is installed in the HDD 2505 from the drive device 2513. In some cases, the HDD 2505 may be installed via a network such as the Internet and the communication control unit 2517.
  • Such a computer apparatus realizes various functions as described above by organically cooperating hardware such as the CPU 2503 and the memory 2501 described above, the OS, and necessary application programs.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Human Resources & Organizations (AREA)
  • Strategic Management (AREA)
  • Economics (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Educational Administration (AREA)
  • Game Theory and Decision Science (AREA)
  • Development Economics (AREA)
  • Marketing (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Debugging And Monitoring (AREA)

Abstract

　本システムは、実施された一連の業務イベントを時系列に並べたプロセスインスタンスを生成する手段を各々有する複数のプロセスサーバと、イベントデータをイベントデータ格納部から順次読み出し、複数のプロセスサーバのいずれかに割り振るマスタサーバとを有する。そして、マスタサーバが複数のプロセスサーバにプロセスインスタンスの保持状況を問い合わせ、問い合わせに対する応答からプロセスインスタンスのマージ先を決定し、マージ指示を出力する。そして、マージ元のプロセスサーバは、マージ指示に係るイベントデータをマージ先に送信し、マージ先のプロセスサーバは、イベントデータを受信し、プロセスインスタンスに当該イベントデータをマージする。

Description

業務フロー分散処理システム及び方法
　本技術は、業務フローを生成する技術に関し、より詳しくは複数のサーバに処理を分散させて業務フローを生成する技術に関する。
　例えば企業などにおいて用いられている業務システムで生成されたデータを収集・解析することにより業務フローを自動的に生成する技術が既に知られている。この技術によれば、業務の流れを可視化することができる。
特開２００５－１１５４９４ 特開平８－９５８７４
　従来技術では、処理負荷を分散させるような構成については考慮されておらず、例えば複数のサーバの各々でプロセスインスタンスを分散して生成するような構成は存在しない。
　従って、本技術の目的は、複数のサーバの各々で完全なプロセスインスタンスを分散して生成できるようにすることである。
　本業務フロー分散処理システムは、実施された一連の業務イベントを時系列に並べたプロセスインスタンスを生成する手段を各々有する複数のプロセスサーバと、イベント名と処理時刻とプロセスインスタンスを識別するための識別子とを含み且つ業務イベントに関するイベントデータをイベントデータ格納部から順次読み出し、複数のプロセスサーバのいずれかに割り振るマスタサーバとを有する。そして、上で述べたマスタサーバは、イベントデータ格納部から読み出したイベントデータに含まれる識別子に対応するプロセスインスタンスの保持状況の問い合わせを複数のプロセスサーバに出力する手段と、複数のプロセスサーバから問い合わせに対する応答を受信し、問い合わせに係るプロセスインスタンスを保持している第１プロセスサーバが複数存在するか判断する手段と、第１プロセスサーバが複数存在する場合、第１プロセスサーバの中から問い合わせに係るプロセスインスタンスのマージ先となる第２プロセスサーバを決定する手段と、第２プロセスサーバの情報と問い合わせに係るプロセスインスタンスの識別子とを含むマージ指示を第１プロセスサーバに出力する手段とを有する。さらに、上で述べた複数のプロセスサーバの各々は、イベントデータを含むプロセスインスタンスを識別子に対応して格納するプロセスインスタンスデータ格納部と、マスタサーバから問い合わせを受信した場合、プロセスインスタンスデータ格納部を問い合わせに係る識別子で検索し、当該問い合わせに係るプロセスインスタンスの有無をマスタサーバに応答する手段と、マスタサーバからマージ指示を受信し且つ自身が第２プロセスサーバ以外の第１プロセスサーバである場合、マージ指示に含まれる識別子に係るイベントデータをマージ指示に含まれる第２プロセスサーバに出力する手段と、他のプロセスサーバからイベントデータを受信した場合、プロセスインスタンスデータ格納部に格納され且つ当該イベントデータと同一の識別子に対応するプロセスインスタンスに当該イベントデータをマージするマージ手段とを有する。
図１は、プロセスサーバの処理負荷を分散させた場合の問題を説明するための図である。 図２は、プロセスサーバの処理負荷を分散させた場合の問題を説明するための図である。 図３は、プロセスインスタンスの件数を集計する場合の処理を説明するための図である。 図４は、実施の形態に係る業務フロー分散処理システムの概要を示す図である。 図５は、イベントデータ格納部に格納されるデータの一例を示す図である。 図６は、実施の形態に係る業務フロー分散処理システムの全体の流れを説明するための図である。 図７は、実施の形態に係る業務フロー分散処理システムの全体の流れを説明するための図である。 図８は、実施の形態に係る業務フロー分散処理システムの全体の流れを説明するための図である。 図９は、実施の形態に係る業務フロー分散処理システムの全体の流れを説明するための図である。 図１０は、実施の形態に係る業務フロー分散処理システムの全体の流れを説明するための図である。 図１１は、実施の形態に係る業務フロー分散処理システムの全体の流れを説明するための図である。 図１２は、実施の形態に係る業務フロー分散処理システムの全体の流れを説明するための図である。 図１３は、実施の形態に係る業務フロー分散処理システムの全体の流れを説明するための図である。 図１４は、実施の形態に係る業務フロー分散処理システムの全体の流れを説明するための図である。 図１５は、実施の形態に係る業務フロー分散処理システムの全体の流れを説明するための図である。 図１６は、実施の形態に係る業務フロー分散処理システムの全体の流れを説明するための図である。 図１７は、実施の形態に係る業務フロー分散処理システムの全体の流れを説明するための図である。 図１８は、実施の形態に係る業務フロー分散処理システムの全体の流れを説明するための図である。 図１９は、マスタサーバの処理フローを示す図である。 図２０は、マスタサーバの処理フローを示す図である。 図２１は、マスタサーバの処理フローを示す図である。 図２２は、プロセスサーバの処理フローを示す図である。 図２３は、プロセスサーバの処理フローを示す図である。 図２４は、プロセスサーバの処理フローを示す図である。 図２５は、プロセスサーバの処理フローを示す図である。 図２６は、プロセスサーバの処理フローを示す図である。 図２７は、コンピュータの機能ブロック図である。
　例えば図１に示すように、実施された一連の業務イベントを時系列に並べたプロセスインスタンスを生成するプロセスサーバを複数設け（図１では、プロセスサーバＡ及びＢ）、プロセスサーバの処理負荷を分散させることが考えられる。この場合、マスタサーバが、所定の条件に応じて各プロセスサーバに適切に処理を振り分ける必要がある。例えば、図１では、受注ＩＤをキーにしてプロセスインスタンスを生成するようになっているため、マスタサーバは、同一の受注ＩＤを有する業務イベント（例えば、受注、生産、出荷など）を、特定のプロセスサーバに振り分ける必要がある。しかし、例えばプロセスサーバに障害が発生し、一時的に利用不可になると、図２に示すように、同一の受注ＩＤを有する業務イベントが複数のプロセスサーバに分散してしまい、完全なプロセスインスタンス（図２の例では、「受注」－「生産」－「出荷」）を生成することができない。
　一方で、例えば業務フローの分析などにおいて、プロセスインスタンスの発生件数の集計を行っている。なお、プロセスインスタンスの同一性を判断する際には、プロセスインスタンス間で業務イベントの並びを比較するとなると時間がかかるため、図３に示すように、プロセスインスタンス毎にハッシュ値を計算し、ハッシュ値に従ってプロセスインスタンス間の同一性を判断する。これは、プロセスインスタンスにおける業務イベントの並びが同じであれば、算出されるハッシュ値も同じ値となるからである。しかし、上で述べたように、完全なプロセスインスタンスを生成することができないため、正しい集計結果を得ることができない場合がある。
　そこで、本実施の形態では、図４に示すような構成を採用する。以下、本技術の一実施の形態に係る業務フロー分散処理システムについて説明する。図４では、例えば社内ＬＡＮ（Local Area Network）のようなネットワーク１には、マスタサーバ３と、複数のプロセスサーバ５（図４では５Ａ及び５Ｂ）とが接続されている。なお、図示していないが、業務システムなども接続されている。
　マスタサーバ３は、業務システムにおいて実施された業務イベントに関するイベントデータを格納するイベントデータ格納部３１と、定期的に又は任意のタイミングにてイベントデータ格納部３１からイベントデータを抽出するイベントデータ抽出部３３と、各プロセスサーバ５にプロセスインスタンス（以下、フローデータと呼ぶ場合もある）の保持状況の問い合わせやハッシュ値の取得を行う問い合わせ部３５と、イベントデータ抽出部３３により抽出されたイベントデータの送信先を決定するなどの処理を実施する格納先決定部３７とを有する。
　プロセスサーバ５Ａは、マスタサーバ３からのイベントデータを受信するイベントデータ受信部５１と、フローデータを生成するなどの処理を実施するフローデータ処理部５３と、フローデータ処理部５３により生成されたフローデータを格納するフローデータ格納部５５と、フローデータのマージを行うマージ処理部５７とを有する。なお、図４では図示していないが、プロセスサーバ５Ｂも、プロセスサーバ５Ａと同様の構成を有する。
　図５にイベントデータ格納部３１に格納されるデータの一例を示す。図５の例では、イベントデータ格納部３１には、レコード番号（Ｎｏ．）の列と、イベント名の列と、プロセスインスタンスを識別するための識別子（ＩＤ）の列と、処理日時の列とが含まれる。なお、イベントデータ格納部３１には、業務システム（図示せず）から収集したデータが登録される。収集処理自体は、本技術の主要部分ではないため、これ以上述べない。
　次に、図６乃至図１８を用いて、図４に示した業務フロー分散処理システムの全体の流れを説明する。なお、イベントデータ格納部３１には、図５に示したようなデータが格納されているものとする。また、説明の便宜上、プロセスサーバ５が２台（プロセスサーバ５Ａ及び５Ｂ）の場合を例として説明するが、３台以上の場合も基本的には同様の処理となる。まず、マスタサーバ３のイベントデータ抽出部３３は、定期的又は任意のタイミングにてイベントデータ格納部３１から未処理のイベントデータを抽出する（図６：ステップ（１））。ここでは、レコード番号１（図５）のイベントデータ（イベント名「受注」、ＩＤ「Ｐ０１」）が抽出される。そして、マスタサーバ３の問い合わせ部３５は、イベントデータからＩＤ（Ｐ０１）を抽出し（ステップ（２））、当該ＩＤ（Ｐ０１）に係るフローデータの保持状況の問い合わせをプロセスサーバ５Ａ及び５Ｂに出力する（ステップ（３））。
　そして、プロセスサーバ５Ａ及び５Ｂの各々のフローデータ処理部５３は、マスタサーバ３からＩＤ（Ｐ０１）に係るフローデータの保持状況の問い合わせを受信し、問い合わせに係るＩＤ（Ｐ０１）でフローデータ格納部５５を検索する（ステップ（４））。そして、プロセスサーバ５Ａ及び５Ｂの各々のフローデータ処理部５３は、ＩＤ（Ｐ０１）に係るフローデータを保持しているか否かを応答する（ステップ（５））。なお、ここでは、プロセスサーバ５Ａもプロセスサーバ５ＢもＩＤ（Ｐ０１）に係るフローデータを保持していないため、保持していない旨を応答する。そして、マスタサーバ３の問い合わせ部３５は、問い合わせに対する応答をプロセスサーバ５Ａ及び５Ｂから受信する。
　図７の説明に移行して、マスタサーバ３の格納先決定部３７は、イベントデータの送信先を決定する（図７：ステップ（６））。なお、詳細は後で説明するが、問い合わせに係るフローデータを保持しているプロセスサーバ５が存在しない場合には、全てのプロセスサーバ５の中からイベントデータの送信先を決定する。また、問い合わせに係るフローデータを保持しているプロセスサーバ５が１台である場合には、当該プロセスサーバ５をイベントデータの送信先として決定する。さらに、問い合わせに係るフローデータを保持しているプロセスサーバ５が複数存在する場合には、当該フローデータを保持しているプロセスサーバ５の中からフローデータのマージ先を決定する。なお、ここでは、プロセスサーバ５Ａが送信先として決定されたものとする。そして、マスタサーバ３の格納先決定部３７は、イベントデータ（イベント名「受注」、ＩＤ「Ｐ０１」）をプロセスサーバ５Ａに送信する（ステップ（７））。プロセスサーバ５Ａのフローデータ処理部５３は、マスタサーバ３からのイベントデータを受信する。そして、当該イベントデータを含むフローデータを生成し、フローデータ格納部５５に格納する（ステップ（８））。
　図８の説明に移行して、マスタサーバ３のイベントデータ抽出部３３は、イベントデータ格納部３１から次のイベントデータを抽出する（図８：ステップ（９））。ここでは、レコード番号２（図５）のイベントデータ（イベント名「受注」、ＩＤ「Ｐ０２」）が抽出される。そして、マスタサーバ３の問い合わせ部３５は、イベントデータからＩＤ（Ｐ０２）を抽出し（ステップ（１０））、当該ＩＤ（Ｐ０２）に係るフローデータの保持状況の問い合わせをプロセスサーバ５Ａ及び５Ｂに出力する（ステップ（１１））。
　そして、プロセスサーバ５Ａ及び５Ｂの各々のフローデータ処理部５３は、マスタサーバ３からＩＤ（Ｐ０２）に係るフローデータの保持状況の問い合わせを受信し、問い合わせに係るＩＤ（Ｐ０２）でフローデータ格納部５５を検索する（ステップ（１２））。そして、プロセスサーバ５Ａ及び５Ｂの各々のフローデータ処理部５３は、ＩＤ（Ｐ０２）に係るフローデータを保持しているか否かを応答する（ステップ（１３））。なお、ここでは、プロセスサーバ５Ａもプロセスサーバ５ＢもＩＤ（Ｐ０２）に係るフローデータを保持していないため、保持していない旨を応答する。そして、マスタサーバ３の問い合わせ部３５は、問い合わせに対する応答をプロセスサーバ５Ａ及び５Ｂから受信する。
　図９の説明に移行して、マスタサーバ３の格納先決定部３７は、イベントデータの送信先を決定する（図９：ステップ（１４））。ここでは、プロセスサーバ５Ｂが送信先として決定されたものとする。そして、マスタサーバ３の格納先決定部３７は、イベントデータ（イベント名「受注」、ＩＤ「Ｐ０２」）をプロセスサーバ５Ｂに送信する（ステップ（１５））。プロセスサーバ５Ｂのフローデータ処理部５３は、マスタサーバ３からのイベントデータを受信する。そして、当該イベントデータを含むフローデータを生成し、フローデータ格納部５５に格納する（ステップ（１６））。
　図１０の説明に移行して、マスタサーバ３のイベントデータ抽出部３３は、イベントデータ格納部３１から次のイベントデータを抽出する（図１０：ステップ（１７））。ここでは、レコード番号３（図５）のイベントデータ（イベント名「生産」、ＩＤ「Ｐ０１」）が抽出される。そして、マスタサーバ３の問い合わせ部３５は、イベントデータからＩＤ（Ｐ０１）を抽出し（ステップ（１８））、ＩＤ（Ｐ０１）に係るフローデータの保持状況の問い合わせをプロセスサーバ５Ａ及び５Ｂに出力する（ステップ（１９））。なお、ステップ（１９）の時点において、プロセスサーバ５Ａは、一時的に利用できない状態（例えば障害発生など）になっているものとする。
　そして、プロセスサーバ５Ｂのフローデータ処理部５３は、マスタサーバ３からＩＤ（Ｐ０１）に係るフローデータの保持状況の問い合わせを受信し、問い合わせに係るＩＤ（Ｐ０１）でフローデータ格納部５５を検索する（ステップ（２０））。そして、プロセスサーバ５Ｂのフローデータ処理部５３は、ＩＤ（Ｐ０１）に係るフローデータを保持しているか否かを応答する（ステップ（２１））。ここでは、プロセスサーバ５ＢはＩＤ（Ｐ０１）に係るフローデータを保持していないため、保持していない旨を応答する。なお、プロセスサーバ５Ａは、一時的に利用できない状態であるため、プロセスサーバ５Ａからの応答はない。そして、マスタサーバ３の問い合わせ部３５は、問い合わせに対する応答をプロセスサーバ５Ｂから受信する。
　図１１の説明に移行して、マスタサーバ３の格納先決定部３７は、イベントデータの送信先を決定する（図１１：ステップ（２２））。ここでは、プロセスサーバ５Ｂが送信先として決定されたものとする。そして、マスタサーバ３の格納先決定部３７は、イベントデータ（イベント名「生産」、ＩＤ「Ｐ０１」）をプロセスサーバ５Ｂに送信する（ステップ（２３））。プロセスサーバ５Ｂのフローデータ処理部５３は、マスタサーバ３からのイベントデータを受信する。そして、当該イベントデータを含むフローデータを生成し、フローデータ格納部５５に格納する（ステップ（２４））。すなわち、ＩＤ（Ｐ０１）に係るフローデータが、プロセスサーバ５Ａ及び５Ｂに分散されて格納された状態となる。
　図１２の説明に移行して、マスタサーバ３のイベントデータ抽出部３３は、イベントデータ格納部３１から次のイベントデータを抽出する（図１２：ステップ（２５））。ここでは、レコード番号４（図５）のイベントデータ（イベント名「配送」、ＩＤ「Ｐ０１」）が抽出される。そして、マスタサーバ３の問い合わせ部３５は、イベントデータからＩＤ（Ｐ０１）を抽出し（ステップ（２６））、ＩＤ（Ｐ０１）に係るフローデータの保持状況の問い合わせをプロセスサーバ５Ａ及び５Ｂに出力する（ステップ（２７））。なお、ステップ（２７）の時点において、プロセスサーバ５Ａは、利用可能な状態に回復しているものとする。
　そして、プロセスサーバ５Ａ及び５Ｂの各々のフローデータ処理部５３は、マスタサーバ３からＩＤ（Ｐ０１）に係るフローデータの保持状況の問い合わせを受信し、問い合わせに係るＩＤ（Ｐ０１）でフローデータ格納部５５を検索する（ステップ（２８））。そして、プロセスサーバ５Ａ及び５Ｂの各々のフローデータ処理部５３は、ＩＤ（Ｐ０１）に係るフローデータを保持しているか否かを応答する（ステップ（２９））。ここでは、プロセスサーバ５Ａもプロセスサーバ５ＢもＩＤ（Ｐ０１）に係るフローデータを保持しているため、保持している旨を応答する。そして、マスタサーバ３の問い合わせ部３５は、問い合わせに対する応答をプロセスサーバ５Ａ及び５Ｂから受信する。
　図１３の説明に移行して、マスタサーバ３の格納先決定部３７は、フローデータのマージ先を決定する（図１３：ステップ（３０））。ここでは、プロセスサーバ５Ａがマージ先として決定されたものとする。そして、マスタサーバ３の格納先決定部３７は、ＩＤ（Ｐ０１）に係るフローデータのマージ指示をプロセスサーバ５Ｂに送信する（ステップ（３１））。なお、マージ指示には、ＩＤ及びマージ先のプロセスサーバ５の情報が含まれる。プロセスサーバ５Ｂのマージ処理部５７は、マスタサーバ３からのマージ指示を受信する。そして、プロセスサーバ５Ｂのマージ処理部５７は、マージ指示に含まれるＩＤ（Ｐ０１）に係るフローデータをフローデータ格納部５５から読み出し、プロセスサーバ５Ａに送信する（ステップ（３２））。なお、フローデータではなく、ＩＤ（Ｐ０１）に係るイベントデータを送信するようにしてもよい。
　そして、プロセスサーバ５Ａのマージ処理部５７は、プロセスサーバ５ＢからＩＤ（Ｐ０１）に係るフローデータ（又はイベントデータ）を受信し、自身の保持しているフローデータにマージする（ステップ（３３））。そして、プロセスサーバ５Ａのマージ処理部５７は、マージ完了通知をプロセスサーバ５Ｂに送信する（ステップ（３４））。
　そして、プロセスサーバ５Ｂのマージ処理部５７は、プロセスサーバ５Ａからマージ完了通知を受信し、フローデータ格納部５５からＩＤ（Ｐ０１）に係るフローデータ（又はイベントデータ）を削除する（ステップ（３５））。すなわち、ＩＤ（Ｐ０１）に係るフローデータが、プロセスサーバ５Ａにのみ格納された状態となる。
　図１４の説明に移行して、マスタサーバ３の格納先決定部３７は、ステップ（２５）にて抽出したイベントデータ（イベント名「配送」、ＩＤ「Ｐ０１」）をプロセスサーバ５Ａに送信する（図１４：ステップ（３６））。そして、プロセスサーバ５Ａのフローデータ処理部５３は、マスタサーバ３からのイベントデータを受信し、ＩＤ（Ｐ０１）に係るフローデータを更新する（ステップ（３７））。具体的には、当該イベントデータの業務イベントをＩＤ（Ｐ０１）に係るフローデータに追加する。
　図１５の説明に移行して、マスタサーバ３のイベントデータ抽出部３３は、イベントデータ格納部３１から次のイベントデータを抽出する（図１５：ステップ（３８））。ここでは、レコード番号５（図５）のイベントデータ（イベント名「生産」、ＩＤ「Ｐ０２」）が抽出される。そして、マスタサーバ３の問い合わせ部３５は、イベントデータからＩＤ（Ｐ０２）を抽出し（ステップ（３９））、ＩＤ（Ｐ０２）に係るフローデータの保持状況の問い合わせをプロセスサーバ５Ａ及び５Ｂに出力する（ステップ（４０））。
　そして、プロセスサーバ５Ａ及び５Ｂの各々のフローデータ処理部５３は、マスタサーバ３からＩＤ（Ｐ０２）に係るフローデータの保持状況の問い合わせを受信し、問い合わせに係るＩＤ（Ｐ０２）でフローデータ格納部５５を検索する（ステップ（４１））。そして、プロセスサーバ５Ａ及び５Ｂの各々のフローデータ処理部５３は、ＩＤ（Ｐ０２）に係るフローデータを保持しているか否かを応答する（ステップ（４２））。ここでは、プロセスサーバ５Ａは、ＩＤ（Ｐ０２）に係るフローデータを保持していないため、保持していない旨を応答する。一方、プロセスサーバ５Ｂは、ＩＤ（Ｐ０２）に係るフローデータを保持しているため、保持している旨を応答する。そして、マスタサーバ３の問い合わせ部３５は、問い合わせに対する応答をプロセスサーバ５Ａ及び５Ｂから受信する。
　図１６の説明に移行して、マスタサーバ３の格納先決定部３７は、イベントデータの送信先を決定する（図１６：ステップ（４３））。なお、ＩＤ（Ｐ０２）に係るフローデータを保持しているのが、プロセスサーバ５Ｂのみであるため、プロセスサーバ５Ｂを送信先として決定する。そして、マスタサーバ３の格納先決定部３７は、イベントデータ（イベント名「生産」、ＩＤ「Ｐ０２」）をプロセスサーバ５Ｂに送信する（ステップ（４４））。プロセスサーバ５Ｂのフローデータ処理部５３は、マスタサーバ３からのイベントデータを受信し、ＩＤ（Ｐ０２）に係るフローデータを更新する（ステップ（４５））。具体的には、当該イベントデータの業務イベントをＩＤ（Ｐ０２）に係るフローデータに追加する。
　図１７の説明に移行して、マスタサーバ３のイベントデータ抽出部３３は、イベントデータ格納部３１から次のイベントデータを抽出する（図１７：ステップ（４６））。ここでは、レコード番号６（図５）のイベントデータ（イベント名「生産」、ＩＤ「Ｐ０２」）が抽出される。そして、マスタサーバ３の問い合わせ部３５は、イベントデータからＩＤ（Ｐ０２）を抽出し（ステップ（４７））、ＩＤ（Ｐ０２）に係るフローデータの保持状況の問い合わせをプロセスサーバ５Ａ及び５Ｂに出力する（ステップ（４８））。
　そして、プロセスサーバ５Ａ及び５Ｂの各々のフローデータ処理部５３は、マスタサーバ３からＩＤ（Ｐ０２）に係るフローデータの保持状況の問い合わせを受信し、問い合わせに係るＩＤ（Ｐ０２）でフローデータ格納部５５を検索する（ステップ（４９））。そして、プロセスサーバ５Ａ及び５Ｂの各々のフローデータ処理部５３は、ＩＤ（Ｐ０２）に係るフローデータを保持しているか否かを応答する（ステップ（５０））。ここでは、プロセスサーバ５Ａは、ＩＤ（Ｐ０２）に係るフローデータを保持していないため、保持していない旨を応答する。一方、プロセスサーバ５Ｂは、ＩＤ（Ｐ０２）に係るフローデータを保持しているため、保持している旨を応答する。そして、マスタサーバ３の問い合わせ部３５は、問い合わせに対する応答をプロセスサーバ５Ａ及び５Ｂから受信する。
　図１８の説明に移行して、マスタサーバ３の格納先決定部３７は、イベントデータの送信先を決定する（図１８：ステップ（５１））。なお、ＩＤ（Ｐ０２）に係るフローデータを保持しているのが、プロセスサーバ５Ｂのみであるため、プロセスサーバ５Ｂを送信先として決定する。そして、マスタサーバ３の格納先決定部３７は、イベントデータ（イベント名「生産」、ＩＤ「Ｐ０２」）をプロセスサーバ５Ｂに送信する（ステップ（５２））。プロセスサーバ５Ｂのフローデータ処理部５３は、マスタサーバ３からのイベントデータを受信し、ＩＤ（Ｐ０２）に係るフローデータを更新する（ステップ（５３））。具体的には、当該イベントデータの業務イベントをＩＤ（Ｐ０２）に係るフローデータに追加する。そして、プロセスサーバ５Ａ及び５Ｂの各々は、フローデータ毎にハッシュ値を計算する。なお、プロセスサーバ５Ａ及び５Ｂの各々は、例えばマスタサーバ３からの要求に応じて各フローデータに係るハッシュ値をマスタサーバ３に送信するようにしてもよい。
　このように、本業務フロー分散処理システムでは、なんらかの理由で同一ＩＤの業務イベントが複数のプロセスサーバ５に分散されても、その後自動的にマージするので、結果として複数のプロセスサーバ５の各々で完全なプロセスインスタンスを分散して生成することができる。また、プロセスインスタンス間の同一性をハッシュ値により判断することができ、正しい集計結果を得ることができる。
　以上のような処理を実施することにより、なんらかの理由で同一ＩＤの業務イベントが複数のプロセスサーバ５に分散されても、その後自動的にマージされるため、結果として複数のプロセスサーバ５の各々で完全なプロセスインスタンスを分散して生成することができるようになる。
　次に、図１９乃至図２６を用いて、上で説明した処理を実施するためのマスタサーバ３及びプロセスサーバ５の処理をより詳細に説明する。図１９及び図２１に、マスタサーバ３の処理フローを示す。まず、図１９及び図２０を用いて、イベントデータを抽出した際の処理を説明する。なお、マスタサーバ３は、定期的又は任意のタイミングにて図１９及び図２０に示すような処理を実施する。
　まず、イベントデータ抽出部３３は、イベントデータ格納部３１に未処理のイベントデータが格納されているか判断する（図１９：ステップＳ１）。イベントデータ格納部３１に未処理のイベントデータが格納されていなければ（ステップＳ１：Ｎｏルート）、処理を終了する。一方、イベントデータ格納部３１に未処理のイベントデータが格納されている場合（ステップＳ１：Ｙｅｓルート）、イベントデータ抽出部３３は、イベントデータ格納部３１から未処理のイベントデータを抽出する（ステップＳ３）。そして、イベントデータ抽出部３３は、イベントデータからＩＤを抽出する（ステップＳ５）。そして、問い合わせ部３５が、抽出ＩＤを含むフローデータ問い合わせ要求を各プロセスサーバ５に送信する（ステップＳ７）。
　その後、問い合わせ部３５は、プロセスサーバ５からの応答を受信すると、全てのプロセスサーバ５から応答を受信したか否か判断する（ステップＳ９）。いずれかのプロセスサーバ５からの応答を未だ受信していない場合（ステップＳ９：Ｎｏルート）、ステップＳ９の処理に戻り、プロセスサーバ５からの応答の受信待ちとなる。一方、全てのプロセスサーバ５から応答を受信した場合（ステップＳ９：Ｙｅｓルート）、端子Ａを介してステップＳ１１（図２０）の処理に移行する。なお、例えばあるプロセスサーバ５が一時的に利用できない状態となっている場合には、当該プロセスサーバ５から応答は送信されない。したがって、いずれかのプロセスサーバ５からの応答を未だ受信していない場合であっても、一定時間経過した場合には、端子Ａを介してステップＳ１１（図２０）の処理に移行する。
　図２０の説明に移行して、端子Ａの後、格納先決定部３７は、抽出ＩＤに対応するフローデータを保持しているプロセスサーバ５があるか判断する（図２０：ステップＳ１１）。抽出ＩＤに対応するフローデータを保持しているプロセスサーバ５がなければ（ステップＳ１１：Ｎｏルート）、格納先決定部３７は、全てのプロセスサーバ５の中から格納先を決定する（ステップＳ１３）。例えば、前回格納先としたプロセスサーバ５を記憶しておき、順番で格納先を変更するようにしたり、問い合わせに対する応答と共にフローデータ格納部５５のデータ量を返すようにして、データ量の少ないプロセスサーバ５を格納先として決定したりする。なお、適切に分散できる方式であれば、他の方式を採用してもよい。そして、格納先決定部３７は、格納先となるプロセスサーバ５にイベントデータを送信する（ステップＳ１５）。その後、端子Ｂを介してステップＳ１（図１９）の処理に戻る。
　一方、ステップＳ１１において、抽出ＩＤに対応するフローデータを保持しているプロセスサーバ５があると判断された場合（ステップＳ１１：Ｙｅｓルート）、格納先決定部３７は、抽出ＩＤに対応するフローデータを保持しているプロセスサーバ５が複数あるか判断する（ステップＳ１７）。抽出ＩＤに対応するフローデータを保持しているプロセスサーバ５が１台の場合（ステップＳ１７：Ｎｏルート）、格納先決定部３７は、抽出ＩＤに対応するフローデータを保持しているプロセスサーバ５を格納先として決定する（ステップＳ１９）。その後、ステップＳ１５の処理に移行し、格納先となるプロセスサーバ５にイベントデータを送信する。
　一方、ステップＳ１７において、抽出ＩＤに対応するフローデータを保持しているプロセスサーバ５が複数あると判断された場合（ステップＳ１７：Ｙｅｓルート）、格納先決定部３７は、抽出ＩＤに対応するフローデータを保持しているプロセスサーバ５の中からマージ先を決定する（ステップＳ２１）。例えば、問い合わせに対する応答と共にフローデータ格納部５５のデータ量を返すようにして、データ量の少ないプロセスサーバ５をマージ先として決定したりする。なお、適切に分散できる方式であれば、他の方式を採用してもよい。そして、格納先決定部３７は、抽出ＩＤ及びマージ先となるプロセスサーバ５の情報を含むフローデータマージ指示を、抽出ＩＤに対応するフローデータを保持しているプロセスサーバ５に送信する（ステップＳ２３）。その後、ステップＳ１５の処理に移行し、格納先となるプロセスサーバ５にイベントデータを送信する。
　次に、図２１を用いて、集計に関連する処理を説明する。なお、マスタサーバ３は、定期的又は任意のタイミングにて図２１に示すような処理を実施する。まず、問い合わせ部３５は、各プロセスサーバ５にハッシュ値取得要求を送信する（図２１：ステップＳ２５）。そして、問い合わせ部３５は、各プロセスサーバ５からハッシュ値を受信する（ステップＳ２７）。そして、問い合わせ部３５は、同一ハッシュ値毎に、当該ハッシュ値に係るフローデータの件数を計数し、集計結果を記憶装置に格納する（ステップＳ２９）。集計結果は、必要に応じてユーザなどに出力する。
　図２２乃至図２６に、プロセスサーバ５の処理フローを示す。まず、図２２を用いて、マスタサーバ３からイベントデータを受信した際の処理を説明する。イベントデータ受信部５１は、マスタサーバ３からイベントデータを受信し（図２２：ステップＳ３１）、一旦記憶装置に格納する。そして、フローデータ処理部５３が、イベントデータからＩＤを抽出する（ステップＳ３３）。そして、フローデータ処理部５３は、抽出ＩＤに対応するフローデータがフローデータ格納部５５に格納されているか判断する（ステップＳ３５）。抽出ＩＤに対応するフローデータが格納されている場合（ステップＳ３５：Ｙｅｓルート）、抽出ＩＤに対応するフローデータを読み出し、受信したイベントデータの業務イベントを当該フローデータ追加する（ステップＳ３７）。一方、抽出ＩＤに対応するフローデータがフローデータ格納部５５に格納されていなければ（ステップＳ３５：Ｎｏルート）、受信したイベントデータの業務イベントを含むフローデータを新たに生成する（ステップＳ３９）。そして、フローデータ処理部５３は、ステップＳ３７又はステップＳ３９の処理の後、フローデータをフローデータ格納部５５に格納する（ステップＳ４１）。具体的には、ステップＳ３７において業務イベントを追加した後のフローデータ、又は、ステップＳ３９において生成したフローデータを格納する。また、フローデータ処理部５３は、当該フローデータからハッシュ値を計算し（ステップＳ４３）、フローデータと対応して格納する。その後、処理を終了する。
　次に、図２３を用いて、マスタサーバ３からフローデータ問い合わせ要求を受信した際の処理を説明する。フローデータ処理部５３は、マスタサーバ３からフローデータ問い合わせ要求を受信し（図２３：ステップＳ５１）、フローデータ問い合わせ要求からＩＤを抽出する（ステップＳ５３）。そして、フローデータ処理部５３は、抽出ＩＤを基にフローデータ格納部５５を検索し（ステップＳ５５）、抽出ＩＤに対応するフローデータが格納されているか判断する（ステップＳ５７）。抽出ＩＤに対応するフローデータが格納されている場合（ステップＳ５７：Ｙｅｓルート）、フローデータ処理部５３は、フローデータを保持している旨の応答をマスタサーバ３に送信する（ステップＳ５９）。一方、抽出ＩＤに対応するフローデータが格納されていなければ（ステップＳ５７：Ｎｏルート）、フローデータ処理部５３は、フローデータを保持していない旨の応答をマスタサーバ３に送信する（ステップＳ６１）。そして、処理を終了する。
　次に、図２４を用いて、マスタサーバ３からフローデータマージ指示を受信した際の処理を説明する。マージ処理部５７は、マスタサーバ３からフローデータマージ指示を受信し（図２４：ステップＳ７１）、フローデータマージ指示からＩＤ及びマージ先のプロセスサーバ５の情報を抽出する（ステップＳ７３）。なお、図示していないが、自身がマージ先のプロセスサーバ５として指定されている場合には、以降の処理をスキップし、処理を終了する。そして、マージ処理部５７は、抽出ＩＤに対応するフローデータをフローデータ格納部５５から読み出し、マージ先のプロセスサーバ５に送信する（ステップＳ７５）。なお、フローデータを送信するのではなく、当該フローデータを生成するために用いたイベントデータを送信するようにしてもよい。その後、マージ処理部５７は、マージ先のプロセスサーバ５からのマージ完了通知の受信待ちとなる。マージ先のプロセスサーバ５からマージ完了通知を受信した場合（ステップＳ７７：Ｙｅｓルート）、マージ処理部５７は、フローデータ格納部５５から抽出ＩＤに対応するフローデータを削除する（ステップＳ７９）。その後処理を終了する。
　一方、一定時間経過してもマージ先のプロセスサーバ５からマージ完了通知を受信しなかった場合、又は、マージ先のプロセスサーバ５からエラー通知を受信した場合（ステップＳ７７：Ｎｏルート）、ステップＳ７９の処理をスキップし、処理を終了する。すなわち、なんらかの理由でマージできなかった場合には、フローデータはフローデータ格納部５５から削除されない。
　次に、図２５を用いて、他のプロセスサーバ５からフローデータ（又はイベントデータ）を受信した際の処理を説明する。マージ処理部５７は、他のプロセスサーバ５からフローデータ（又はイベントデータ）を受信し（図２５：ステップＳ９１）、一旦記憶装置に格納する。また、マージ処理部５７は、フローデータからＩＤを抽出する（ステップＳ９３）。そして、マージ処理部５７は、抽出ＩＤに対応するフローデータがフローデータ格納部５５に格納されているか判断する（ステップＳ９５）。抽出ＩＤに対応するフローデータがフローデータ格納部５５に格納されている場合（ステップＳ９５：Ｙｅｓルート）、マージ処理部５７は、フローデータ格納部５５から抽出ＩＤに対応するフローデータを読み出し、受信したフローデータとマージする（ステップＳ９７）。具体的には、他のプロセスサーバ５からのフローデータに含まれるイベントデータの業務イベントを処理日時に従って自身のフローデータに追加する。そして、マージ処理部５７は、マージ後のフローデータをフローデータ格納部５５に格納する（ステップＳ９９）。また、フローデータ処理部５３は、マージ後のフローデータからハッシュ値を計算し（ステップＳ１０１）、マージ後のフローデータと対応して格納する。そして、マージ処理部５７は、マージ完了通知をフローデータの送信元に送信する（ステップＳ１０３）。その後、処理を終了する。
　一方、ステップＳ９５において、抽出ＩＤに対応するフローデータがフローデータ格納部５５に格納されていないと判断された場合（ステップＳ９５：Ｎｏルート）、マージ処理部５７は、マージ対象となるフローデータが存在しないため、エラー通知をフローデータの送信元に送信する（ステップＳ１０５）。そして、処理を終了する。
　次に、図２６を用いて、集計に関連する処理を説明する。なお、プロセスサーバ５は、定期的又は任意のタイミングにて図２６に示すような処理を実施する。フローデータ処理部５３は、フローデータに対応して格納されているハッシュ値を読み出し、同一ハッシュ値毎に当該ハッシュ値に係るフローデータの件数を計数し、集計結果を記憶装置に格納する（図２６：ステップＳ１１１）。また、フローデータ処理部５３は、マスタサーバ３からハッシュ値取得要求を受信したか判断する（ステップＳ１１３）。ハッシュ値取得要求を受信している場合（ステップＳ１１３：Ｙｅｓルート）、フローデータに対応して格納されているハッシュ値を読み出し、マスタサーバ３に送信する（ステップＳ１１５）。その後、処理を終了する。一方、ハッシュ値取得要求を受信していなければ（ステップＳ１１３：Ｎｏルート）、ステップＳ１１５の処理をスキップし、処理を終了する。
　以上のような処理を実施することにより、なんらかの理由で同一ＩＤの業務イベントが複数のプロセスサーバ５に分散されても、その後自動的にマージすることができ、結果として複数のプロセスサーバ５の各々で完全なプロセスインスタンスを分散して生成することができるようになる。また、正しい集計結果を得ることができるようになる。
　以上本技術の一実施の形態を説明したが、本技術はこれに限定されるものではない。例えば、上で説明したマスタサーバ３及びプロセスサーバ５の機能ブロック図は必ずしも実際のプログラムモジュール構成に対応するものではない。さらに、処理フローにおいても、処理結果が変わらなければ処理の順番を入れ替えることも可能である。さらに、並列に実行させるようにしても良い。
　また、格納先及びマージ先を決定する方式は、上で述べた方式に限られない。例えば、フローデータ格納部５５のデータ量に応じて、問い合わせに対する応答を遅らせるようにし、最も早く応答を返してきたプロセスサーバ５を格納先又はマージ先として決定するようにしてもよい。また、例えば、マスタサーバ３において、各プロセスサーバ５に対して過去に割り振ったイベントデータのＩＤをテーブルなどに記憶しておき、割り振った数の少ないプロセスサーバ５を格納先又はマージ先として決定するようにしてもよい。さらに、例えば、前回マージ指示を送信してから所定期間内であれば、当該マージ指示に係るマージ元及びマージ先のプロセスサーバ５は、マージ処理中であるため、格納先又はマージ先の候補から外すようにしてもよい。
　また、上では、イベントデータを抽出した後に、フローデータの保持状況の問い合わせを行っていたが、例えば、一時的に利用不可のプロセスサーバ５があった場合、マスタサーバ３が、当該プロセスサーバ５が復帰するまでの間に割り振りを行ったイベントデータのＩＤを記憶しておき、復帰後に当該プロセスサーバに対して、記憶したＩＤに係るフローデータの保持状況の問い合わせを行うようにしてもよい。
　また、上では、各プロセスサーバ５が、マスタサーバ３にハッシュ値を送信していたが、ハッシュ値の代わりに、ステップＳ１１１において集計した各フローデータの件数をマスタサーバ３に送信するようにしてもよい。この場合、マスタサーバ３は、各プロセスサーバ５からの、フローデータの件数を集計し、全体の集計結果を求めるようにすればよい。
　以上本実施の形態をまとめると以下のようになる。
　本業務フロー分散処理システムは、実施された一連の業務イベントを時系列に並べたプロセスインスタンスを生成する手段を各々有する複数のプロセスサーバと、イベント名と処理時刻とプロセスインスタンスを識別するための識別子とを含み且つ業務イベントに関するイベントデータをイベントデータ格納部から順次読み出し、複数のプロセスサーバのいずれかに割り振るマスタサーバとを有する。そして、上で述べたマスタサーバは、イベントデータ格納部から読み出したイベントデータに含まれる識別子に対応するプロセスインスタンスの保持状況の問い合わせを複数のプロセスサーバに出力する手段と、複数のプロセスサーバから問い合わせに対する応答を受信し、問い合わせに係るプロセスインスタンスを保持している第１プロセスサーバが複数存在するか判断する手段と、第１プロセスサーバが複数存在する場合、第１プロセスサーバの中から問い合わせに係るプロセスインスタンスのマージ先となる第２プロセスサーバを決定する手段と、第２プロセスサーバの情報と問い合わせに係るプロセスインスタンスの識別子とを含むマージ指示を第１プロセスサーバに出力する手段とを有する。さらに、上で述べた複数のプロセスサーバの各々は、イベントデータを含むプロセスインスタンスを識別子に対応して格納するプロセスインスタンスデータ格納部と、マスタサーバから問い合わせを受信した場合、プロセスインスタンスデータ格納部を問い合わせに係る識別子で検索し、当該問い合わせに係るプロセスインスタンスの有無をマスタサーバに応答する手段と、マスタサーバからマージ指示を受信し且つ自身が第２プロセスサーバ以外の第１プロセスサーバである場合、マージ指示に含まれる識別子に係るイベントデータをマージ指示に含まれる第２プロセスサーバに出力する手段と、他のプロセスサーバからイベントデータを受信した場合、プロセスインスタンスデータ格納部に格納され且つ当該イベントデータと同一の識別子に対応するプロセスインスタンスに当該イベントデータをマージするマージ手段とを有する。
　このようにすれば、なんらかの理由で同一ＩＤの業務イベントが複数のプロセスサーバに分散されても、自動的にマージすることができ、各プロセスサーバは、完全なプロセスインスタンスを生成することができる。
　また、上で述べたマージ手段は、マージ完了通知をイベントデータの送信元に出力する手段を有する場合もある。そして、上で述べた複数のプロセスサーバの各々は、第２プロセスサーバからマージ完了通知を受信した場合、マージ指示に対応するプロセスインスタンスをプロセスインスタンスデータ格納部から削除する手段をさらに有するようにしてもよい。
　このようにすれば、マージが完了するまで、マージ元のプロセスサーバにおけるプロセスインスタンスは削除されないため、マージ漏れをなくすことができる。
　さらに、上で述べた複数のプロセスサーバの各々は、プロセスインスタンスデータ格納部に格納されている各プロセスインスタンスについて、当該プロセスインスタンスからハッシュ値を計算し、記憶装置に格納する手段をさらに有するようにしてもよい。
　また、上で述べた複数のプロセスサーバの各々は、同一のハッシュ値毎に当該ハッシュ値に係るプロセスインスタンスの件数を計数する手段をさらに有するようにしてもよい。
　また、上で述べたマスタサーバは、複数のプロセスサーバの各々からハッシュ値を取得し、同一のハッシュ値毎に当該ハッシュ値に係るプロセスインスタンスの件数を計数する手段をさらに有するようにしてもよい。
　なお、本業務フロー分散処理システムは、プログラムが上記処理をハードウエアに実行させることによって実現可能であり、当該プログラムは、例えばフレキシブル・ディスク、ＣＤ－ＲＯＭ、光磁気ディスク、半導体メモリ、ハードディスク等のコンピュータ読み取り可能な記憶媒体又は記憶装置に格納される。また、ネットワークを介してディジタル信号にて頒布される場合もある。なお、処理途中のデータについては、コンピュータのメモリ等の記憶装置に一時保管される。
　なお、マスタサーバ３及びプロセスサーバ５は、図２７のようなコンピュータ装置であって、メモリ２５０１（記憶装置）とＣＰＵ２５０３（処理装置）とハードディスク・ドライブ（ＨＤＤ）２５０５と表示装置２５０９に接続される表示制御部２５０７とリムーバブル・ディスク２５１１用のドライブ装置２５１３と入力装置２５１５とネットワークに接続するための通信制御部２５１７とがバス２５１９で接続されている。オペレーティング・システム（ＯＳ：Operating System）及び本実施の形態における処理を実施するためのアプリケーション・プログラムは、ＨＤＤ２５０５に格納されており、ＣＰＵ２５０３により実行される際にはＨＤＤ２５０５からメモリ２５０１に読み出される。必要に応じてＣＰＵ２５０３は、表示制御部２５０７、通信制御部２５１７、ドライブ装置２５１３を制御して、必要な動作を行わせる。また、処理途中のデータについては、メモリ２５０１に格納され、必要があればＨＤＤ２５０５に格納される。本技術の実施の形態では、上で述べた処理を実施するためのアプリケーション・プログラムはコンピュータ読み取り可能なリムーバブル・ディスク２５１１に格納されて頒布され、ドライブ装置２５１３からＨＤＤ２５０５にインストールされる。インターネットなどのネットワーク及び通信制御部２５１７を経由して、ＨＤＤ２５０５にインストールされる場合もある。このようなコンピュータ装置は、上で述べたＣＰＵ２５０３、メモリ２５０１などのハードウエアとＯＳ及び必要なアプリケーション・プログラムとが有機的に協働することにより、上で述べたような各種機能を実現する。

Claims (6)

  1. 　実施された一連の業務イベントを時系列に並べたプロセスインスタンスを生成する手段を各々有する複数のプロセスサーバと、
    　イベント名と処理時刻と前記プロセスインスタンスを識別するための識別子とを含み且つ前記業務イベントに関するイベントデータをイベントデータ格納部から順次読み出し、前記複数のプロセスサーバのいずれかに割り振るマスタサーバと、
    　を有し、
    　前記マスタサーバは、
    　前記イベントデータ格納部から読み出した前記イベントデータに含まれる前記識別子に対応するプロセスインスタンスの保持状況の問い合わせを前記複数のプロセスサーバに出力する手段と、
    　前記複数のプロセスサーバから前記問い合わせに対する応答を受信し、前記問い合わせに係るプロセスインスタンスを保持している第１プロセスサーバが複数存在するか判断する手段と、
    　前記第１プロセスサーバが複数存在する場合、前記第１プロセスサーバの中から前記問い合わせに係るプロセスインスタンスのマージ先となる第２プロセスサーバを決定する手段と、
    　前記第２プロセスサーバの情報と前記問い合わせに係るプロセスインスタンスの前記識別子とを含むマージ指示を前記第１プロセスサーバに出力する手段と、
    　を有し、
    　前記複数のプロセスサーバの各々は、
    　前記イベントデータを含む前記プロセスインスタンスを前記識別子に対応して格納するプロセスインスタンスデータ格納部と、
    　前記マスタサーバから前記問い合わせを受信した場合、前記プロセスインスタンスデータ格納部を前記問い合わせに係る前記識別子で検索し、当該問い合わせに係るプロセスインスタンスの有無を前記マスタサーバに応答する手段と、
    　前記マスタサーバから前記マージ指示を受信し且つ自身が前記第２プロセスサーバ以外の前記第１プロセスサーバである場合、前記マージ指示に含まれる前記識別子に係る前記イベントデータを前記マージ指示に含まれる前記第２プロセスサーバに出力する手段と、
    　他のプロセスサーバから前記イベントデータを受信した場合、前記プロセスインスタンスデータ格納部に格納され且つ当該イベントデータと同一の前記識別子に対応するプロセスインスタンスに当該イベントデータをマージするマージ手段と、
    　を有する業務フロー分散処理システム。
  2. 　前記マージ手段は、
    　マージ完了通知を前記イベントデータの送信元に出力する手段
    　を有し、
    　前記複数のプロセスサーバの各々は、
    　前記第２プロセスサーバから前記マージ完了通知を受信した場合、前記マージ指示に対応するプロセスインスタンスを前記プロセスインスタンスデータ格納部から削除する手段
    　をさらに有する請求項１記載の業務フロー分散処理システム。
  3. 　前記複数のプロセスサーバの各々は、
    　前記プロセスインスタンスデータ格納部に格納されている各前記プロセスインスタンスについて、当該プロセスインスタンスからハッシュ値を計算し、記憶装置に格納する手段
    　をさらに有する請求項１記載の業務フロー分散処理システム。
  4. 　前記複数のプロセスサーバの各々は、
    　同一の前記ハッシュ値毎に当該ハッシュ値に係る前記プロセスインスタンスの件数を計数する手段
    　をさらに有する請求項３記載の業務フロー分散処理システム。
  5. 　前記マスタサーバは、
    　前記複数のプロセスサーバの各々から前記ハッシュ値を取得し、同一の前記ハッシュ値毎に当該ハッシュ値に係る前記プロセスインスタンスの件数を計数する手段
    　をさらに有する請求項３記載の業務フロー分散処理システム。
  6. 　実施された一連の業務イベントを時系列に並べたプロセスインスタンスを前記プロセスインスタンスを識別するための識別子と対応して格納するプロセスインスタンスデータ格納部を各々有する複数のプロセスサーバと、イベント名と処理時刻と前記識別子とを含み且つ前記業務イベントに関するイベントデータをイベントデータ格納部から順次読み出し、前記複数のプロセスサーバのいずれかに割り振るマスタサーバとを有するシステムにおいて実行される業務フロー分散処理方法であって、
    　前記マスタサーバにより、前記イベントデータ格納部から読み出した前記イベントデータに含まれる前記識別子に対応するプロセスインスタンスの保持状況の問い合わせを前記複数のプロセスサーバに出力するステップと、
    　前記プロセスサーバにより、前記マスタサーバから前記問い合わせを受信した場合、前記プロセスインスタンスデータ格納部を前記問い合わせに係る前記識別子で検索し、当該問い合わせに係るプロセスインスタンスの有無を前記マスタサーバに応答するステップと、
    　前記マスタサーバにより、前記複数のプロセスサーバから前記問い合わせに対する応答を受信し、前記問い合わせに係るプロセスインスタンスを保持している第１プロセスサーバが複数存在するか判断するステップと、
    　前記マスタサーバにより、前記第１プロセスサーバが複数存在する場合、前記第１プロセスサーバの中から前記問い合わせに係るプロセスインスタンスのマージ先となる第２プロセスサーバを決定するステップと、
    　前記マスタサーバにより、前記第２プロセスサーバの情報と前記問い合わせに係るプロセスインスタンスの前記識別子とを含むマージ指示を前記第１プロセスサーバに出力するステップと、
    　前記プロセスサーバにより、前記マスタサーバから前記マージ指示を受信し且つ自身が前記第２プロセスサーバ以外の前記第１プロセスサーバである場合、前記マージ指示に含まれる前記識別子に係る前記イベントデータを前記マージ指示に含まれる前記第２プロセスサーバに出力するステップと、
    　前記プロセスサーバにより、他のプロセスサーバから前記イベントデータを受信した場合、前記プロセスインスタンスデータ格納部に格納され且つ当該イベントデータと同一の前記識別子に対応するプロセスインスタンスに当該イベントデータをマージするステップと、
    　を含む業務フロー分散処理方法。
PCT/JP2008/064628 2008-08-15 2008-08-15 業務フロー分散処理システム及び方法 WO2010018637A1 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
PCT/JP2008/064628 WO2010018637A1 (ja) 2008-08-15 2008-08-15 業務フロー分散処理システム及び方法
JP2010524648A JP5024453B2 (ja) 2008-08-15 2008-08-15 業務フロー分散処理システム及び方法
EP08809000A EP2325791A4 (en) 2008-08-15 2008-08-15 SYSTEM AND METHOD FOR DISTRIBUTED WORKFLOW PROCESSING
US13/023,118 US8583754B2 (en) 2008-08-15 2011-02-08 Business flow distributed processing system and method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2008/064628 WO2010018637A1 (ja) 2008-08-15 2008-08-15 業務フロー分散処理システム及び方法

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US13/023,118 Continuation US8583754B2 (en) 2008-08-15 2011-02-08 Business flow distributed processing system and method

Publications (1)

Publication Number Publication Date
WO2010018637A1 true WO2010018637A1 (ja) 2010-02-18

Family

ID=41668791

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2008/064628 WO2010018637A1 (ja) 2008-08-15 2008-08-15 業務フロー分散処理システム及び方法

Country Status (4)

Country Link
US (1) US8583754B2 (ja)
EP (1) EP2325791A4 (ja)
JP (1) JP5024453B2 (ja)
WO (1) WO2010018637A1 (ja)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120030332A1 (en) * 2010-07-28 2012-02-02 Pfu Limited Management server, information processing device and computer-readable medium
CN107924344A (zh) * 2015-09-01 2018-04-17 微软技术许可有限责任公司 与旧式客户端的互操作
CN109995665A (zh) * 2019-03-29 2019-07-09 新华三信息安全技术有限公司 一种业务数据存储方法及装置

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9773218B2 (en) 2013-07-30 2017-09-26 Red Hat, Inc. Segmented business process engine
CN105930262B (zh) * 2016-03-02 2018-04-20 平安科技（深圳）有限公司 应用程序用户界面自动化测试方法及电子设备
CN114697888B (zh) * 2022-03-28 2023-10-31 中国联合网络通信集团有限公司 5g消息处理方法、装置及存储介质

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH11213082A (ja) * 1997-11-19 1999-08-06 Fujitsu Ltd ワークフロー管理装置及びワークフロー管理システム並びにこれらのプログラムを記憶したコンピュータ読み取り可能な記憶媒体
JP2004258823A (ja) * 2003-02-25 2004-09-16 Hitachi Ltd ビジネスプロセス処理方法およびシステム並びにその処理プログラム
JP2006178935A (ja) * 2004-12-22 2006-07-06 Microsoft Corp ワークフロートランザクションのバッチ処理によるランタイムおよびアプリケーションの状態の同期化

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0895874A (ja) 1994-09-20 1996-04-12 Hitachi Ltd リモートプロシジャコール処理方法
EP1131976A1 (en) * 1998-11-18 2001-09-12 Lightbridge, Inc. Event manager for use in fraud detection
US7131113B2 (en) * 2002-12-12 2006-10-31 International Business Machines Corporation System and method on generating multi-dimensional trace files and visualizing them using multiple Gantt charts
JP4287234B2 (ja) * 2003-10-03 2009-07-01 富士通株式会社 業務プロセストラッキング装置，業務プロセストラッキング方法，業務プロセストラッキングプログラム，業務プロセストラッキングプログラムを記録した記録媒体
US20050171833A1 (en) * 2003-10-28 2005-08-04 Wolfram Jost Systems and methods for acquiring time-dependent data for business process analysis
EP2063384A4 (en) * 2006-09-15 2011-07-13 Fujitsu Ltd INFORMATION PROCESSING AND DEVICE FOR WORKING PROCESS ANALYSIS
CN101785302B (zh) * 2007-08-24 2013-07-17 Lg电子株式会社 数字广播系统和在数字广播系统中处理数据的方法
EP2215770B1 (en) * 2007-10-18 2013-03-20 Telefonaktiebolaget L M Ericsson (publ) Merging of overlay networks in distributed data structures
US8560372B2 (en) * 2007-12-22 2013-10-15 Sap Ag Compiling workflows into instructions for a state correlation engine
US8214170B2 (en) * 2009-01-15 2012-07-03 International Business Machines Corporation Test pattern compression

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH11213082A (ja) * 1997-11-19 1999-08-06 Fujitsu Ltd ワークフロー管理装置及びワークフロー管理システム並びにこれらのプログラムを記憶したコンピュータ読み取り可能な記憶媒体
JP2004258823A (ja) * 2003-02-25 2004-09-16 Hitachi Ltd ビジネスプロセス処理方法およびシステム並びにその処理プログラム
JP2006178935A (ja) * 2004-12-22 2006-07-06 Microsoft Corp ワークフロートランザクションのバッチ処理によるランタイムおよびアプリケーションの状態の同期化

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
See also references of EP2325791A4 *
TOMOTAKA IKAWA ET AL.: "Bunsan Dokuritsu Active Database Jo deno Workflow-yo Transaction Model", IEICE TECHNICAL REPORT, DE2000-71 TO 90, vol. 100, no. 288, 21 July 2000 (2000-07-21), pages 119 - 125, XP008143172 *

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120030332A1 (en) * 2010-07-28 2012-02-02 Pfu Limited Management server, information processing device and computer-readable medium
CN107924344A (zh) * 2015-09-01 2018-04-17 微软技术许可有限责任公司 与旧式客户端的互操作
CN107924344B (zh) * 2015-09-01 2022-04-19 微软技术许可有限责任公司 与旧式客户端互操作的方法以及服务器系统
CN109995665A (zh) * 2019-03-29 2019-07-09 新华三信息安全技术有限公司 一种业务数据存储方法及装置
CN109995665B (zh) * 2019-03-29 2022-03-22 新华三信息安全技术有限公司 一种业务数据存储方法及装置

Also Published As

Publication number Publication date
EP2325791A1 (en) 2011-05-25
JP5024453B2 (ja) 2012-09-12
JPWO2010018637A1 (ja) 2012-01-26
EP2325791A4 (en) 2012-08-01
US8583754B2 (en) 2013-11-12
US20110138007A1 (en) 2011-06-09

Similar Documents

Publication Publication Date Title
CN103248645B (zh) Bt离线数据下载系统及方法
CN113067883B (zh) 数据传输方法、装置、计算机设备及存储介质
US11394794B2 (en) Fast ingestion of records in a database using data locality and queuing
US8190599B2 (en) Stream data processing method and system
JP5024453B2 (ja) 業務フロー分散処理システム及び方法
JP5245711B2 (ja) 分散データ処理システム、分散データ処理方法および分散データ処理用プログラム
US20070050425A1 (en) Log management program of a computer, log management method thereof, and computer system
CN112765152B (zh) 用于合并数据表的方法和装置
CN109325200B (zh) 获取数据的方法、装置及计算机可读存储介质
US20100106436A1 (en) Power consumption calculation facility
US10009220B2 (en) In-vehicle information system and information processing method thereof
CN105930502B (zh) 一种收集数据的系统、客户端和方法
US20120072589A1 (en) Information Processing Apparatus and Method of Operating the Same
US10789307B2 (en) Cloud-based discovery and inventory
CN109657167B (zh) 数据采集方法、装置、服务器及存储介质
US9853933B2 (en) Message queue replication with message ownership migration
US20090313230A1 (en) Computing job information managing device, terminal, and computing job information managing system
US8700954B2 (en) Common trouble case data generating method and non-transitory computer-readable medium storing common trouble case data generating program
CN111241044B (zh) 搭建异构数据库的方法、装置、设备及可读存储介质
WO2014075425A1 (zh) 数据处理方法、计算节点及系统
JP6048555B1 (ja) 分類情報作成装置、分類情報作成方法、分類情報作成プログラム、検索装置、検索方法、及び、検索プログラム
KR102128389B1 (ko) 클라우드 기반의 데이터 처리 장치, 방법 및 클라우드 기반의 데이터 처리 서비스를 제공받는 사용자 단말
JP2020166504A (ja) データ提供システムおよびデータアクセス方法
JP5998527B2 (ja) 情報処理装置及び情報処理プログラム
US20160309006A1 (en) Non-transitory computer-readable recording medium and distributed processing method

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 08809000

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2010524648

Country of ref document: JP

WWE Wipo information: entry into national phase

Ref document number: 2008809000

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE