Introduction
FEATURE AVAILABILITY STARTING FROM RELEASE 2.5.6
FEATURE AVAILABILITY STARTING FROM RELEASE 2.6.3
The JITL CheckLicenseJob template can be used to monitor if the JS7 - License is about to expire or is expired.
- The job template makes use of the JS7 - REST Web Service API to perform JS7 - Order State Transitions.
- 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.
Usage
When defining the job either:
- invoke the Wizard that is available from the job properties tab in the Configuration view and select the JITL CheckLicenseJob and relevant arguments from the Wizard
or
- specify the
JITL
job class andcom.sos.jitl.jobs.checklicense.CheckLicenseJob
Java class name and add arguments specifying what order states to transition..
Example
Download (upload .json): pduCheckLicenseJITL.workflow.json
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.
In a next step invoke the job wizard that you find in the upper right corner of the job property editor. The wizard brings up the following popup window:
Explanation:
- From the list of available job templates select the CheckLicenseJob.
Then hit the Next button to make the job wizard display available arguments:
Explanation:
- Optional Arguments
validity_days
: Specifies ...
- Note that the the check box provided with each argument has to be selected the argument is to be added to the arguments of the CheckHistoryJob template.
When hitting the Submit button the wizard adds the required arguments to the job which should look like this:
The job arguments can be specified:
- from individual variables as configured using the job wizard,
- by using JS7 - Job Resources.
Documentation
The Job Documentation including the full list of arguments can be found from: https://www.sos-berlin.com/doc/JS7-JITL/CheckHistoryJob.xml
Arguments
The CheckLicenseJob template accepts the following arguments:
Name | Required | Default Value | Purpose |
---|---|---|---|
validity_date | yes | n/a | Specifies ... |
Return Variables
The CheckHistoryJob template returns the following variables:
Return Variable | Data Type | Purpose | Example |
---|---|---|---|
,,, | Boolean | Returns .... | |
| String | Returns ... | |
body | String | Returns ... |
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
Explanation:
- Arguments of the CheckHistoryJob template include to specify the
query
andworkflow
that is looked up in the execution history. - The query isCompletedSuccessful checks if the indicated workflow was successfully executed during the current day.
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:
- the job script can make use of environment variables like this:
- Return Variables can be mapped to environment variables like this:
- If the successor job is a JVM job then Return Variables can be accessed directly.
- If the successor job is a Shell job then