Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Use Case:
    • Consider the situation where:
      • A job chain is to start at a number of parallel job chains
      • Subsequent jobs in started job chains check if jobs from parallel chains completed successfully.
    • Usually a split & sync pattern is used for similar use cases, however, synchronizing includes that both jobs have to be completed.
    • Instead the current use case is about check and control if a job of a parallel chain has completed without forcing both jobs to run synchronously.

Solution

  • Download: final_chain_job_chain_history.zip
  • Extract the archive to a folder in your JobScheduler installation named ./config/live.
  • The archive will extract the files to a sub-folder final_chainparallel_job_chain_historycontrol. 
  • Note that you can store the sample files in any folder you like.

...

Flowchart
# order_A [shape="ellipse",label="Order A\n start time: Friday 08:00 ",fillcolor="violet"]
# order_B [shape="ellipse",label="Order B\n start time: Friday 07:00 ",fillcolor="violet"]
# order_Z [shape="ellipse",label="Order Z\n start time: Friday 15:00 ",fillcolor="violet"]
 
job_chain_1 [label="Job Chain 1\nhas no relevant dependencies",fillcolor="orange"]
job_chain_2 [label="Job Chain 2\nis started by Job Chain 1",fillcolor="violet"]
job_chain_3 [label="Job Chain 3\nis started by Job Chain 1",fillcolor="lightskyblue"]
job_chain_4 [label="Job Chain 4\nis started by Job Chain 1",fillcolor="aquamarine"]
job_chain_5 [label="Job Chain 5\nis started by Job Chain 1",fillcolor="orangered"]
job_chain_6 [label="Job Chain 6\nis started by Job Chain 4",fillcolor="yellow"]


split1 [label="Split 1", fillcolor="orange"]
job1 [label="Job 1", fillcolor="orange"]
job2 [label="Job 2", fillcolor="orange"]
sync1 [label="Sync 1", fillcolor="orange"]
job1_2 [label="Job 1.2", fillcolor="orange"]

job3 [label="Job 3", fillcolor="violet"]
job4 [label="Job 4", fillcolor="violet"]

job5 [label="Job 5", fillcolor="lightskyblue"]
job6 [label="Job 6", fillcolor="lightskyblue"]

job7 [label="Job 7", fillcolor="aquamarine"]
job8 [label="Job 8", fillcolor="aquamarine"]
job9 [label="Job 9", fillcolor="aquamarine"]

job10 [label="Job 10", fillcolor="orangered"]
job11 [label="Job 11", fillcolor="orangered"]
job12 [label="Job 12", fillcolor="orangered"]

job13 [label="Job 13", fillcolor="yellow"]

job_chain_1 -> split1
split1 -> job1 -> sync1
split1 -> job2 -> sync1
sync1 -> job1_2
 
job1 -> job_chain_2 -> job3 -> job4
job2 -> job_chain_3 -> job5 -> job6

job1_2 -> job_chain_4 -> job7 -> job8 -> job9
job1_2 -> job_chain_5 -> job10 -> job11 -> job12


job9 -> job_chain_6 -> job13

# job8 -> job4
# job11 -> job4
# job11 -> job6
job4 -> job8 [arrowhead="normal", color="lightslategrey"]
job4 -> job11 [shapearrowhead="invnormal", color="lightslategrey"]
job6 -> job11 [shapearrowhead="invnormal", color="lightslategrey"]
job13 -> job12 [arrowhead="normal", color="lightslategrey"]

Implementation

Components

  • The solution contains three job chains:
    • job_chain_A and job_chain_B represent the predecessor job chains that have no relevant dependencies with job_chain_Z.
    • job_chain_Z is the final job chain that checks if job_chain_A and job_chain_B have already been executed successfully.
  • The solution implements a job check_predecessor_job_chain_Z that has been added at the start of job_chain_Z.
    • This job makes use of a parameter check_job_chains that is assigned a semicolon separated list of job chain names.
      • Job chain names can be specified with an absolute path (starting from the live folder) or with a path relative to the directory of this job.
      • Example:
        • check_job_chains = job_chain_A;job_chain_B
    • This job implements a spooler_process() function that reads the parameters and checks the job cahin history for successful execution of the job chains specified by the parameter.
    • Should all checks for previous successful execution provide a positive result then the current order will be moved to the next job chain node. Otherwise the current order is set back and will be repeated regularly according to the setback configuration for this job.

...