Skip to end of metadata
Go to start of metadata

Scenario

  • 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 expect a file to arrive, e.g. Mon-Fri not later than 18:00. This scenario applies to any events that 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 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 is created that triggers the assertion.
    • The 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 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 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 will fail and create a notification to signal a failed assertion.
  • In addition to expecting a single execution of a job chain the solution includes
    • to check if more than one execution of a job chain occurred.
    • to check e.g. successful executions of a job chain only.

Implementation

  • 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 Shadow Orders created by the Assertion Monitor.

Assertion Monitor

The assertion_shadow_order Assertion Monitor can be used by any job chain of a user that signals execution to the Assertion Job Chain:

Implementation of the Assertion Monitor  Expand source

Explanations:

  • The Assertion Monitor creates a Shadow Order for the Assertion Job Chain, see below.
    • The Shadow Order id is made up from the following parts: 
      • the folder of the originating job chain (and optional sub-folders): all forward slashes are replaced by exclamation marks (!).
      • separated by a hash character follows the name of the originating job chain.
      • separated by a hash character follows the originating order id.
    • Example:  !my_folder!my_subfolder#my_job_chain#my_order_id
      • the job chain my_job_chain is located in the /my_folder/my_subfolder directory hierarchy.
      • the originating order id is my_order_id.
  • Line 7: should the name or location of the Assertions Job Chain be changed then this should be considered by the Assertion Monitor.

Assertion Job Chain

The assertions job chain implements management of assertions and is provided with the assertions directory of the delivery.

Assertion Job Chain  Expand source

Explanations:

  • The job chain includes a single job assertions, see below.
  • The job chain can easily be extended, e.g. by a successor job that is executed in case of failure of the assertions job. The successor job could e.g. implement an e-mail job to send e-mail notifications.
  • By default the assertions job relies on the fact that either JobScheduler is configured to send e-mail in case of any failed jobs or that the JobScheduler Monitoring Interface is used to forward notifications to a System Monitor, such as Nagios, 

Assertion Job

The assertions job effectively does the work of determining if an expectation has been met, i.e. if for a given Assertion Order one or more Shadow Orders have been generated.

Assertion Job  Expand source

Explanations:

  • The job checks if for a given Assertion Order a matching Shadow Order has been created by the Assertion Monitor.

Usage

Use of the Assertion Monitor by Jobs

The Assertion Monitor is used by any jobs that should signal execution of a job chain to the Assertion Job Chain.

Use of the Assertion Monitor with job1  Expand source

Explanations:

  • 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 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

For a given job chain job_chain1 users should create an Assertion Order with an order id like this: !<folder>#job_chain1.

Sample Assertion Order for Assertion Job Chain  Expand source

Explanations:

  • The Assertion Order does not have to use parameters at all: if no parameters are specified then by default all matching Shadow Orders for a given Assertion Order will be removed. 
  • If the Assertion Order makes use of the optional parameter num_of_orders then this parameter specifies the number of Shadow Orders that are expected and that will be removed when the Assertion Order starts. Should a smaller number of Shadow Orders be found than specified by this parameter then the assertion is considered being failed. This parameter is useful if e.g. more than one incoming file is expected from a directory monitored by file watching. 
  • If instead the parameter num_of_successful_orders is used then this signals that Shadow Orders for successfully executed job chains only should be considered. Otherwise successful and failed execution of the originating job chain are both counted as matching events.
  • If the num_of_orders or num_of_successful_orders parameters are used with a value 0 then this causes the default behavior to be applied, i.e. all matching Shadow Orders will be removed.
  • The run-time of the Assertion Order specifies the point in time when the order will start and will trigger if expectations have been met.
  • Any number of Assertion Orders can created for the Assertion Job Chain.