- 23 Sep 2024
-
DarkLight
-
PDF
ChildJob Looping in Workflow Design
- Updated on 23 Sep 2024
-
DarkLight
-
PDF
Itential recently made the decision to revert deprecation of the forEach
task, thereby allowing it to remain in the platform. As a best practice, Itential recommends using a childJob
loop.
Using ChildJob Looping
In workflow design, there may be some scenarios where it is best to use a childJobLoop
instead of the forEach
task. Using childJobLoop
simplifies the readability of workflows and promotes modularity without having to maintain looping logic in multiple places throughout the workflow. It is also a better way of doing loops (sequential and parallel) through a childJob
task.
Task | Task Description | Best Practice Recommendation |
---|---|---|
forEach | Executes a loop inside a job by iterating over each item in an array. | Replace with childJob using a “Loop Type” property. |
Task Conversion Process
The main components to converting a forEach
task to a childLoop
task include:
- The conversion of the looped task to a job of its own.
- The handler task that iterates over an array.
- The input and output variables of the
childJob
.
Here are the steps:
-
Create a new workflow for the looped tasks in the
forEach
task. -
Replace the
forEach
task in the original worklow with thechildJob
task and set theWorkflow
to the child workflow created in the previous step. -
Set the
loopType
to sequential or parallel. -
Set the
loopArray
to the referenceddataArray
. Ensure the items in theloopArray
are objects.
All the workflow details involved in the task conversion process are illustrated in the examples below.
Pass Inputs Directly to a Child Job (Basic Example)
Parent Workflow
In the starting workflow (Figure 1), the forEach
task is iterating over an array [1,2,3]
. For each iteration, the task is making a REST call to an API endpoint.
Figure 1
Create the Child Workflow
Next, create a child workflow for the task that is being looped (Figure 2). As a suggestion, it is easier to clone the original workflow and leave only the looping tasks.
Figure 2
Replace forEach with childJob
Go back to the parent workflow and remove the forEach
task. Replace it with childJob
.
Figure 3
Set the Loop Type
Open the task details for the childJob
task and update the Workflow, Loop Type and Loop Array property fields with the corresponding values. Use Sequential
for the Loop Type. Click Save to retain your changes.
Figure 4
Convert Array to Object
For the array passed to the childJob
task, the values need to be objects. Go back to the parent workflow and open the “New Job Variable”. Change the data_array
input to [{},{},{}]
(Figure 5). Click Save to retain your changes.
Figure 5
Run Workflow
Once the “New Job Variable” is updated, click the Run button (▶) to execute the workflow and successfully complete the conversion activity.
Use Transformations to Pass Inputs to a Child Job (Advanced Example)
To build on the basic example presented above, let's explore an alternate mechanism which might be useful in some scenarios.
Restore Parent Workflow
Open the “New Job Variable” and change the data_array
input to to “[1,2,3]”
. Click Save to restore the parent workflow back to its original state.
Next, to minimize some of the complexity of manually converting the input array, you can use a JST to map how the Loop Array passes input values to the childjob.
Create a JST
Open the task details for the childJob
task. Click the plus (+) icon next to the Transformation field to create a JST that can map the Loop Array to input values for the childjob workflow.
Figure 6
Set the Outgoing Schema
On the JST page, set the outgoing schema with an id of num
and type of 'integer'. This allows you to pass in the data_array
variable to the outgoing schema using the original [1,2,3]
input array from the parent workflow. Save and close the JST.
Figure 7
Input for the childJob Task
Next, open task details for the viewData
task. For the message
variable, change the Reference task to job
and the Reference variable to message
as shown in Figure 8. Click Save to update the viewData
task.
Figure 8
Use the JST configured earlier to pass the $id
of message
rather than num
. This creates the data_array
object [{"message":1},{"message":2},{"message":3}
that is passed to the childJob
task.
Figure 9
Save the transformation and then go back to the parent workflow and click the Run button (▶). Once you “work” the childjob, you will see the Rest Call Output as shown Figure 10.
Figure 10
Output for the childJob Task
Lastly, if the parent workflow requires the output of the childJob
task, then use the output data from job_details
. In this case, add the viewData
task and use it to pass in the job_details
.
Figure 11
Next, pass in the job_details
output to the body
variable.
Figure 12
Run the parent workflow and "work" each childjob viewData
task. As shown in Figure 13, the job_details
of the childJob
task will look something like this in the output.
Figure 13
Each of the loop items will contain the job variables for the job that was completed; however, you will notice no job variables are available. To get the output of the REST API call, go back to the child job in designer mode, choose the RestCall
task, and then select (check) the Job Variables box under Outgoing.
Figure 14
Once you run the parent workflow, you will then get the output in job_details
for the childJob
task for each iteration (Figure 15).
Figure 15