Task Status in Workflows (Status within Parent)

When a task executes from within a Workflow, it has two different types of statuses:

• Task Execution Status

  When a task executes, no matter whether as a stand-alone object or from within a Workflow, it undergoes many statuses that describe what is happening/has happened to the task. This task status is also displayed when it executes in a Workflow.

• Task Status within Parent

  This is the status of the task in the context of the Workflow. It depends on how both the Workflow and the task in the Workflow is configured (the task Properties).

These statuses are often different for two main reasons: Workflow configuration and performance. This topic explains why.

Different Statuses Due to Workflow Configuration

Workflows react to the status of their individual tasks according to the specific properties that are defined for each task. These properties are parameters that apply exclusively when the task is executed from within the Workflow, they are not saved with the object itself. For example, you can set a breakpoint, define time and status dependencies, specify post conditions, and many more. As a result of the actions that the Workflow takes based on these properties, its tasks have specific statuses that describe their state in the context of the Workflow itself. This is the task Status within Parent that is displayed in the Details pane in the Workflow monitor.

On the other hand, the task has its own execution status. status, which is often different to the status within parent.

Automic Automation saves these two types of status of a task in a Workflow in different database tables and displays them in the Process Monitoring perspective in the following places: List of Tasks, (Status column and Details pane), Workflow monitor (task box and Details pane) and in the Executions list (Status column and Details pane).

Example

A Workflow with three tasks (three Windows Jobs) handles database maintenance activities: BACKUP_DATABASE, START_DATABASE and START_FRONTEND. We have set a breakpoint on the third task (START_FRONTEND). When we execute the Workflow and open its monitor, this is what we see in the Details pane (the START_FRONTEND task is selected, so the pane shows its details):

• BACKUP_DATABASE is still executing so its status is Active.

• START_DATABASE is waiting for BACKUP_DATABASE to end, its status is Waiting for predecessor.

• We have set a breakpoint in START_FRONTEND. This is a Workflow configuration that affects the behavior of the Job in the context of the Workflow only. As a result, the status of the task within the Workflow is HELD - Manual stop has been set. This is displayed in the Status field in the Status within Parent section of the Details pane.

  Additionally, the Status field in the General section (the upper part of the Details pane) and the Job Status field in the Status within Parent section show the same status, namely the actual status of the task.

This status information is also available in the Tasks list and in the Executions list. For example:

Different Statuses for Performance Reasons

When a task executes, whether from within a Workflow or as a stand-alone object, it undergoes many different statuses. For example, during the time that a task is Active, it goes from Waiting for Generation to Generating to Ready for Start, and so on. Depending on the object configuration and its dependencies to other objects (Sync objects, Calendars and so forth), the task will go though many different statuses. The transition from one status to another is very fast.

When a task runs from within a Workflow, all these specific Active sub-statuses are irrelevant. Updating the Workflow to display each specific status would have a negative impact on its performance. For this reason, the status of the task in the Workflow is displayed as Active. However, the status of the task itself can be different, namely, any of its potential sub-statuses.

See also:

• Workflows (JOBP)

• Task Status