JP2007265029A - Job management apparatus and job management method - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To develop and operate an enterprise system, based on an object-oriented language. <P>SOLUTION: An Uriage Processing Model class 440 defines relations among job objects by means of a Connection class 430. The Uriage Processing Model class 440 manages jobs and their dependency relations though job class groups 420 and the Connection class 430. A flow control unit 150 injects processing into the respective job objects. When a Multi Thread Flow Controller class 452 is selected as an execution model from the job objects, different worker threads are assigned to the respective jobs and the respective jobs are executed in parallel in terms of time. <P>COPYRIGHT: (C)2008,JPO&INPIT

Description

  The present invention relates to a technique for controlling execution of a job, and more particularly to a technique for controlling execution of a plurality of jobs having dependency relationships.

  Enterprise systems that support the operation of enterprises and public facilities are now being introduced as infrastructure systems for large and small organizations. An enterprise system aggregates, accumulates, analyzes, and processes data obtained from node terminals and databases, and outputs information with higher added value. Enterprise systems continue to evolve to make more complex organization management more efficient.

  Such enterprise systems are often modeled as a collection of jobs. A job is a process that is a basic execution unit in the system, such as a database update process and a calculation process for data obtained from each node terminal. These jobs are designed in such a manner that they have a dependency relationship so that the job corresponding to the subsequent stage is executed based on the output data of the job corresponding to the preceding stage.

In building an enterprise system, a procedural language such as COBOL (COmmon Business Oriented Language) is widely used. Since the grammar is simple, COBOL is a well-proven language in the processing model of processing jobs sequentially like an enterprise system.
JP-A-7-129415

On the other hand, object-oriented languages such as JAVA (registered trademark) and C ++ are rapidly spreading in the field of software development. An object-oriented language encapsulates data and an interface for accessing the data as a class. Because data is protected by a kind of structure called a class, object-oriented languages are superior to procedural languages in terms of code reusability, maintainability, and robustness. As object-oriented languages become widespread, JAVA (registered trademark) programmers are increasing more in development sites than COBOL programmers. In particular, in East Asian countries such as China, Taiwan and India, JAVA (registered trademark) programmers are easier to secure than COBOL programmers. In addition, there is a recent situation that many skilled COBOL programmers leave the field due to the so-called 2007 problem where baby boomers retire all at once.
From such a background, the present inventor has recognized that the necessity of developing an enterprise system by JAVA (registered trademark) is becoming apparent.

  However, in order to exert the superiority of an object-oriented language in an enterprise system that often takes a form of batch processing a large amount of data, it is necessary to be based on a design philosophy that is different from the design philosophy of a procedural language. A feature of object-oriented languages is software componentization, and the usefulness of the class depends on how the class functions are defined. The present inventor has conceived that the superiority can be suitably exhibited by providing a new framework for designing an enterprise system on the premise of an object-oriented language.

  The present invention has been made in view of such a situation, and the main object thereof is a technique for efficiently designing a system for executing and controlling a plurality of jobs based on an object-oriented language, and a plurality of jobs. The object is to provide a technique for efficient execution.

An aspect of the present invention is a job management apparatus for executing a plurality of jobs whose dependency relationships are determined so that a job corresponding to a subsequent stage is executed based on output data of a job corresponding to the preceding stage.
This apparatus generates a job object from a class defined in advance according to the type of job, and generates job list information indicating the dependency of each job object. Then, after the job object is created, a processing function indicating the job processing content is set, and after assigning different threads to multiple processing functions, these multiple processing functions are executed in parallel in time. Let
In the relationship between the job object corresponding to the previous stage and the job object corresponding to the subsequent stage, the processing function of the job object corresponding to the subsequent stage executes predetermined processing using the output data generated by the processing function of the job object corresponding to the previous stage as a variable, and the output data is not generated. The stage waits until output data is generated.

  It should be noted that any combination of the above-described components and a representation of the present invention by a method, apparatus, system, recording medium, and computer program are also effective as an aspect of the present invention.

  The present invention is effective in efficiently designing and operating a job execution control system based on an object-oriented language.

FIG. 1 is a hardware configuration diagram of the enterprise system 204.
The enterprise system 204 is a system introduced for business management of an organization such as a company or a public facility. The enterprise system 204 may be configured as a system that integrates a plurality of geographically dispersed organizations.

The enterprise system 204 in this embodiment includes a job management apparatus 100, a node terminal 200, and a database 206. These are connected to each other via the Internet 202.
The job management apparatus 100 sequentially executes a plurality of jobs according to a data flow diagram (DFD: Data Flow Diagram) that defines the relationship between the jobs. A data flow diagram (hereinafter also referred to as “DFD”) will be described later in detail with reference to FIG. Further, the function of the job management apparatus 100 will be described in detail with reference to FIG.

  The node terminal 200 is a computer terminal used by a user for performing business. The node terminal 200 acquires various business data. The job management apparatus 100 transmits and receives data to and from the node terminal 200 and the database 206 when executing a job. The job management apparatus 100 executes various jobs based on data acquired from the node terminal 200 or the database 206.

  In summary, the job management apparatus 100 executes various jobs using data obtained from the node terminal 200 and the database 206 as variables. The job management apparatus 100 can also integrally control the execution timing of each job. In this manner, the enterprise system 204 as a whole is operated by sequentially executing jobs whose processing contents are defined in advance based on data obtained from the node terminal 200 and the database 206.

FIG. 2 is a functional block diagram of the job management apparatus 100.
Each block shown here can be realized in hardware by an element such as a CPU of a computer or a mechanical device, and in software it is realized by a computer program or the like. Draw functional blocks. Therefore, those skilled in the art will understand that these functional blocks can be realized in various forms by a combination of hardware and software.
Here, functions to be exhibited by each functional block will be mainly described, and specific actions thereof will be described with reference to FIG.

The job management apparatus 100 includes a user interface processing unit 110, a communication unit 120, and a data processing unit 130.
The user interface processing unit 110 is in charge of processing related to the entire user interface such as input processing from the user and information display for the user. The communication unit 120 is in charge of communication processing with the node terminal 200 and the database 206. The data processing unit 130 executes various types of data processing based on data acquired from the user interface processing unit 110 and the communication unit 120. The data processing unit 130 also serves as an interface between the user interface processing unit 110 and the communication unit 120.

The data processing unit 130 includes a model management unit 140 and a flow control unit 150.
The model management unit 140 manages data related to a “static model” indicating the dependency relationship of each job. The flow control unit 150 defines the processing contents of each job and controls the execution of each job. It should be noted that in the job management apparatus 100 according to the present embodiment, the model management unit 140 that manages the static dependency relationship of the job and the flow control unit 150 that manages the dynamic processing content of the job are functionally related. It is to be separated. Therefore, the “definition of dependency” and “definition of processing contents” of a job have a framework (framework) in which one design work is not restricted by the other design contents.
Based on the above, a more specific software structure will be described.

