Workflow in status "Waiting for Parallel Tasks" instead of "Ready for Start" when using :WAIT in Tasks
search cancel

Workflow in status "Waiting for Parallel Tasks" instead of "Ready for Start" when using :WAIT in Tasks

book

Article ID: 378379

calendar_today

Updated On:

Products

CA Automic Workload Automation - Automation Engine

Issue/Introduction

When a workflow is set with "Generate at Runtime" and "Allow simultaneous executions" left blank, and it is started within another workflow, the monitoring display functions correctly. The workflow status shows as “Ready to start,” and the next step is marked as “Preparing.”

However, an incorrect status appears when the same workflow is configured with "Generate at Runtime" and "Allow simultaneous executions" set to any value ie "1".

Upon starting the workflow again, it displays “Waiting for end of parallel jobs” instead of “Ready to start,” even though no parallel jobs are running.

See example below:

If we look inside the subworkflow:

After further investigation, it was found that a :WAIT 60 was set in the Preprocess of the Task - which is the reason why the Task would remain in Preparing Status for 60s.

After that time, the task would end correctly with this 60s delay:

Why does this "Waiting for end of Parallel task(s)" appear displayed during the time of the :WAIT transaction at the subworkflow level?

Environment

Automation Engine 12.x, 21.x and 24.x

Cause

Currently this is expected behavior, due to the function :WAIT as this script statement causes all open transactions of the script to be written to the AE database.

Resolution

Due to the logic of the Processing of the Tasks, the check of "Wait for end of parallel task(s)" executed right before the function :WAIT when it's been set at the subworkflow level, this status may be displayed temporarily and may cause confussion.

At the end of the :WAIT, the normal status will be retrieved and will be updated accordingly in the Workflow Monitor as shown above.

Even thought we recognize this is not ideal and may cause confusion, modifying this behavior that has been the same on every version could possibly break some other features and it won't be changed in the short future due to the high risk of inducing a regression in the task processing.

Additional Information

Feel free to raise an Idea in case you would like to have this behavior changed in the future.