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.
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
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
A 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 some other state defined for the 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 additional order for the same or some other job chain.
- a non-zero return code causes an order to proceed to the error_state.
Alternative commands
The JobScheduler's next_state (true), error_state (false) define the default behavior of the job chain as described above.
XML commands such as add_order and modify_job can also be used to provide a limited control of workflow within a job chain. 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. For more information see:
- the How to configure the handling of exit codes by jobs article
- the JobScheduler <job_chain_node.job_chain> Element reference
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 on_return_codes is therefore independent of the job specified for a node and can be used more flexibly than commands such as 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 information getting JobScheduler installed and running.
The configuration can now be:
- inspected - and edited if required - using in the JOE - JobScheduler Object Editor
- run using the JOC - JobScheduler Operations Center.
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:
- JobChainA has 6 shell jobs 1, 2 ,3, 4, 5 and 6 and JobChainB has 2 shell jobs.
- If Job3 in JobChainA ends successfully (i.e. its shell script ends with a return code = 0):
- .An order will be generated for JobChainB and the order started.
- The order running on JobChainA should proceed to the next node configured for the chain (Job4).
- If Job 3 in JobChainA ends in error, i.e. its shell script ends with a return code between 1 and 5, then:
- No order for JobChainB should be generated.
- The order running on JobChainA should skip two processing steps (Jobs4 and Job5) and proceed to the last node in the chain (Job6).
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.
- 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.
- Generation of the order to start JobChainB:
- If Job3 in JobChainA ends with an return code = 0 then an order for JobChainB 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 the parameters set for the originating order.
- If Job3 in JobChainA ends with an return code = 0 then an order for JobChainB will be generated by the JobScheduler and started. This is configured using an add_order element.
- Skipping nodes in the current job chain:
- If Job3 in JobChainA 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:
- Job3 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 6 for Job6 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 Job3 in JobChainA 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:
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 Job3 in JobChainA and used to set the return code for this job:
- The orderParameter for Order0 has the value 0 and
- the orderParameter for Order1 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 Order0. This shows the log information for Job3 and the start of Job4. The following points are relevant:
- The order_parameter value of 0 is shown in Line 58 of the listing.
- Line 71 shows that Job3 is exiting with return code 0.
- The end of processing of the node for Job3 is noted in line 72.
- Line 74 shows that the state is set for starting Job4 - there is no mention of the generation of the order that will start JobChainB.
The next code block shows part of the log file for Order1. This shows the log information for Job3 and the start of Job6. The following points are relevant:
- Line 68 of the listing shows that Job3 is exiting with return code 1.
- Line 69 shows that an error has been logged.
- The end of processing of the node for Job3 is noted in line 70.
- Line 72 shows that the state is set for starting Job6 - 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 Order1. Line 99 of the listing shows that despite the error recorded as Job3 ended, the order is set to the success state.
Part of the log file for JobChainB, which only starts when Order0 is run, is shown in the next code block. Only the log information for Job6 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 24.
- The order_parameter value from Order0 on JobChainA has also been taken over and shown in line 36.
- The parameter_job_3 parameter, which is set with value "ParameterReturnCodeJob3" is shown in line 33. This parameter was set in the on_return_code element at the node for Job3 in JobChainA.
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 = 0signals success, in the ReturnCodes field- Syntax:
- Individual return codes are separated by 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="JobChainB">
<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="JobChainB">
<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="Job4" next_state="5" error_state="Error"/>
<job_chain_node state="5" job="Job5" next_state="6" error_state="Error"/>
<job_chain_node state="6" job="Job6" next_state="Success" error_state="Error"/>
<job_chain_node state="Success"/>
<job_chain_node state="Error"/>
</job_chain>
Limitations of use
Overlapping return codes
Avoid creating overlapping return codes and/or overlapping return code ranges.
- 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.
Overlapping return code ranges should not be be used.
This is currently possible in JOE (versions 1.9.7, 1.10.1).
<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.
References
Change Management References
See also
- 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