FIG. 3 is a diagram showing a data flow diagram 312 in the present embodiment.
A data flow diagram 312 shown in the figure shows a process of calculating the number of sales for each region and each store by summing up the number of CDs sold at four CD (Compact Disc) stores in a predetermined period. . In this data flow diagram 312, six components (Entity) are defined: sales data 300, sales aggregation processing 302, district-specific sales data 304, store master data 306, store name addition processing 308, and store-specific sales data 310. Yes.

  Sales data 300 is data indicating the number of CDs sold at four CD stores. Here, in order to identify the CD stores, “store IDs” indicated as “01” to “04” are assigned to the respective CD stores. Further, in order to identify the district to which each CD store belongs, each district is given a “district ID” indicated as “A” or “B”. According to the sales data 300, CD stores “01” and “02” belong to the “A” district, and CD stores “03” and “04” belong to the “B” district. Here, two node terminals 200 are installed in the CD store “01”, and “1” and “2” are input as the number of CD sales from each node terminal 200. Similarly, two node terminals 200 are also installed in CD stores “02” and “04”. That is, the sales data 300 is data obtained from two districts, four CD stores, and seven node terminals 200.

  In the sales aggregation process 302, the sales data 300 obtained from the node terminal 200 installed in each CD store is collected, and the number of CD sales for each CD store is calculated. Information relating to the number of CDs sold for each CD store (hereinafter referred to as “intermediate data”) is passed to the store name adding process 308. On the other hand, the sales data 304 for each district is generated by calculating the number of CD sales for each district.

  The store name addition processing 308 generates store-specific sales data 310 based on the intermediate data received from the sales aggregation processing 302 and the store master data 306. The store master data 306 is data that associates a store ID with a store name, and is data obtained from the database 206. The sales data 310 for each store is data obtained by tabulating the number of CDs sold for each CD store, and includes not only the store ID but also the corresponding store name.

  Suppose that the data flow diagram 312 is implemented by COBOL. COBOL is not a language designed for a multi-thread environment. Therefore, when the sales aggregation process 302 and the store name addition process 308 are defined as multitask processes, the memory space of the sales aggregation process 302 and the memory space of the store name addition process 308 are allocated separately. Therefore, the sales aggregation processing 302 is a processing method in which the intermediate data is once converted into a file, and the store name addition processing 308 reads the intermediate data from this file.

  On the other hand, JAVA (registered trademark), which is a programming language used in the present embodiment, is a language designed with sufficient assumption that it will be used in a multi-thread environment. Therefore, even when the sales aggregation processing 302 and the store name addition processing 308 are defined as multitask processing, each processing can be executed by separate threads. Since the memory sharing between threads belonging to the same process space is simple, the sales aggregation processing 302 can pass the intermediate data to the store name addition processing 308 without having to bother creating a file. The superiority and feasibility of such multithread will be described in detail later.

  In the present embodiment, six components included in the data flow diagram 312 are defined as “jobs”, and a class (hereinafter also referred to as “job class”) is defined for each job. The flow control unit 150 sets the processing content of an object (hereinafter also referred to as “job object”) generated by instantiating a job class. In the following, an object generated by instantiating “X class (“ X ”is a character string)” is simply referred to as “X object”.

FIG. 4 is a diagram illustrating the dependency relationship of the job class corresponding to the DFD of FIG.
The UriageSource class 400 is a job class corresponding to the sales data 300, and is a class that collects and holds the sales data 300 from the node terminals 200 of each CD store. The UriageAggregator class 402 is a job class corresponding to the sales aggregation process 302. Similarly, the AreaUriageTotalSink class 404 is a job class corresponding to the district sales data 304, the MiseMaSource class 406 is a store master data 306, the MiseMaMatcher class 408 is a store name addition process 308, and the MiseUriageTotalSink class 410 is a job class corresponding to the store sales data 310. .

When the sales data 300 is passed to the UriageSource class 400 and the process for instantiating the UriageAggregator class 402 is directly described, the connection between the UriageSource class 400 and the UriageAggregator class 402 becomes strong. If the connection between job classes becomes strong, it is not desirable because a change in dependency or processing contents of a certain job class easily affects the performance of many other job classes. In other words, in order to design a job class with excellent reusability, maintainability, and robustness, it is desirable that the coupling between job classes is weak.
Therefore, in the present embodiment, a method of “injecting processing” by the NodeFlowController class 500 described later is adopted for each job class from the UriageSource class 400 to the MiseUriageTotalSink class 410. In other words, the job class itself is designed in a form that does not have any dependency in nature.

FIG. 5 is a schematic diagram illustrating the relationship of classes for realizing the basic functions of the job management apparatus 100. This will be described in detail with reference to FIGS. 6 and 7 below. In FIG.
The UriageProcessingModel class 440 is a class that defines the relationship between the job classes shown in the data flow diagram 312. The UriageProcessingModel class 440 has a job class group 420 including the six job classes shown in FIG. The rhombus symbols shown in the figure indicate “aggregation” based on the UML (Unified Modeling Language) notation. That is, the UriageProcessingModel class 440 has a job class group 420 as a part thereof. Therefore, when the UriageProcessingModel class 440 is instantiated, the job class group 420 that is a part thereof is also instantiated. The UriageProcessingModel object will have each job object.

  The UriageProcessingModel class 440 also has a Connection class 430. The Connection class 430 is a class that manages the dependency relationship of each job class in the job class group 420 as a list (hereinafter, such a class is referred to as a “relationship class”). The UriageProcessingModel class 440 manages jobs and their dependencies using the functions of the job class group 420 and the Connection class 430.

  The SingleThreadFlowController class 450 and the MultiThreadFlowController class 452 are classes that define the processing content of each job class. The enterprise system 204 is actually driven by the functions of the SingleThreadFlowController class 450 and the MultiThreadFlowController class 452. The SingleThreadFlowController class 450 is a class that drives the enterprise system 204 in a single thread model. The MultiThreadFlowController class 452 is a class that drives the enterprise system 204 in a multi-thread model. At the start of processing of the enterprise system 204, one of the execution models of the SingleThreadFlowController class 450 and the MultiThreadFlowController class 452 is selected by the user. The execution model selection method will be described in detail with reference to FIG.

  The SingleThreadFlowController class 450 and the MultiThreadFlowController class 452 both have a UriageProcessingModel class 440. More strictly, a reference to the UriageProcessingModel class 440 is set in the SingleThreadFlowController class 450 and the MultiThreadFlowController class 452, but in this specification, it is defined as “having” including the reference. Therefore, when the execution model of either the SingleThreadFlowController class 450 or the MultiThreadFlowController class 452 is selected and the UriageProcessingModel class 440 is instantiated, the job class group 420 and the Connection class 430 are further instantiated in a chain. Become.

Compared with the functional block diagram shown in FIG. 2, the function of the model management unit 140 is realized by the functions of the UriageProcessingModel class 440, the job class group 420, and the Connection class 430, and the function of the flow control unit 150 is the SingleThreadFlowController class 450. Alternatively, it is realized by the function of the MultiThreadFlowController class 452. Hereinafter, a class that defines job contents and their dependencies such as the UriageProcessingModel class 440 is referred to as a “model class”, and a class that defines job processing contents such as the SingleThreadFlowController class 450 and the MultiThreadFlowController class 452 is referred to as a “control class”. "
In the following, a multithread model based on the MultiThreadFlowController class 452 will be described as a subject. For reference, the single thread model is detailed in Japanese Patent Application No. 2005-350643, which is a related case of this case.

