3. SubTasks

Component

Components are used to save the frequently used Jiffy steps separately in Components so that those can be reused across tasks instead of writing the same steps again and again. These components can be used any number of times in any number of tasks.

Refer to Components to understand more on the usage of Components.

Start Sub Task and End Sub Task

Sub Task consists of two nodes: Start Sub Task and End Sub Task. They work as a group. Maximum loop count and Maximum time that a sub task to be executed can be defined in the properties. This can be used in cases where:

A group of nodes needs to be executed until some criteria is met
A group of nodes needs to be executed for N times

For example, as part of a task execution, step 4 can be executed only if an email is triggered post step 3. Add a subtask group after step 3 with a maximum delay of X seconds and loop count of Y times. Add a validator for the email in between start sub task and end sub task. In this case, the execution will come out of subtask and proceed with the execution of subsequent nodes if any one of the below condition is satisfied

If all nodes in the subtask is passed successfully (if there are more than one validator node within subtask, all validator nodes has to be passed successfully)
If the loop count reaches Y times
If the subtask execution time reaches X seconds (Time given in Total Wait Time (Sec):)

If, Else, and EndIf

If-else-EndIf nodes brings conditional execution in JIFFY. Refer ”task -> If-Else–Endif” for more details. This video shows how this works in Jiffy.

Note: DB Nodes, Datatable Nodes cannot be used inside of the If-Else–Endif nodes.

Task

Task node allows the users to access and execute another task of same release as a child task from the current task (Parent task).

Notes :

Any number of child task nodes can be added in the parent task
No data can be passed between child task and parent task. i.e Task node does not allow any data to be mapped to the child task from previous nodes or mapped from child task to use in further nodes of parent task
Nested tasks are not allowed, i.e another parent task (any task which has a task node) cannot be used in task node
Task nodes are not allowed in Components
Task nodes cannot be used in iteration. For example, if the execution of a task needs to be iterated with different input data, then a task node cannot be used
When CONTINUE ON FAILURE in properties is set to Off, if the child task execution is failed, then the nodes which comes after task node will not be executed
When the parent task executed from task design, the execution details of child task can be viewed only in Task Execution - > Execution History. The Run ID can be obtained by clicking the view button of child task node and use the Run ID to get more details of the execution in Task Execution - > Execution History
When the parent task is executed form Task Execution tab, separate entries will be created in Execution history for parent task and each individual child task with all the execution details of each node

Polling Nodes

Polling nodes are used to trigger the execution of tasks continuously at given time interval. Only task nodes are allowed within polling nodes. The execution of polling nodes will be continued until it is stopped manually, irrespective of child tasks whether they are successfully executed or failed. So this can be considered as a scheduler which can trigger the execution of other child tasks at a given time interval.

Polling task execution can be triggered either from Task Design or Task Execution. As soon as the polling task execution is triggered it creates the following:

An entry in Polling history with Status as POLLING, which says the execution is in progress
An entry in Execution Summary for the task with details as how many times the child tasks are executed along with successful/failed count
An entry in Execution History for each round of execution, details of all the child tasks within polling nodes, i.e if the child task within the polling nodes are executed 50 times, the execution history will have 50 entries with the details of each round of execution
If the polling task is triggered from Task execution, in addition to the above-mentioned entries there will be an entry for parent task in Execution Summary and Execution History

Stopping the polling node execution

Once the execution is triggered, it can be stopped by selecting the record from Polling history. If the execution is triggered from Task Design, user can also stop the execution by using Stop Run button available in Task design window. When the user click on Stop button, execution will not be instantly stopped, instead it will continue till the current iteration is completed for all the child tasks within polling nodes and then will be stopped. Once stopped, the status of polling task in Polling History will be updated as STOPPED.

Notes:

Only task nodes are allowed within the polling nodes. In case if any other nodes are used, the polling will not be executed and the status in Polling history and Execution summary will be updated as INVALIDATED
No iterations are allowed within the polling nodes
Polling nodes are not allowed in components
Nested polling nodes are not allowed
Tasks which has polling node cannot be selected in Task nodes, ie those tasks cannot be used as child tasks
RESTART functionality will not be available for polling tasks