...

• The job template makes use of the JS7 - REST Web Service API to retrieve information from the JS7 - History. Operation of the job template requires
  network access from the Agent that executes the job to the JOC Cockpit instance,
  • availability of the Controller and of JOC Cockpit,
  • authentication and authorization with JOC Cockpit.
  • The job template authenticates with the JS7 - REST Web Service API by use of user account/password and/or by use of a certificate, for details see JS7 - Authentication.
  • For details about configuration items see JS7 - JITL Common Authentication.
• The job template checks the execution history of workflows and jobs
  • for execution with a start date or completion date in the given period,
  • for successful or failed execution results.

...

You can use the job wizard like this:

Explanation:

• Add an empty job from the instruction panel.
• Specify a name and a label for the job.
• Select an Agent.

...

• the history status of orders or jobs:
  • completed: the order or job completed successfully or failed.
  • completed successful
  • completed failed
• the period for which the execution history is looked up for orders and jobs that
  • started between two dates
  • completed between two dates
  • with periods being specified as absolute or relative dates

...

Syntax

Queries are specified from a function and optional arguments.

Functions

Functions

Arguments

Arguments

Syntax 

...

Absolute Dates

Absolute date can be specified

Absolute Dates

Absolute date can be specified as values to the startedFrom, startedTo, completedFrom and completedTo arguments.

...

...

The Job Documentation including the full list of arguments can be found underfrom: https://www.sos-berlin.com/doc/JS7-JITL/CheckHistoryJob.xml

Anchor
arguments arguments

Arguments

The CheckHistoryJob template accepts the following arguments:

Anchor
return_variables return_variables

Return Variables

The CheckHistoryJob template returns the following variables:

...

...

The CheckHistoryJob template authenticates with the JS7 - REST Web Service API by use of user account/password and/or by use of a certificate, for details see JS7 - Authentication.

...

Job Dependencies

The CheckHistoryJob template can be used to implement backward job dependencies:

• Jobs based on the CheckHistoryJob template do not fail if the underlying query does not return results.
• Instead, the CheckHistoryJob template provides Return Variables that can be inspected to determine further execution of jobs in a workflow.
• JS7 offers the JS7 - If Instruction to check the values of Return Variables and to decide what instructions to execute next.

Download (upload .json): pdwCheckHistory.workflow.json

Image Added

Explanation:

• Arguments of the CheckHistoryJob template include to specify the query and workflow that is looked up in the execution history.
• The query isCompletedSuccessful checks if the indicated workflow was successfully executed during the current day.
  
  

Image Added

Explanation:

• The JS7 - If Instruction is used to check the $returnValue return variable that carries
  • the value 0 if the query of the CheckHistoryJob template returns one or more hits.
  • the value 1 if the query of the CheckHistoryJob template returns no hits.
  • Alternative solutions include to check the value of the $js7CheckHistoryResult return variable for a Boolean value that indicates if the query did return any hits:
    • $js7CheckHistoryResult == true
    • $js7CheckHistoryResult == false
• The above example executes a successor job based on the result of the CheckHistoryJob. Such jobs have access to any Return Variables:
  • If the successor job is a Shell job then
    • Return Variables can be mapped to environment variables like this:
      
      Image Added
      
      
    • the job script can make use of environment variables like this:
      
      Image Added
      
      
  • If the successor job is a JVM job then Return Variables can be accessed directly.

Further Resources

• JS7 - JITL Common Authentication
• JS7 - JITL Common Variables

js7 {
    auth { ... }
    configuration { ... }
    job { ... }
    web { ... }

	api-server {
    	# API Server URL
	    url = "https://joc-2-0-primary:4443"

    	# Option 1: use of a Credential Store
	    cs-file=${js7.config-directory}"/private/secret.kdbx"
	    cs-key=${js7.config-directory}"/private/secret.key"
    	cs-password="secret"

	    # Option 1: use of references to credentials 
    	account="/myAccounts/joc@username"
	    password="/myAccounts/joc@password"


    	# Option 2: Use of account and password
	    account="root"
    	password="root"
	}
}

Explanation:

• The api-server configuration section specifies authentication details for the CheckHistoryJob and can occur in any position directly within the js7 configuration block.
• Configuration items available from this configuration section are explained with the following chapters.

Certificate Based Authentication

For JS7 - Certificate based Authentication configured with the ./config/private/private.conf file

• the url configuration item is required that specifies the URL of the JS7 REST Web Service API. Typically this corresponds to the JOC Cockpit URL.
  • Users can set up a number of JOC Cockpit instances that are clustered for automated fail-over.
  • Users can set up a load balancer that routes requests to a number of available JOC Cockpit instances.
  • For use with the CheckHistoryJob template both active and standby JOC Cockpit instances can be used.
• the Client Authentication Certificate has to be available from the keystore file indicated with the js7.web.https.keystore or js7.web.https.client_keystore settings.

User Account / Password Authentication

For user account/password authentication configured with the ./config/private/private.conf file

• the url configuration item is required as explained above.
• the user account and password can be specified from the following options:
  • Option 1: Use of a JS7 - Credential Store
    • with the following settings:
      • cs-file: Specifies the path to a KeePass database file.
      • cs-key: Specifies the path to a KeePass key file.
      • cs-password: Specifies the password for the KeePass database file.
      • account: Specifies the path to the entry in the KeePass database that holds the account name.
      • password: Specifies the path to the entry in the KeePass database that holds the password.
    • that suggest to preferably use a KeePass key file (cs-key) to protect the KeePass database. Basically it is pointless to protect a Credential Store by use of a password  (cs-password) that is similarly visible as putting the key under the mat. Use of a key file allows to apply OS ownership and file permissions to protect to the key file from 3rd parties.
  • Option 2: Use of user account and password
    • with the following settings:
      • account: Specifies the account name.
      • password: Specifies the plain text password.
    • that include both settings to be visible from the configuration file.

Job Dependencies

The CheckHistoryJob template can be used to implement job dependencies 

...