FIG. 6 is a class diagram showing the relationship between the job class and the model class.
As shown in FIG. 4, the UriageProcessingModel class 440 has six job classes from the UriageSource class 400 to the MiseUriageTotalSink class 410. The UriageProcessingModel class 440 itself is included in the MultiThreadFlowController class 452. The UriageProcessingModel class 440 is a model class that inherits the ProcessingModel class 460. That is, the UriageProcessingModel class 440 is defined as a class to which a specific function is added in order to manage the sales process of the CD while inheriting the function defined in the ProcessingModel class 460. When creating the ProcessingModel class 460, it is only necessary to add a specific function to manage the sales processing of the CD. Therefore, compared to creating the UriageProcessingModel class 440 itself from scratch, the burden associated with development and maintenance is reduced. Is done. Hereinafter, a basic class that is a model class inheritance source, such as the ProcessingModel class 460, is referred to as a “model base class”. The ProcessingModel class 460 has a Connection class 430. Therefore, the UriageProcessingModel class 440 that inherits the ProcessingModel class 460 also has a Connection class 430.

Of the six job classes, the UriageSource class 400 and the MiseMaSource class 406 are job classes that inherit the RecordStreamSource class 480. The RecordStreamSource class 480 is a class in which basic specifications for managing data that is a premise of a job such as the sales data 300 and the store master data 306 are defined. The UriageAggregator class 402 inherits the RecordStreamAggregator class 482. The RecordStreamAggregator class 482 is a class in which a basic specification for a job that aggregates data like the sales aggregation process 302 is defined. The MiseMaMatcher class 408 inherits the RecordStreamMatcher class 484. The RecordStreamMatcher class 484 is a class in which basic specifications are defined for a job that combines two types of data as in the store name addition process 308. The MiseUriageTotalSink class 410 and the AreaUriageTotalSink class 404 inherit the RecordStreamSink class 486. The RecordStreamSink class 486 is a class in which basic specifications for managing data generated as a result of job processing, such as sales data by district 304 and sales data 310 by store, are defined.
As described above, the six job classes inherit any of the four types of classes (hereinafter referred to as “job base classes”). Going back further, all job base classes inherit the Node class 490. The Node class 490 is a class in which basic specifications independent of job types are defined.

  The Node class 490 has a NodeFlowController class 500. The NodeFlowController class 500 is a class for determining the processing content of a job object (hereinafter, such a class is referred to as a “processing class”). Therefore, when a job class is instantiated, a processing object is also generated for each job object. However, when the job class is instantiated, specific processing content is not set in the processing object. By the method described in detail later, when the MultiThreadFlowController class 452, that is, the control class, injects processing, specific processing contents are set.

  According to the class diagram shown in the figure, a job base class and a model base class are defined in addition to a job class and a model class corresponding to the data flow diagram 312. Therefore, when a developer designs the enterprise system 204, functions specific to the enterprise system 204 to be designed are added to the job class and model class using the basic specifications of the job base class and model base class prepared in advance. Should be defined. This makes it possible to effectively use the object-oriented language characteristic of class reusability. In the case of the enterprise system 204, since the basic specifications of hundreds or thousands of jobs can often be aggregated into several patterns, the inheritance function of the object-oriented language is particularly effective.

FIG. 7 is a class diagram regarding inheritance of processing classes.
As seen in FIG. 6, the NodeFlowController class 500 is a processing class for defining job object processing contents. The MTNodeFlowController class 502 is inherited from the NodeFlowController class 500, and further, four types of processing classes, the MTRecordStreamSource class 510, the MTRecordStreamMatcher class 512, the MTRecordStreamAggregator class 514, and the MTRecordStreamSink class 516 are inherited. The MTRecordStreamSource class 510 is a class for defining the processing contents corresponding to the RecordStreamSource class 480. The MTRecordStreamMatcher class 512, the MTRecordStreamAggregator class 514, and the MTRecordStreamSink class 516 are classes that define processing contents corresponding to the RecordStreamMatcher class 484, the RecordStreamAggregator class 482, and the RecordStreamSink class 486, respectively. The processing contents of the job class are defined by the four types of processing classes inherited from the NodeFlowController class 500.

Although not shown, the STNodeFlowController class is also inherited from the NodeFlowController class 500, and further, four types of processing classes, the STRecordStreamSource class, the STRecordStreamMatcher class, the STRecordStreamAggregator class, and the STRecordStreamSink class are inherited from the STNodeFlowController class. These classes are processing classes for the single thread model. In the case of the multi-thread model, the processing content is defined by the processing class having the MT system prefix, that is, the subclass group of the MTNodeFlowController class 502. In the case of the single thread model, the processing class having the ST system prefix, that is, The processing contents are defined by the subclass group of the STNodeFlowController class.
Based on the above class diagram, the contents of the basic processing will be described according to the processing order while referring to the sample source code. The source code shown below is described in JAVA (registered trademark).

FIG. 8 is a diagram illustrating a function that is executed first when the execution of the enterprise system is started.
The function (method) executed first is the main function (S10). The main function is a public static member function of the UriageProcessingModel class 440, and can be called from outside the UriageProcessingModel class 440. The user can select a single thread model (S12) or a multi-thread model depending on whether or not an argument is specified in the main function (S14). A description will be given assuming that an argument is specified and a multi-thread model is selected (S14).

  When the multi-thread model is selected, the doTestWithMultiThread function is executed. When the doTestWithMultiThread function is executed, the UriageProcessingModel class 440 is instantiated and a model object named testProcessingModel is generated (S100). Details of the processing executed in the instantiation will be described with reference to FIG.

  Next, the MultiThreadFlowController class 452 is instantiated, and a control object named multiThreadFlowController is generated (S200). Details of the processing executed in the instantiation will be described later with reference to FIG.

  Finally, the model object is passed as an argument to the doTask function of the control object (S300). At this time, “injection of processing” by the control object is executed for the job object managed by the model object. Detailed processing contents regarding the doTask function will be described later with reference to FIG.

  In summary, the doTestWithMultiThread function generates a model object and a control object, passes the model object to the control object, and causes the control object to execute a predetermined process.

FIG. 9 is a diagram illustrating source code executed when a model object is generated.
In S100, when the UriageProcessingModel class 440 is instantiated, first, a constructor function indicated as UriageProcessingModel () is executed (S102). Upon execution of this constructor function, each job class is instantiated (S104). Here, as the member variables of the UriageProcessingModel class 440, the job classes of the UriageSource class 400, the MiseMaSource class 406, the UriageAggregator class 402, the MiseMaMatcher class 408, the MiseUriageTotalSink class 410, and the AreaUriageTotalSink class 404 are instantiated, respectively, uriageSource, miseMaSource, uriageAggregator Job objects named miseMaMatcher, miseUriageTotalSinkr and areaUriageTotalSink are created. When each job object is generated, a processing object is generated from the NodeFlowController class 500. This is because the inheritance source Node class 490 has the NodeFlowController class 500. However, specific processing contents corresponding to each job object are not defined in the processing object at this stage. Further, when instantiating the UriageProcessingModel class 440, a relation class possessed by the model base class, that is, the Connection class 430 is also instantiated. The Connection class 430 is a class for managing the connection between job objects in a list format.

  Some job classes have a “pool class” and an “item class” which will be described later. When such a type of job class is instantiated, a pool class and an item class are also instantiated. The item class is a class for holding data acquired from the node terminal 200 and the database 206 and data transmitted and received between job objects. The pool class is a class for holding a predetermined number of item objects as an upper limit. The pool class and item class will be described in detail with reference to FIG.

  Next, the createModel function in the constructor function is executed (S106). As a result, each job object generated in S104 is registered as a node in the related object. In this way, necessary job objects and their connections are defined. In other words, the model object generates a job object that is an appearance character and a relation object indicating the relationship when the model object is generated.

