Versions Compared

Key

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

...

  • Frequently the fact that a job chain is executed depends on an external event, e.g. when watching for incoming files from a monitored directory. This situation is non-deterministic, i.e. we cannot know if a file will arrive or not. However, from a business perspective we assume expect a file to arrive, e.g. Mon-Fri not later than 18:00. This scenario applies to any events that depend on are created by mechanisms outside of the JobScheduler's reach as e.g. file orders, manual starts of job chains or external applications that start job chains e.g. by use of the API.
  • Typically users want to receive a notification if an expected event did not occur.
  • This article suggests a solution introducing Assertions to manage the expectation what should happen and when it should happen. 

...

Solution Outline

  • Basically the solution should work works for all job chains, including job chains that are started from file orders and job chains that are e.g. manually started by ad hoc orders. This solution is not intended for standalone jobs.
  • For a job chain that is expected to execute until a given date and time a shadow order Shadow Order is created that implements triggers the assertion.
    • The shadow order Shadow Order is assigned a start-time rule or calendar based rule to start e.g. Mon-Fri at 18:00. This is the point in time when the expectation should be met, i.e. at the given point in time the shadow order checks Shadow Order triggers a check if the respective job chain has been executed.
    • Should this check be successful, i.e. the job chain has been executed then the shadow order Shadow Order will complete its run successfully and will recalculate its next start-time.
    • Should this check fail, i.e. the job chain has not been executed then the shadow order Shadow Order will fail and create a notification to signal a failed assertion.
  • In addition to expecting a single execution of a job chain the solution should includeincludes
    • to check if more than one execution of a job chain occurred.
    • to check e.g. successful executions of a job chain only.

...

  • The below sample implementation is available for download: assertions.zip
  • Unzip the sample to your JobScheduler Master's live folder. This will create an assertions sub-folder with the below job-related objects.
  • The implementation includes 
    • the Assertion Monitor script that is used by jobs that signal execution of a job chain ,and that will create a Shadow Order.
    • the Assertion Job Chain that handles pairs of Assertion Orders and calls to Shadow Orders created by the Assertion Monitor.

Assertion Monitor

...

  • The <monitor.use> element references the Assertion Monitor. This monitor ships with the assertion_shadow_order.monitor.xml file in the assertions directory of the delivery.
  • Should the Assertion Monitor be referenced used from jobs outside of the assertions directory then an absolute path to its location can be used like this:
    • <monitor.use monitor="/assertions/assertion_shadow_order"/>
  • The Assertion Monitor is executed when an order completes a job node. It will create a Shadow Order for the Assertions Job Chain that signals that an expectation has been met, see below.
  • Therefore only one job in a job chain should use the Assertion Monitor, e.g. the first job node of the job chain.

Use of an Assertion Order for the assertions Job Chain

...