Introduction
JobScheduler can manage workflows according to the results of jobs, i.e. their return codes. It can use job return codes to:
- define the next job node to be executed in the same job chain,
- dynamically generate order parameters and
- start orders for other job chains.
Feature History
FEATURE AVAILABILITY STARTING FROM RELEASE 1.9
Issues
Feature support is subject to the following issues:
JS-1190 - Getting issue details... STATUS
JS-1193 - Getting issue details... STATUS
JS-534 - Getting issue details... STATUS
Use Cases
Workflow control by job return codes allows conditional job chain execution and the representation of more dynamic and complex processes than was previously possible with JobScheduler.
The return codes from individual jobs in a job chain can be used to:
- dynamically generate orders to start alternative job chains and, if required, assign order parameters and
- extend the range of error handling possibilities by allowing orders to jump/skip nodes in the current job chain.
Scope of workflow control
Implementation
Workflow control using return codes uses the inverse logic of return codes: an return code of 0 is returned when a job has run successfully and all other return codes (i.e. non 0) are returned when a job ends in error.
In addition, whereas by default a non-zero return code causes the JobScheduler to log an error for the job and to move the order to the error state, return code handling can be used to continue processing of the order without logging an error for the order.
Workflow control has been implemented to use individual return codes (0, 1, 2, etc.) or return code ranges (1-5, 6-9, etc.).
A typical implementation of this feature within a job chain could be:
- a return code of 0 causes an order to move to the next_state in the job chain.
- a return code between 1 and 5 causes the order to move to the cleanup_files state defined for the current job chain.
- a return code between 6 and 9 causes the order to proceed to the error state.
A typical implementation involving additional job chains could be:
- a return code of 0 will cause an order to move to the next_state in the job chain and to generate an order for an additional job chain.
- a non-zero return code causes an order to proceed to the error_state and start a second, error handling job chain.
Implementation of workflow control within a job chain and involving other job chains can also be combined.
Alternative commands
The JobScheduler's next_state (true), error_state (false) and add_order commands can also be used to provide a limited control of work flow within a job chain (see How to configure the handling of exit codes by jobs and the JobScheduler <job_chain_node.job_chain> Element reference).
However, these commands are job-specific and will be applied every time the job is called, limiting the extent to which the job can be reused.
Feature comparison
The implementation of return_codes is specified for a job chain node and is part of the job chain object. The implementation of return_codes is therefore independent of the job specified for a node and can be used more flexibly than next_state, error_state and add_order.
Example: Starting an order and skipping nodes according to the return code returned by a job chain node
Demonstration Files
Download: JobChainReturnCodes Example 1 working example (Windows Version), for Linux simply modify the shell scripts.
Unpack the configuration in the JobScheduler's Live folder. See our series of Tutorials for JobScheduler for information getting JobScheduler installed and running.
The configuration can now be:
- inspected - and edited if required - using in the JobScheduler Object Editor (JOE)
- run using the JobScheduler Operating Center (JOC).
Example
Use case
Consider two job chains where the return code for a job in one of the chains is used to control further workflow as follows:
- If the job configured to control the workflow runs successfully then:
- an order for another job chain will be generated and started and
- the order for the original job chain will proceed to the next node for the chain.
- If the job configured to control the workflow does not run successfully then:
- the order for the other job chain will not be be generated
- processing of the order for the original job chain will 'skip' to an alternative chain node.
Example configuration
A configuration as described in the previous section is shown in the diagram below:
- Job Chain A has 6 shell jobs 1, 2 ,3, 4, 5 and 6 and Job Chain B has 2 shell jobs.
- If Job 3 in Job Chain A ends successfully (i.e. its shell script ends with a return code = 0):
- .An order will be generated for Job Chain B and the order started.
- The Order running on Job Chain A should proceed to the next node configured for the chain (Job 4).
- If Job 3 in Job Chain A ends in error (i.e. its shell script ends with a return code between 1 and 5) then:
- No order for Job Chain B should be generated.
- The Order running on Job Chain A should skip two processing steps (Jobs 4 and 5) and proceed to the last node in the chain (Job 6).
Processing return codes
The configuration of the return codes takes place in one of two ways:
- The standard progression of an order along a job chain is as follows:
- When any of the jobs in either chain ends with an return code = 0, i.e. successfully, the order will proceed to the node defined by the next_state.
- When any of the jobs ends with an return code other than 0, i.e. in error, then processing of the order will be stopped and the order will proceed to the error_state.
- For more information about the principles of the jobs, job chains and orders elements used to configure JobScheduler workflows see our series of Jobs, Job Chains and Orders articles.
- Workflow control is activated by specifying one or more on_return_code elements for a job chain node.
One or more return_codes and one or more behaviors can be specified for each on_return_code element.- A match of a job return code and a return_code attribute specified for will cause the behavior(s) specified for the on_return_code element to be carried out.
Note that on_return_code elements are specified for the job chain node and not for the job, which is a child element of the node in the configuration. This allows jobs to be reused in other job chains with a different workflow control configuration. - Generation of the order to start Job Chain B:
- If Job 3 in Job Chain A ends with an return code = 0 then an Order for Job Chain B will be generated by the JobScheduler and started. This is configured using an add_order element.
- By default the generated order will have the ID of the originating order.
- By default the generated order will have any parameters set for the originating order.
- In addition
- If Job 3 in Job Chain A ends with an return code = 0 then an Order for Job Chain B will be generated by the JobScheduler and started. This is configured using an add_order element.
- Skipping nodes in the current job chain:
- If Job 3 in Job Chain A ends with a non-zero return code (in the example between 1 and 5) and a to_state element is set then JobScheduler behaves as follows:
- Job 3 will be set to the error state.
- The order will not proceed to the error_state but to the state specified in the state attribute of the to_state element.
In the example this is state 6 for Job 6 as shown in the diagram above. - If no further jobs in the job chain end with a non-zero return code then the order will end with the success state.
- If Job 3 in Job Chain A ends with a non-zero return code (in the example between 1 and 5) and a to_state element is set then JobScheduler behaves as follows:
- A match of a job return code and a return_code attribute specified for will cause the behavior(s) specified for the on_return_code element to be carried out.
Example Job Chain Operation
Two orders are available for the example configuration, with each order carrying a parameter named orderParameter. This parameter is read by the shell script in Job 3 in Job Chain A and used to set the return code for this job:
- The orderParameter for Order 0 has the value 0 and
- the orderParameter for Order 1 has value 1.
The behavior of the example configuration for each order will be as described in the previous section.
Running the Example Orders
The orders can be started in the Job Chains tab of the JobScheduler Operating Center (JOC) using the Start order now command as shown in the screenshot below:
Run both Order 1 and Order 2 and then open their log files using the Show log link shown in the Order History pane as in the next screenshot:
The code block below can be opened to show part of the log file for Order 0. This shows the log information for Job 3 and the start of Job 4. The following points are relevant:
- The orderParameter value of 0 is shown in Line 56 of the listing.
- Line 66 shows that Job 3 is exiting with return code 0.
- The end of processing of the node for Job 3 is noted in line 70.
- Line 71 shows that the state is set for starting Job 4 - there is no mention of the generation of the order that will start Job Chain B.
The next code block shows part of the log file for Order 1. This shows the log information for Job 3 and the start of Job 6. The following points are relevant:
- Line 66 of the listing shows that Job 3 is exiting with return code 1.
- The end of processing of the node for Job 3 is noted in line 70.
- Line 70 shows that an error is logged
- Line 71 shows that the state is set for starting Job 6 - the job at the node specified in the to_state element that was configured for node 3.
The next code block shows the last few lines of the log file for Order 1. Line 98 of the listing shows that despite the error recorded as Job 3 ended, the order is set to the success state.
Part of the log file for Job Chain B, which only starts when Order 0 is run, is shown in the next code block. Only the log information for Job 6 is shown in the listing. It can be seen that:
- The ID from the order generating the order for has been taken over by default. This is shown in the listing in line 51.
- The orderParameter value from Order 0 on Job Chain A has also been taken over and shown in line 38.
- The ParameterJob3 parameter, which is set with value "Parameter from Job3 - RC=0" is shown in line 35. This parameter was set in the on_return_code element at the node for Job 3 in JobChain A.
Configuring the example return codes
This is done in the Nodes tab of the JobScheduler Object Editor JOE for JobChain0 as shown in Screenshot 1 below.
A more detailed description of how to use JOE to configure a job chain can be found in JobScheduler Tutorial 2 - Editing a Simple Job with JOE
- The standard progression through the job chains is configured in the NextState and ErrorState fields of the form.
- Generation of the order to start JobChain1 is configured as shown in the screenshot:
- 1) Select Job3 since we want to start JobChain1 if this job ends successfully
- 2) Click on the Return Codes button to open the Return Code configuration form
Screenshot 1
- 1) Give the return code e.g
. return_code = 0is success in the ReturnCodes field- Syntax:
- Individual return codes are separated by blank spaces (e.g. 1 2).
- Return code ranges are inclusive and written 1..5 6..9
- Return codes can only be specified once
- Behavior:
- Note that non-zero return codes can be used but will be seen as an errors in the originating job chain.
- Should no
<on_return_code>element match the current return code then JobScheduler will apply thejob_chain_node@next_state(return code 0) orjob_chain_node@error_state(other return codes) attribute.
- Syntax:
- 2), 3) Select the target job chain e.g. JobChain1 from the drop down list
only job chains present in the same folder will be available in the Job Chain dropdown list- Other job chains can be:
- navigated to using the Browse button.
- specified using the syntax:
/myFolder/myJobChain.
- 4) Click on Add Order button to assign the Order to the
JobChain1 - 5) Click on Apply (at the foot of the form) to make the changes in the job chain configuration
- Save the job chain configuration.
Screenshot 2
Example Job Chain Code
<job_chain title="JobChain A">
<job_chain_node state="1" job="Job_1" next_state="2" error_state="Error"/>
<job_chain_node state="2" job="Job_2" next_state="3" error_state="Error"/>
<job_chain_node state="3" job="Job_3" next_state="4" error_state="Error">
<on_return_codes >
<on_return_code return_code="1..5">
<to_state state="6"/>
</on_return_code>
<on_return_code return_code="0">
<add_order xmlns="https://jobscheduler-plugins.sos-berlin.com/NodeOrderPlugin" job_chain="Chain_B">
<params >
<param name="parameterJob3" value="Parameter from Job3 - RC=0"/>
</params>
</add_order>
</on_return_code>
<on_return_code return_code="1">
<add_order xmlns="https://jobscheduler-plugins.sos-berlin.com/NodeOrderPlugin" job_chain="Chain_B">
<params >
<param name="parameterJob3" value="Parameter from Job3 - RC=1"/>
</params>
</add_order>
</on_return_code>
</on_return_codes>
</job_chain_node>
<job_chain_node state="4" job="Job_4" next_state="5" error_state="Error"/>
<job_chain_node state="5" job="Job_5" next_state="6" error_state="Error"/>
<job_chain_node state="6" job="Job_6" next_state="Success" error_state="Error"/>
<job_chain_node state="Success"/>
<job_chain_node state="Error"/>
</job_chain>
Limitations of use
Overlapping return codes
- Overlapping return codes should not be used to create multiple orders.
- This is automatically corrected in JOE but is possible when configuration is carried out with a code editor.
- Example:
Overlapping return code ranges should not be be used.
This is currently possible in JOE (Versions 1.9.7, 1.10.1) and when configuration is carried out with a code editor.
Example:
<on_return_code> matching limitations
Identical return code values are matched when a configuration is being generated in the JobScheduler Object Editor JOE.
This means that when a behavior (to_state or add_order) is specified for a single return code value and/or range of values or any combination thereof and another behavior is specified for exactly the same return code(s) then both will be included in the same on_return_code element and both behaviors will be carried out.
However, if there is a slight 'mismatch' of return codes - for example, if a behavior is specified for a return code of 3 and a second behavior for a return code range of 3..5 then these behaviors will be saved in different on_return_code elements.
JobScheduler executes on_return_code elements one after the other and executes any element containing a to_state attribute first. This means that of a job ends with a return code that is matched by a number of on_return_code elements, only the element with a to_state attribute will be executed as once this has been done, the order will no longer be at the original state to execute any further on_return_code elements.
Further Examples
The following subjects have not been covered in this article:
- Dynamic modification of parameters within a job chain
- Setting parameters and IDs for orders for additional job chains
Change Management References
References
- The Knowledge Base Articles on return / exit code handling:
- JobScheduler Reference Documentation:
<job_chain_node> XML Element
<add_order> (Node Order plugin) XML Element
- <params> (Node Order plugin) XML Element
- <param> (Node Order plugin) XML Element