FIG. 10 is a diagram showing a source code of a part corresponding to the time of generating the control object and the start of execution of the data flow.
In S200 of the doTestWithMultiThread function shown in FIG. 8, the MultiThreadFlowController class 452 is instantiated. At this time, first, a constructor function indicated as MultiThreadFlowController () is executed (S202). By executing this constructor function, a variable named model that holds an instance of the ProcessingModel class 460 is prepared (S204). Since the ProcessingModel class 460 is a model base class from which the UriageProcessingModel class 440 is inherited, a specific model related to CD sales processing is not set in the variable named model at this stage. By executing the constructor function, a control object named multiThreadFlowController is generated from the MultiThreadFlowController class 452 (S200 in FIG. 8).

  Thus, the generation of the model object and the control object shown in S100 and S200 of FIG. 8 is completed, and various objects are generated based on the classes shown in FIG. The processing up to this point is called “generation initialization processing”.

  The doTestWithMultiThread function of FIG. 8 shown above calls the doTask function of the control object when the generation initialization process ends (S300 of FIG. 8). At this time, the model object is passed as an argument of the doTask function of the control object. The model object sets the model object named testProcessingModel related to the sales process of the CD generated in S100 of FIG. 8 to the object named model generated in S204 by the setModel function (S310). In this way, the control object acquires a specific model object to be controlled.

  Next, the doTask function instantiates a “queue class” for sending and receiving item objects between job objects (S320). The queue class is a class that becomes a queue when the job object corresponding to the previous stage transfers the item object to the job object corresponding to the subsequent stage. The queue class will be described in detail with reference to FIG. Next, an injectFlowController function for injecting processing into each job object is executed (S330). The process from S310 to S330 is referred to as “injection initialization process”. Finally, the mainTask function is executed to instruct each job object that the model objects aggregate to start execution (S340).

FIG. 11 is a diagram showing source code corresponding to the processes up to S320 and S330 in FIG.
The injectRecordStream function is executed in accordance with the execution of S320 of the doTask function shown in FIG. As a result, the MTRecordStream class is instantiated as an object for passing data between job objects. This MTRecordStream class corresponds to the queue class. This class functions as a queue that holds a predetermined number of item objects input from job objects corresponding to the preceding stage as an upper limit. The job object corresponding to the latter stage acquires the item object from the queue object, and reads the data held by the item object. For example, the UriageSource object of the job object corresponding to the preceding stage stores the item object in the queue object set in relation to the UriageAggregator object of the job object corresponding to the subsequent stage, and the UriageAggregator object of the subsequent stage acquires the item object from this queue object. The basic interface for passing data between job objects is also defined on the control object side.
Next, the injectFlowController function is executed with the execution of S330 (FIG. 10) of the doTask function. The injectFlowController function scans the related objects, sequentially selects job objects, and executes the injectFlowControllerToNode function for each job object (S332).

In this injectFlowControllerToNode function, a temporary processing object nfc is generated. Next, it is determined which type of job base class the job object to be processed is inherited from. For example, when the job object to be processed inherits the RecordStreamSource class 480, a processing object that inherits the MTRecordStreamSource class 510 is set in the processing object named nfc. For example, since the UriageAggregator object is based on the RecordStreamAggregator class 482, an MTRecordStreamAggregator object is set in nfc. Thus, one of the four types of processing objects is set in the processing object nfc. Then, a processing object is set for each job object by the setTargetNode function (S334). At this stage, the processing content of the job object is determined. That is, the process is “injected” into the job object by the control object. Each processing object has a processing function named doTask function, and the content of this processing function defines the actual processing content.
Here, an algorithm for selecting a processing class to be assigned according to a job base class is shown, but an algorithm for selecting a processing class to be assigned for each job class can be arbitrarily designed. For example, the processing class to be assigned may be selected / changed according to the success or failure of a predetermined condition such as detection of an external event.

FIG. 12 is a diagram showing source code corresponding to the processing of S340 in FIG.
When the injection initialization process is completed, a mainTask function for actually operating the enterprise system 204 is executed (S340). The mainTask function scans the related objects, sequentially selects job objects, and acquires the processing objects set in each job object (S342).

  Then, the startThread function provided as a member function of the processing object is executed (S344). In this way, different threads (hereinafter referred to as “worker threads”) are assigned to the processing objects, and each job is executed in different contexts. As shown in FIG. 4, six job classes are defined in the enterprise system 204, and six processing classes are instantiated accordingly. Since there are six job objects, S344 is executed six times, and six worker threads are instructed to execute one after another. When the execution thread of the mainTask function (hereinafter referred to as “main thread”) is included, a total of seven threads are executed concurrently. Of the six worker threads, worker threads other than the MiseMaSource class 406 are registered in a list named threadList (S346).

  When the execution of the six worker threads is started, the mainTask function checks the threadList to determine whether each registered worker thread has ended by using the join function (S348). The join function is blocked if the determination target worker thread is not terminated. Therefore, if any one of the five worker threads registered in the threadList has not ended, the mainTask function is not ended by the block of the join function. When the five worker threads registered in the threadList are terminated, the main thread block by the join function is released, and the mainTask function is terminated. As a result, the processing of the entire enterprise system 204 is completed.

Worker threads for the MiseMaSource class 406 are not registered in the threadList. Therefore, even if this worker thread has not ended, the main thread can be ended. The reason why the worker thread for the MiseMaSource class 406 is not registered in the threadList is as follows.
The processing content of the MiseMaSource object is to read predetermined master data called store master data 306 and transfer it to the MiseMaMatcher object. The MiseMaSource object does not necessarily need to read all of the store master data 306, but only needs to be read for processing the MiseMaMatcher object corresponding to the subsequent stage. For this reason, the worker thread of the MiseMaSource object is excluded from the target of waiting for completion by the join function. On the other hand, the UriageSource object is a target of waiting because all sales data 300 acquired from the node terminal 200 is a processing target. That is, unless the UriageSource object acquires all of the sales data 300 and passes it to the UriageAggregator object, the mainTask does not end.

FIG. 13 is a diagram showing source code corresponding to the process of S344 of FIG.
The multi-thread processing class inherited from the MTNodeFlowController class 502 includes a startThread function as a member function. When this function is called from the MultiThreadFlowController class 452, a new worker thread is generated (S350) and the execution is started (S352). In this way, the doTask function corresponding to the processing function is executed in the worker thread.

However, whether or not a worker thread enters an execution state or a standby state after the start of execution is affected by the job dependency defined by the DFD. For example, the processing content of the MiseMaSource object is to acquire the store master data 306 from the database 206 and pass it to the subsequent MiseMaMatcher object, so the MiseMaSource object usually executes a job without being affected by the processing status of other jobs. Is possible. On the other hand, a MiseMaMatcher object cannot execute a job unless it receives data passed from a MiseMaSource object.
As described above, even if the six worker threads are started to be executed, not all of them are immediately put into the execution state, and the state transits to either the standby state or the execution state according to the processing state of other jobs. . As a result, a plurality of jobs are executed asynchronously while following the dependency defined in the DFD.

