Page History

...

• 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 Assertions Assertion Monitor.

Assertion Job Chain

...

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

...

• 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 exist 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 check trigger if expectations have been met.
• Any number of Assertion Orders can created for the Assertions Assertion Job Chain.