Product Knowledge Base

Space shortcuts

Page tree

Scope

  • Use Case

    • Create Job Stream #1 

      • 1. Batch Job #1 runs only at 10pm. If the job fails to run successfully, is should be rerun up to a maximum 2 times.

      • 2. Batch Job #2 will run IF AND ONLY IF Job #1 completes successfully by 11pm and only if today is Wednesday.

      • 3. Batch Jobs #3 and #4 will run only if Job #2 ran successfully before 11.30pm and only if it’s before the 10th of the month (meaning the run date is < 10th OCT-2015 for example).

      • 4. Batch Job #5 will run after midnight and if Jobs #3 and #4 completed running within 45 minutes of their individual start times.

      • 5. Batch Job #6 will run only on Thursdays and Fridays of the week, and IF AND ONLY IF it’s after the 5th of the current month AND before 15th of the month (meaning the run date is > 5th OCT-2015 && < 15th OCT-2015 for example).

    • Create Job Stream #2:

      • 6. Run Batch Job #7 all by itself in a separate Job Stream #2 during the 1st week of the 3rd month of every quarter in a calendar year.

    • Combine the 2 Job Streams into a new Job Stream #3:

      • 7. Batch Job #8 and Batch Job #9 (in Job Stream #3) will be automatically started and running at the same time IF AND ONLY IF Job #6 from Job Stream #1 and Job #7 from Job Stream #2 ran successfully.

    • Create Job Stream # 4:

      • 8. Run Batch Job #10 (in Job Stream #4) only after the successful completion of Job #8 and #9 in Job Stream #3.

  • Feature Availability
    • FEATURE AVAILABILITY STARTING FROM RELEASE 1.10.2
    • JITL-217 - Getting issue details... STATUS

Solution

  • Download: workflow_condition.zip
  • Extract the archive to a folder in your JobScheduler installation named ./config/live/issues.
  • The archive will extract the files to a sub-folder workflow_condition. 
  • Note that you can store the sample files in any folder you like: however, you will then have to adjust the job parameters accordingly.

Pattern

Implementation