FIG. 14 is a schematic diagram for explaining a data transmission / reception method between job objects.
Dependencies between the previous stage and the subsequent stage are defined between jobs according to the definition of the relationship class. In the case of FIG. 4, the subsequent job of the MiseMaSource object is the MiseMaMatcher object, but for the MiseUriageTotalSink object, the MiseMaMatcher object is the previous job. In FIG. 14, for the sake of simplicity, description will be given for jobs 1 to 4 having a dependency relationship. Each job from job 1 to job 4 here corresponds to a job object. The subsequent job of job 1 is job 2. Jobs subsequent to job 2 are job 3 and job 4. Each job executes its own processing on the condition that data indicating the processing result is acquired from the preceding job.

  The job corresponding to the preceding stage records data in the item object, and passes the item object to the succeeding job. Between jobs, data is sent and received in a form packaged by item objects. The item class has a binary data array for storing data in binary format. Data to be transferred is stored in this binary data array. A detailed data structure will be described in detail with reference to FIG. A predetermined number of item objects are set between jobs in the preceding and following stages, such as job 1 and job 2, job 2 and job 3, and job 2 and job 4. In FIG. 14, a total of 15 item objects are generated, 5 for each job. A circle indicates an item object, and an item object that is shaded indicates that data has been recorded.

  In the relationship between job 1 and job 2, a pool object 210 for temporarily holding an item object is generated in job 1, which is the preceding stage. The pool class is a class for holding a predetermined number of item objects as an upper limit. A pool object 212 and a pool object 214 are also generated for the relationship between job 2 and job 3, and job 2 and job 4, respectively. The pool object 210 stores a predetermined number of item objects set for the relationship between job 1 and job 2. The same applies to the pool object 212 and the pool object 214. Note that the job 2 may not generate as many pool objects as the pool object 212 and the pool object 214 corresponding to the number of jobs in the subsequent stage, but may generate only one shared pool object. In this case, job 2 records the processing result in the item object acquired from the shared pool object, and transfers it to job 3 or job 4. Job 3 and job 4 return the item object to the shared pool object after reading data from the item object received from job 2. As described above, even when there are a plurality of jobs in the subsequent stage, the item object may be managed by one pool object.

  When job 1 executes its own processing, it retrieves the item object from the pool object 210 and records the processing result. Specifically, data indicating the processing result is recorded in the binary data array of the extracted item object. Such a recording method is simply referred to as “recording in the item object”. The job 1 inputs the item object in which the processing result is recorded to the queue object 220 set in relation to the job 2 in the subsequent stage. The job 2 takes out the item object from the queue object 220 and acquires data indicating the processing result of the job 1. Thus, job 2 executes its own processing based on the data indicating the processing result of job 1. When job 2 acquires the data, it returns the item object received from job 1 to pool object 210. Therefore, between the job 1 and the job 2, data is transferred via the queue object 220 while reusing the five item objects generated first. Similarly, a queue object 222 is set for the relationship between job 2 and job 3, and a queue object 224 is set for the relationship between job 2 and job 4.

Job 1 is blocked when there is no item object in the pool object 210 or when the queue object 220 is full of item objects. Similarly, job 2 is blocked when queue object 220 is empty. The same applies to the relationship between job 2 and job 3, and job 2 and job 4.
The reason why the processing method described above is employed will be described.

(1) An item object is prepared in advance for each job.
Suppose that job 2 acquires an item object in which the processing result of job 1 is recorded, and job 2 overwrites the processing result of job 2 on this item object and passes it to job 3. As described above, in the model in which one item object is sequentially transferred from job 1 to job 2 and job 3, each job is likely to be blocked. This is because job 1 cannot transfer the next processing result to job 2 unless job 3 returns the item object to job 1 or creates a new item object. The approach of generating item objects is not desirable for the following reason (2).
On the other hand, if an item object is prepared in advance for each relationship between job 1 and job 2, job 2 and job 3, and job 2 and job 4, job 1 is directly in the processing state of job 3 or job 4. The self-processing can be executed without being affected by the effects. By preparing an item object for each job, data passing processing between jobs can be simplified and blocking can be suppressed.

(2) Reuse item objects.
Job 1 may generate an item object at the time of data transfer to job 2, and when job 2 acquires data from job 1, the item object may be destroyed and the memory area may be released. However, when such a method is adopted in an enterprise system that executes many batch processes, the overhead associated with the creation and destruction of item objects may deteriorate the performance of the entire system.
In view of this, an item object is generated in advance for each job and reused between jobs, thereby reducing processing costs associated with the generation and destruction of the item object. Since the generation cost of the item object is localized at the start of execution of the enterprise system 204 and the destruction cost of the item object is localized at the end of execution, the throughput can be improved.

(3) A plurality of item objects are reused between jobs.
A plurality of, for example, five item objects used for data transmission / reception between the preceding and succeeding jobs are generated. What is necessary is just to obtain | require suitable number of item objects according to the property of a job, or the result of test execution. If there is only one item object for sending and receiving data between job 1 and job 2, when job 2 is reading data from the item object, job 1 will be new until the item object is returned. Process results cannot be recorded in the item object. For this reason, the processing state of job 1 is easily affected by the processing state of job 2 in the subsequent stage.
On the other hand, if a plurality of item objects are to be reused, job 1 processing and job 2 processing can be easily executed asynchronously. Particularly in the multi-thread model, the throughput of the entire system can be improved by reusing a plurality of item objects between jobs.

(4) The item object is transferred via the queue object.
If the item object is directly passed from job 1 to job 2 without going through the queue, job 1 will be blocked until job 2 is ready to receive the item object. On the other hand, since the queue object operates the preceding job and the succeeding job asynchronously, the throughput of the entire system can be improved.

  In addition, when the present inventor defined a simple DFD and executed a test using a single thread model, the total processing time was 13.3 seconds when the methods (2) and (3) were adopted. there were. On the other hand, when the functions (2) and (3) are disabled, the total processing time of the system for the same DFD is 80.5 seconds. In particular, the ability to limit the processing costs associated with the creation and destruction of item objects at the start and end of system execution contributes greatly to improving overall throughput.

FIG. 15 is a diagram showing source code corresponding to the process of recording the processing result in the item object and putting it in the queue.
The source code shown in the figure shows a doProcessMatching function that the MiseMaMatcher class 408 calls when its own processing is completed. When the doProcessMatching function is executed, the item object record is acquired from the pool object (S364). If there is no item object in the pool object, it is blocked. The processing result is written in the acquired item object record (S366), and is input to the queue object (S368). When the queue is full, the process of S368 is blocked.

