HCL Workload Automation: How to drive your workload by business logic

When designing a workflow into job streams using the HCL Workload Automation solution, it may happen that the entire process is not modeled as a simple pipeline and the implementation of the projected flowchart requires some branching and decision logic (IF… THEN.. ELSE…).

Using the HCL Workload Automation conditional dependencies feature, it’s very easy to solve this design problem. Let’s take a look at how to create and use conditional dependencies in many use cases.

First things first: What is a conditional dependency?

It’s a job dependency that will be released in case a particular status is reached or a specific output condition is verified on the parent job. If the condition is not satisfied, the dependent job will be suppressed.

Thinking about conditional dependency on job status we can affirm that is a generalization of the standard dependency that is released if the parent job ends in success or it’s canceled while, on conditional dependency, you can map any status as requirement even an ABEND or RUNNING state.

If not satisfied upon parent job’s completion, the child job will go into SUPPRESS state instead of remaining in HOLD status like in standard dependencies.

Here’s our first use case scenario:

Use case 1: error management

In this use case, the scheduler wants to differentiate the job stream processing in case the PRINT_ANSWER job is ending in error.

To achieve this goal is sufficient to create a dependency for the job PROCESS_DATA from PRINT_ANSWER and flag it as conditional dependency and select the status as SUCC, on the other side, the conditional dependency for MANAGE_ERROR job is associated to the ABEND status.

As you can see in the figure here, if PRINT_ANSWER job is successful the MANAGE_ERROR job will be suppressed and the regular PROCESS_DATA job will run.

Sometimes it’s required to manage the job stream flow differently depending on a job’s return code instead of its status.

Let’s look at another instance.

Use case 2: branching by return code

As shown in the figure above, the job stream is branching to manage two different successful return codes for job START.

Job START has two different successful output conditions labeled as “zero” and “four” and jobs CHILD_0 and CHILD_4 are dependent from it with a conditional dependency based on the respective output conditions.

In this example, the exit code of START is 4 and condition “four” is true while condition “zero” is false causing job CHILD_0 suppressing and job CHILD_4 executing.

Let’s make the processing requirement more complex — like branching the workflow basing on the content of the job log or the result of a database query or a particular value of a JSON received as an answer in a RESTful job (and not on the status mapped for the job) in another scenario.

Use case 3: branching by variable content

In this example, conditions that are not affecting the job status (“other output conditions” field) is created for job MESSAGE to evaluate the presence of the strings “KO” or “OK” in the job log using the variable ${this.stdlist} to branch the processing. Notice that successor jobs need to have the “variable resolution at runtime” flag set.

Possible alternatives to the job log variable use can be the use of the JSONresult variable (${this.JSONResult}) in restful jobs that, contains the JSON file received in answer by the service or the value filtered for a specific tag indicated in the advanced section of the RESTful job definition. A variable named after the column label in your SQL query for the database job type can be used as another example.

Imagine now that two different branches are not enough for your requirements, but you need to implement multiple branches like in the next use case here:

Use case 4: multiple branching

We’ve now created seven different output conditions not affecting the job status for the parent job and then set seven different conditional dependencies, one for each output condition, to implement the multiple branching flow.

Then we learned how to branch the flow in a job stream. A common question: Is it possible to join the branches? Yes, as explained in this next use case.

Use case 5: joining branches

The job on the bottom of this figure depends on a special dependency type: the join dependency. It’s possible to add into the join dependency one or more jobs and set the resolution criteria to “all completed successfully” or “one completed successfully” or in general some of them in the number you desire.

If your branches are mutually exclusive, or if you put 1 out of 7 like in the figure, it’s sufficient that one branch only completes successfully to release the last job (the other branches are suppressed).

We are at the end of our journey into logical branching for job streams, but before leaving remember this: if you need to add a sequence of more than one job in each branch you need to concatenate the parent-child jobs with a conditional dependency activated by the SUCC state of the parent job.

You really need this trick because the first job of a chain in a branch that is not pursued will be suppressed and the default behavior in classical dependency definition is to release the child job for execution. Then, the second step of the chain will start to execute, while your desired result is to have the entire branch pipeline suppressed!

Forcing the dependency to be released only in presence of a SUCC state of the parent job will cause a cascade suppression of the jobs in your branch as desired.

Happy conditional logic designing!

To learn more about HCL Workload Automation.