Components

  • Hints
    • The solution makes use of Scripting with Pre-/Post-Processing Monitors and date calculation.
    • The term completed successfully as subsequently used includes that
      • if not specified otherwise the last run of a job took place within the current period that is the current day (24pm to 0am).
      • the last run of a job was successful (not any previous runs within the same period).
    • The conditions assigned to jobs are handled in a way that job execution is skipped and processing is continued with the next job. The default behavior of JobScheduler would be to stop processing and wait for a condition to be met.
    • Except for job8 and job9 all jobs implement a simple "echo hello world" command.
  • The solution contains four job streams with dependencies:
    • job_stream1 and job_stream2 represent two job chains that have to be executed successfully to make job_stream3 proceed.
    • job_stream3 splits the processing into parallel jobs (job8, job9).
    • job_stream4 is the final job chain that checks if job8 and job9 from job_stream3 did complete successfully.
  • The solution implements the following job dependencies:
    • job_stream1
      • job1
        • runs without dependencies.
        • is configured for setback, i.e. will repeat iself in case of error up to two times.
      • job2
        • implements an individual Pre-Processing Monitor to check if the current day is Wednesday and if the predecessor job job1 completed successfully before 11:00pm.
        • will be skipped and the order moved to the next job node if the check fails.
      • job3
        • implements an individual Pre-Processing Monitor to check if the current date is before the 10th of month and if the predecessor job job2 completed successfully before 11.30pm.
        • will be skipped and the order moved to the next job node if the check fails.
      • job4
        • implements the same check as job3.
      • job5
        • implements an individual Pre-Processing Monitor to check if two predecessor jobs (job3, job4) completed successfully and consumed less than 45 min. execution time.
        • will be skipped and the order moved to the next job node if the check fails.
      • job6
        • implements an individual Pre-Processing Monitor to check if the current day is a Thursday or Friday and if the date is after the 5th and before the 15th of month.
        • will be skipped and the order moved to the success end node if the check fails.
        • makes use of the Named Post-Processing Monitor start_job_stream (by a <monitor.use> element):
          • the Post-Processing Monitor will not start job chains if the job completes with a return code > 0 signalling an error or if one of the checks fails.
          • this Monitor checks if a number of jobs completed successfully (job6, job7): 
            • the job names are specified by use of the check_jobs job parameter that is assigned a semicolon separated list of job names. 
            • job names can be specified with an absolute path (starting from the live folder) or with a path relative to the directory of this job.
            • the current job is exempted from checks as it is running, i.e. not completed, and resulted in a successful return code 0. 
          • if the checks are successful then this Monitor will start a number of job chains (job_stream3):
            • the job chain names are specified by use of the start_job_chains job parameter 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.
    • job_stream2
      • job7
        • implements an individual Pre-Processing Monitor to check if the current day is within the first week of a month.
        • will be skipped and the order moved to the success end node if the check fails.
        • makes use of the Named Post-Processing Monitor start_job_stream (by a <monitor.use> element) in the same way as job6.
        • the same job parameterization applies as for job6.
    • job_stream3
      • job8
        • makes use of the Named Post-Processing Monitor start_job_stream (by a <monitor.use> element):
          • the Monitor checks if a number of jobs completed successfully (job8, job9).
          • if the checks are successful then this Monitor will start a number of job chains (job_stream4).
        • implements a ping command to the localhost that is executed once.
      • job9
        • makes use of the Named Post-Processing Monitor start_job_stream (by a <monitor.use> element) in the same way as job8.
        • the same job parameterization applies as for job8.
        • implements a ping command to the localhost that is executed ten times. This is intended to have different execution times for job8 and job9.
    • job_stream4
      • job10
        • makes use of the Named Pre-Processing Monitor check_job_history by a <monotor.use> element) in
          • this Monitor checks if a number of jobs completed successfully (job9, job9): 
            • the job names are specified by use of the check_jobs job parameter that is assigned a semicolon separated list of job names. 
            • job names can be specified with an absolute path (starting from the live folder) or with a path relative to the directory of this job.
            • the current job is exempted from checks as it is running during the check, i.e. not completed, and resulted in a successful return code 0. 
        • will be skipped and the order moved to the next job node if the check fails.
  • The Monitors include a number of date checks that are disabled (to make the examples operable by default) by use of comments such as
             /* =>
             isJobRunEnabled = ( Date.today().getDate() < 10 );
             */ 
    • Please remove comments to enable the respective checks. 

Usage

  • Positive Check
    • Start the order start_job_stream1 using JOC's Start Order now context menu. Alernatively add a new order.
      • The order should pass through the job chain without errors.
    • Start the order start_job_stream2 using JOC's Start Order now context menu. Alternatively add a new order.
      • The order should also pass through the job chain without errors.
      • As the job chains job_stream1 and job_stream2 completed successfully the job chain job_stream3 will be kicked off by job7 of job_stream2.
      • Job chain job_stream3 runs job8 and job9 in parallel.
      • job9 in job_stream3 will take longer than job8 to complete and will start job chain job_stream4.
      • Job chain job_stream4 with job10 will complete successfully.
  • Negative Check
    • Modify the job job1 in job chain job_stream1 to include an error, e.g. by adding the command exit 1 as the final line in the job script.
    • Start the order start_job_stream1 using JOC's Start Order now context menu. Alernatively add a new order.
      • The order should complete with an error having passed job1, no further jobs are executed.
    • Add a new order to job chain job_stream1 and specify job2 as the initial order state.
      • This approach simulates job2 being started independently.
      • The jobs job2 up to job6 in job chain job_stream1 are skipped due to failed or missing execution of predecessor jobs.
      • Should you previously have performed the Positive Check then the job chains job_stream3 and job_stream4 will be kicked off. The fact that job chain job_stream2 has previously completed successfully during the Positive Check run is sufficient to allow execution of job_stream3 and job_stream4..

References

Change Management References

T Key Linked Issues Fix Version/s Status P Summary Updated
Refresh

Documentation