FIG. 16 is a diagram illustrating source code corresponding to the process of acquiring the item object from the queue and acquiring the processing result of the preceding job.
The job object subsequent to the MiseMaMatcher object is a MiseUriageTotalSink object according to FIG. The source code shown in the figure shows a doTask function that the MTRecordStreamSink class 516 serving as a processing object of MiseUriageTotalSink calls at the start of its own processing. First, the item object record is acquired from the queue object set in relation to the previous job object (S370). If the queue is empty, the process of S370 is blocked.

  After that, the doWrite function which is a member function of the MiseUriageTotalSink class 410 is executed, and the specific output processing implemented in the MiseUriageTotalSink class 410 is executed by the doWrite function (S372). Next, the RecordUtil.releaseIfNeeded function is executed, and the item object acquired in S370 is returned to the pool object of the preceding job (S374).

FIG. 17 is a schematic diagram for explaining the structure of an item object.
The item object is used not only between the preceding and succeeding jobs but also when the MiseMaSource class 406 or the UriageSource class 400 acquires data from the node terminal 200 or the database 206. Here, description will be made on data X shown as a structure of four types of data, data A, data B, data C, and data D. Data X includes data A, data B, and data Y, and data Y includes data C and data D. “Element data” refers to basic data such as data A to data D, and “aggregate data” refers to structure type data including a plurality of element data such as data X and data Y. I will call it.

  In the case of a computer program written in an object-oriented language, when data is read from a file or database, a type conversion process is usually executed according to the read data. For example, if the data type of the data A read in binary format is defined as an integer type, the data A is recorded in the memory after securing a memory area for holding the data A as an integer. In the case of collective data such as data X, a memory is secured corresponding to the data structure of data X, and each element data is recorded. In the case of data X, numerical data, character string data, or structure data is recorded in the memory corresponding to the five data types of data A, B, C, D, Y, and X. Become. By creating a kind of data object corresponding to the data type, the programmer can easily handle the data. However, the present inventor has realized that in an enterprise system that executes many batch processes, the processing cost of the type conversion process may greatly reduce the performance of the entire system.

  Therefore, in this embodiment, data read from the file system formed as the database 206 and data indicating job processing results are stored in the binary format of the item object in binary format. That is, when data is acquired from the file system, data type conversion processing is not executed. Here, a case where job 1 in FIG. 14 reads data X from a predetermined database will be described as an example.

  Assume that one item object RIX is generated in relation to the job 1 and the database. When the job 1 acquires the data X from the database, the job 1 records the data X in the binary data array of the item object RIX as it is. The data X is a total of 64 bytes of data, and includes four types of element data: 24-byte data A, 16-byte data B, 8-byte data C, and 16-byte data D. It is assumed that the data structure of the data X acquired by the job 1 from the database is known to the job 1. Therefore, in the item class RIX, the size of the binary data array is set to 64 bytes in advance.

  The item class RIX further holds an offset value, a size value, and a pointer to a binary data array. The offset value indicates the start position in the binary data array of the data X to be managed, and the size value indicates the size of the data X. Since the data X is data from the first byte to the 64th byte of the binary data array, the offset value is 0 and the size value is 64 (bytes). Since the data X includes data A, data B, and data Y, when the item class RIX is instantiated, item classes RIA, RIB, and RIY for managing the data A, data B, and data Y are also attached. Instantiated. The item object RIX also holds pointers for accessing lower-level item objects RIA, RIB, and RIY as member variables.

Item class RIA manages data A. The substance of data A is stored in the binary data array of the upper item class RIX. The item class RIA holds an offset value for the data A, a size value, and a pointer to a binary data array that stores the data A. The offset value of the item object RIA is 0, and the size value is 24. This is because the data from the first byte to the 23rd byte of the binary data array. The processing object is, for example,
int dataA = RIX.RIA.getNum ();
The data A can be extracted as an integer value by the getNum function of the item object RIA via the item object RIX in the format as shown in FIG. When the processing object requires data A, data A in the binary data array is extracted, and type conversion processing by the getNum function is executed. In other words, data A is treated as a part of binary data unless it is necessary to extract data A. For example, in the case of copying data X or comparing data X with another data, type conversion of data A need not be executed.

  At least in the stage of extracting the data X from the database, it is not necessary to perform the type conversion process on the data X. The processing load accompanying the type conversion is suppressed by such a processing method. Actually, when the present inventor tried to test a simple DFD system, if the above method that does not execute the type conversion process when reading data from the database is adopted, the processing time of 13.3 seconds is always required. Changing to a method that executes type conversion processing took 37.1 seconds of processing time. In object-oriented languages, the basic idea is to “structure data in a way that users can easily handle”. On the other hand, the present inventor considered that the processing load for structuring data by the type conversion process is likely to cause a decrease in throughput in the enterprise system, as in the case of object generation / discard. Therefore, as described above, we succeeded in improving the throughput of the entire system by an approach that does not execute the type conversion process until it is actually needed and handles the data as binary data unless necessary.

Similarly, the item class RIB manages the data B. The offset value is 24 and the size value is 16. The item class RIY is a class for managing data Y that is a structure of data C and data D. The offset value is 40 and the size value is 24. Since the data Y is a structure including data C and data D as element data, when the item class RIY is instantiated, the item classes RIC and RID for managing the data C and data D are also instantiated. Is done. The item object RIY holds a pointer for accessing the lower item objects RIC and RID as a member variable.
For example, the processing object is
string dataD = RIX.RIY.RID.getString ();
In such a format, the data D can be extracted as a character string type by the getString function of the item object RID via the item object RIX.

  The same applies to data transmission / reception between jobs as in job 1 and job 2. The job 1 records the data indicating the processing result in the binary data array of the item object generated by the relationship between the job 1 and the job 2 and inputs it to the queue object 220. At this time, the job 2 may read the binary data from the item object and execute the type conversion process only on the data that needs the type conversion among the element data included in the binary data. According to such a processing method, it is possible to ensure convenience when handling data while improving throughput. The processing cost associated with the type conversion processing is usually insignificant, but is difficult to ignore in the case of the enterprise system 204 that batch-processes a large amount of data. The job management apparatus 100 that executes type conversion only when necessary can suppress such processing costs to a minimum.

According to the job management apparatus 100 shown in the above embodiment, the static relation definition of the job and the dynamic process definition of the job can be clearly separated by the model object and the control object.
In the case of a procedural language such as COBOL, these two types of definitions are often made as a unit. For this reason, the developer has to design the system while being aware of the static relation definition of the job and the dynamic process definition at the same time. On the other hand, according to the framework shown in the present embodiment, these two types of definitions can be clearly separated. For this reason, it is possible to define job relations without being excessively influenced by the job process definition. The reverse is also true. A framework that enables such a separation design is effective in enhancing the expandability, maintainability, and robustness of the enterprise system 204.

