Page History

...

job_chain [label="Job Chain",fillcolor="orange"]
split [label="split",fillcolor="lightskyblue"]
split_100 [label="split:100",fillcolor="lightskyblue"]
split_200 [label="split:200",fillcolor="lightskyblue"]
split2 [label="split",fillcolor="white"]
split2_100 [label="split",fillcolor="white"]
split2_200 [label="split",fillcolor="white"]
join2 [label="join2",fillcolor="white"]
split_300 [label="split:300",fillcolor="lightskyblue"]
split_400 [label="split:400",fillcolor="lightskyblue"]
join [label="join",fillcolor="lightskyblue"]
300 [label="300",fillcolor="lightskyblue"]
success [label="success ",fillcolor="orange"]

job_chain -> split 
split -> split_100
split -> split_200
split_200 -> split2
split2 -> split2_100
split2 -> split2_200
split2_100 -> join2
split2_200 -> join2
split -> split_300
split -> split_400
split_100 -> join
join2 -> join 
split_300 -> join
split_400 -> join
join -> 300
300 -> success 

Implementation

Components

• The job chain and jobs job1 to job5 provided by the sample are not specific to this solution, they represent simple shell scripts.
• The two split_partitions jobs (split and split2) are instances of the Splitter JITL Job and use the Java class com.sos.jitl.splitter.JobChainSplitterJSAdapterClass.
  • The job is used with the following parameters:
    • state_names: a list of semicolon separated job node states to which split orders are added. For each entry in this list an individual order is created.
      • The state names correspond to the states that the respective job nodes are associated with in the job chain definition.
      • State names for the first node of each of the job chain segments that are executed in parallel should be prefixed with the name of the state of the split_partitions job and a colon. This should be followed by a unique descriptor, usually name of the job associated with the state but this is not mandatory. This convention is necessary to ensure correct display of dependencies in JOE and the JOC Cockpit. For example, state of one of the nested job chain segments in the example used in this article is:
        • split2:200 for jobD.
      • Note that the naming convention for state names for the first node of each parallel job chain segment does not have to be followed for subsequent nodes in the job chain segment (See the example in the How to split and join jobs in a job chain article.)
      • The state names corresponding to the first nodes in each parallel job chain segment are specified in the state_names parameter. For example, the split2 instance of the JobChainSplitter job has the value:
        
        • split_partitions:job3;split_partitions:job4
    • join_state_name: this parameter is required exclusively for improved graphical output from JOE and the JOC Cockpit. It requires the name of the state that is specified for the join node corresponding to the splitter node. For example the value specified for the split2 instance of the JobChainSplitter job is:
      • join2
  • Any number of jobs can follow the jobs that are referenced by the state_names parameter.
• The job job_chain1.join_partitions is used to join up split orders and is provided by the Join Orders JITL Job with the Java class com.sos.jitl.join.JobSchedulerJoinOrdersJSAdapterClass.
  • The recommended naming convention for this job uses the job chain name as a prefix: due to the nature of this job to join up across all job chains that are running in the system and that make use of the same join job name you should prefix the job name with the job chain name if you want this job to be limited to work for the current job chain.
  • This job is used without parameters.

Usage

• Start the main Order (named start in this example) for the Job Chain using JOC. In the current example this will immediately start processing the split Job.
• Each split job generates a new Order for each split part of the Job Chain. The main Order will then jump to the join node corresponding to the split node and wait (in the suspended state) for the processing of all the parallel chain segments to be completed. In the current example, the start Order will wait at the join node until the split:100, join, split:300 and split:400 jobs have successfully completed being processed.