For example, by injecting processing only to a part of job objects, only a part of the functions of the enterprise system 204 can be tested only by a change operation on the control object side.
As a specific example, a case where only the functions of three job objects in the enterprise system 204 configured by 100 job objects are to be tested will be described. In such a case, first, 100 job objects are generated. In practice, processing is injected only into these three job objects. Next, when it is desired to test the function of the five job objects including the three job objects, the processing is injected into five job objects among the already generated 100 job objects. That is, if 100 job objects are generated first, it is not necessary to generate two job objects newly added as test targets for the second test. According to such a processing method, if all job objects are generated first, there is an advantage that it is not necessary to execute a new instantiation process due to a change of a test target.

  In the case of the enterprise system 204 shown in the present embodiment, all job objects are generated by model classes and are not generated from other job classes. For this reason, it is not necessary to have an innate dependency in the job class for the generation of the job object. Thereby, the independence of each job class can be improved. In addition, the programmer can refer to the UriageProcessingModel class 440 so that the job class to be processed can be referred to in an integrated manner, thereby improving the readability of the source code.

  In addition, as described with reference to FIG. 6, since job classes are defined by inheriting one of the typical four job base classes, dozens, hundreds, and thousands of job objects are included. Even in the case of control, the job class design burden is greatly reduced. The same applies to other classes such as a processing class and a model class.

  In this embodiment, as a multi-thread model, a plurality of jobs are executed by different worker threads. Therefore, programmers who design control classes and processing classes need hardly be aware of job dependencies. Each job automatically transitions to either the execution state or standby state depending on the processing status of the preceding and succeeding jobs, so that multiple jobs are executed according to the dependencies defined in the relationship class. become. The multi-thread model is more effective in improving the overall throughput as the flow branches in the DFD.

  In the job management apparatus 100, the single thread model and the multi-thread model can be easily switched at the time of execution. Depending on the dependency in DFD, the single thread model may have a higher overall system throughput than the multi-thread model. Since the model class and the control class are clearly separated, switching between multithreading and single threading can be easily set. For this reason, a suitable execution model can be selected as appropriate even after the DFD is defined or changed.

  In the job management apparatus 100, job objects handle data via item objects. An interface for handling data is formatted according to a predetermined class called an item class. By defining an item class for storing data handled by the job class together with a job class that handles data and a processing class that defines specific processing contents, there is an effect of improving the readability of the entire program. For example, even when a new job class is added to the UriageProcessingModel class 440, data output from the job class and input data can be handled using the item class interface. In this way, by unifying the interface for handling data by item class, it becomes easy to expand or change the function of the enterprise system 204.

Compared to a procedural language such as COBOL, an object-oriented language such as JAVA (registered trademark) is superior in terms of code reusability, maintainability, and robustness. On the other hand, there is a difficulty that overhead is generated more easily than procedural languages. In the present embodiment, in order to suppress such overhead while securing the superiority of the object-oriented language, the following method is mainly adopted.
1. By initially generating a plurality of item objects and reusing them cyclically, processing costs associated with the generation and destruction of the item objects are suppressed.
2. By preparing a queue for passing item objects, the asynchronous nature of each job is improved.
3. Item objects handle data in a binary format, and perform type conversion processing only when extraction is necessary, thereby reducing processing costs associated with type conversion.
According to the job management apparatus 100 shown in the present embodiment, while maintaining the object-oriented framework and utilizing the superiority of the object-oriented language, the generation of overhead associated with data transmission / reception and conversion is suppressed, thereby reducing the procedure. It combines the throughput of a type language with the advantages of an object-oriented language.

  Note that the function of the job management apparatus 100 may be realized by a plurality of hardware resources. For example, job objects may be distributed and arranged in a plurality of job execution devices. According to such an aspect, a processing method is possible in which the job execution apparatus B executes the process of the job object β while the job execution apparatus B executes the process of the job object β. Thereby, not only the time efficiency but also the processing load can be distributed efficiently. The control class may preferentially assign jobs to job execution apparatuses that are lighter in processing load than other job execution apparatuses so that the processing load is not localized in the job execution apparatus group. Conventionally, in order to realize the distributed arrangement of jobs, a design on the premise of distributed arrangement to a plurality of job execution apparatuses has been required. Therefore, it is easy to transfer a job execution subject from an external job execution device to an external job execution device.

  The present invention has been described above based on the embodiment. The present invention is not limited to this embodiment, and various modifications thereof are also effective as aspects of the present invention. For example, in the present embodiment, the description has been made assuming an enterprise system, but more specifically, application to electronic commerce, logistics management, and the like can be considered. Further, the framework shown in this embodiment can be widely applied to a model in which a plurality of jobs are defined and controlled as in workflow management.

The function of the job object generation unit described in the claims is mainly realized by the UriageProcessingModel class 440 in this embodiment. The function of the job list information generation unit described in the claims is realized mainly by the UriageProcessingModel class 440 and the Connection class 430 in this embodiment. The functions of the processing injection unit and the execution control unit described in the claims are mainly realized by the MultiThreadFlowController class 452 in this embodiment. Therefore, the model object generation function described in the claims is realized mainly by the model management unit 140, in particular, the UriageProcessingModel class 440 in this embodiment. The control object generation function described in the claims is realized by the flow control unit 150, particularly, the MultiThreadFlowController class 452 in the present embodiment. The processing function described in the claims corresponds to, for example, the doTask function shown in FIG. 13 in this embodiment. The function of the item object generation unit described in the claims is realized by a constructor or an initialization function of each job object. The function of the item object holding unit described in the claims is realized by a pool class. The function of the queue generation unit described in the claims is realized by the control class, and the function of the queue is realized by the queue class.
In addition, it should be understood by those skilled in the art that the functions to be fulfilled by the constituent elements described in the claims are realized by the individual functional blocks shown in the present embodiment or their linkage. .

  Various aspects of the invention ascertained from the above embodiments and modifications will be exemplified below in the form including those already described in the claims.

A1. An apparatus for executing a plurality of jobs whose dependencies are determined so that a job corresponding to the subsequent stage is executed based on output data of the job corresponding to the preceding stage,
A job object generation unit that generates a job object from a predefined class according to the type of job,
A job list information generation unit for generating job list information indicating the dependency of each job object;
A processing injection unit for setting a processing function indicating the processing content of the job after the job object is generated;
An execution instruction unit that selects a job object with reference to the job list information and executes a processing function set for the job object;
A job management apparatus comprising:

  A2. The processing function of the job object selected by the execution instruction unit specifies a job to which output data is to be passed next based on the job list information, and executes the processing function for the specified job. The job management device described in 1.

  A3. The job management apparatus according to A1 or A2, wherein the job object is not generated by another job object but directly generated by the job object generation unit.

A4. A model object generation unit that generates a model object as an object including each function of the job object generation unit and the job list information generation unit as a part of the function;
A control object generation unit that generates a control object as an object including each function of the processing injection unit and the execution instruction unit as part of the function;
The job management apparatus according to any one of A1 to A3, wherein the control object exhibits the functions of the processing injection unit and the execution instruction unit by setting the model object as a processing target.

A5. A job object is associated with a processing object that includes a processing function as a member function,
The job management apparatus according to any one of A1 to A4, wherein the processing injection unit sets a processing function for a job object by setting the processing object to the job object after the job object is generated.

  A6. The job management apparatus according to A5, wherein the processing injection unit selects a processing object to be set according to a class type on which the job object is based.

A7. Each processing function can be executed in parallel in time,
A predetermined processing function refers to the job list information, specifies a plurality of processing functions to be executed next, and executes the plurality of processing functions in parallel in time. The job management apparatus according to any one of the above.

A8. The job object generation unit can distribute a plurality of job objects to a plurality of external devices connected via a network,
The job management apparatus according to any one of A1 to A7, wherein processing functions of the job objects distributed and arranged in the plurality of external apparatuses can be executed in parallel in time.

A9. Generating a job object corresponding to a job as a structural unit of organizational work from a predefined class according to the type of job;
Generating job list information indicating the dependency of each job object;
A step of setting a processing function indicating job processing contents after generating a job object;
Selecting a job object with reference to the job list information, and executing a processing function set for the job object;
A job management method comprising:

A10. A function for generating a model object as an object for defining dependency relationships of a plurality of jobs so that a job corresponding to the subsequent stage is executed based on output data of the job corresponding to the preceding stage;
A function that generates a control object that defines the processing content of each job,
A function for setting processing contents of a job defined in the model object by executing the first member function of the control object;
A function for executing processing on the first job by executing the second member function of the control object;
A function for specifying a second job to which the output data of the first job should be passed according to the dependency relationship;
A function of executing processing for the second job;
A job management program that causes a computer to execute a plurality of jobs according to the dependency relationship.

It is a hardware block diagram of an enterprise system. It is a functional block diagram of a job management apparatus. It is a figure which shows the data flow diagram in a present Example. FIG. 4 is a diagram illustrating a dependency relationship of job classes corresponding to the DFD of FIG. 3. It is a schematic diagram which shows the relationship of the class for implement | achieving the basic function of a job management apparatus. It is a class diagram which shows the relationship between a job class and a model class. It is a class diagram regarding inheritance of a processing class. It is a figure which shows the function performed first in the start of execution of an enterprise system. It is a figure which shows the source code performed at the time of model object generation. It is a figure which shows the source code performed at the time of a control object production | generation and the start of execution of a data flow. It is a figure which shows the source code corresponding to the process to S320 and S330 of FIG. It is a figure which shows the source code corresponding to the process of S340 of FIG. It is a figure which shows the source code corresponding to the process of S344 of FIG. It is a schematic diagram for demonstrating the data transmission / reception method between job objects. It is a figure which shows the source code corresponding to the process which records a process result on an item object and throws into a queue. It is a figure which shows the source code corresponding to the process of acquiring an item object from a queue and acquiring the processing result of the preceding stage job. It is a schematic diagram for demonstrating the structure of an item object.

Explanation of symbols

  100 job management device, 110 user interface processing unit, 120 communication unit, 130 data processing unit, 140 model management unit, 150 flow control unit, 200 node terminal, 204 enterprise system, 206 database, 300 sales data, 302 sales aggregation processing, 304 Sales data by district, 306 store master data, 308 store name addition processing, 310 store sales data, 312 data flow diagram, 400 UriageSource class, 402 UriageAggregator class, 404 AreaUriageTotalSink class, 406 MiseMaSource class, 408 MiseMaMatcher class, 410 MiseUriageTotalSink class , 420 job classes, 430 Connection class, 440 UriageProcessingModel class, 450 SingleThreadFlowController class Class, 452 MultiThreadFlowController class, 460 ProcessingModel class, 480 RecordStreamSource class, 482 RecordStreamAggregator class, 484 RecordStreamMatcher class, 486 RecordStreamSink class, 490 Node class, 500 NodeFlowController class, 502 MTNodeFlowController class, 510 MTRecordStreamSource class, 512 MTRecordStreamMatcherRecord class 516 MTRecordStreamSink class.

Claims (7)

An apparatus for executing a plurality of jobs whose dependencies are determined so that a job corresponding to the subsequent stage is executed based on output data of the job corresponding to the preceding stage,
A job object generation unit that generates a job object from a predefined class according to the type of job,
A job list information generation unit for generating job list information indicating the dependency of each job object;
A processing injection unit for setting a processing function indicating the processing content of the job after the job object is generated;
An execution instructing unit that executes the plurality of processing functions in parallel in time by assigning different threads to the plurality of processing functions,
In the relationship between the job object corresponding to the previous stage and the job object corresponding to the subsequent stage, the processing function of the job object corresponding to the subsequent stage executes predetermined processing using the output data generated by the processing function of the job object corresponding to the previous stage as a variable, and the output data is not yet A job management apparatus that waits until output data is generated in a generation stage. An item object generation unit that generates an item object from a predefined class for sending and receiving data;
An item object holding unit that is set for each set of job objects corresponding to the previous stage and job objects corresponding to the subsequent stage, and holds the item object;
The item object generation unit generates an item object for each set of job objects corresponding to the preceding stage and job objects corresponding to the subsequent stage, and stores the generated item objects in the corresponding item object holding unit,
The processing function of the job object corresponding to the previous stage takes out the item object from the item object holding unit set in relation to the job object corresponding to the subsequent stage, records the output data, and then transfers the item object to the job object corresponding to the subsequent stage.
The job management apparatus according to claim 1, wherein the processing function of the job object corresponding to the latter stage reads the output data from the transferred item object, and then returns the item object to the item object holding unit. The item object holding unit can hold a plurality of item objects,
The item object generation unit generates a plurality of item objects corresponding to a set of job objects corresponding to the preceding stage and a job object corresponding to the subsequent stage, and stores the plurality of item objects in the corresponding item object holding unit. The job management apparatus according to claim 2, wherein: A queue generation unit that generates a queue that holds up to a predetermined upper limit number of item objects transferred from a job object processing function corresponding to the preceding stage to a job object processing function corresponding to the subsequent stage, for each set of job objects corresponding to the previous stage and job objects corresponding to the subsequent stage. Further comprising
The job object processing function corresponding to the preceding stage transfers the item object to the job object processing function corresponding to the subsequent stage via the queue,
The processing function of the job object corresponding to the preceding stage waits until the queue becomes empty when the number of item objects put in the queue reaches the predetermined upper limit number,
The processing function of the job object corresponding to the subsequent stage waits until the processing function of the job object corresponding to the preceding stage inputs an item object when there is no item object in the queue. Job management device.   5. The item object generation unit generates an item object from a class that stores and manages data in a binary data array for holding data in a binary format regardless of a data type. The job management apparatus according to any one of the above. Generating a job object corresponding to a job as a structural unit of organizational work from a predefined class according to the type of job;
Generating job list information indicating the dependency of each job object;
A step of setting a processing function indicating job processing contents after generating a job object;
Allocating separate threads to the plurality of processing functions to execute the plurality of processing functions in parallel in time, and
In the relationship between the job object corresponding to the previous stage and the job object corresponding to the subsequent stage, the processing function of the job object corresponding to the subsequent stage is caused to execute predetermined processing using the output data generated by the processing function of the job object corresponding to the previous stage as a variable, and the output data is A job management method comprising waiting until output data is generated in an ungenerated stage. A function for generating a model object as an object for defining dependency relationships of a plurality of jobs so that a job corresponding to the subsequent stage is executed based on output data of the job corresponding to the preceding stage;
A function that generates a control object that defines the processing content of each job,
A function for setting a processing function indicating job processing content for each job by executing the first member function of the control object;
A function of assigning different threads to processing functions of a plurality of jobs by executing a second member function of the control object, and executing the processing functions in parallel in time;
In the relationship between the job corresponding to the preceding stage and the job corresponding to the subsequent stage, the processing function of the job corresponding to the subsequent stage is caused to execute predetermined processing using the output data generated by the processing function of the job corresponding to the preceding stage as a variable, and in the stage where the output data is not generated Has the ability to wait until output data is generated,
A job management program that causes a computer to execute a plurality of jobs according to the dependency relationship.

Images