Workflow Definition — Overview

A workflow defines a series of steps (tasks) that are linked to each other and, therefore, build dependencies. One single action triggers the execution of all the tasks within a workflow according to the order defined in it. It is also possible to insert open branches in a workflow (unlinked tasks). Furthermore, not only internal but also external dependencies can be defined. This and the following topics deal with this.

Object Definition

Object class: Executable object

Object type/Short form: JOBP

Default Object Templates/Subtypes:

FOREACH

These workflows represent loops, that is, they repeat one or more tasks several times depending on the defined loop conditions.

For details on these workflows see ForEach Tab.
IF

hese workflows represent IF statements. They contain two branches to which you can assign tasks. Depending on the conditions you specify, one of the two branches will be processed.

For details on these workflows see If Tab.
STANDARD

You can add, order and link tasks in a standard workflow as you need.

You will find the following information in this topic:

General information on workflows
Special case: Unlinked tasks
Internal vs. external dependencies

Background/Purpose

A workflow is an object; an object added to a workflow and linked to a predecessor becomes a task with its specific properties. By linking tasks you create relationships between them and open new functions, like Dependencies and Conditions.

The workflow editor in the Process Assembly perspective allows you to build workflows using graphical tools. You insert tasks and rearrange them via drag and drop and link them using connector lines; you can have some tasks run in parallel and others consecutively. You can include any executable in a workflow (Events, File transfers, Groups, Jobs, Notifications, Scripts) and, of course, other workflows.

For each of these tasks you can define properties, thus building the workflow logic. You can for example:

Specify which states of predecessor tasks (one or more) are acceptable before the task starts, and what action to take based on the state of the predecessor tasks. For example should the task be skipped if a specific predecessor task that needs to provide input values fails?
Have the task check for certain values from other components or data sources, such as check that a certain file exists on the server before beginning.
Specify values for prompt sets of the tasks object or specify variables that the object can retrieve values from at runtime.
Define post-execution actions based on final executions, such as restart with e-mail notification at a job fail.
For all workflow tasks you can enable the option to allow the task to be rolled back, if the workflow is not successful.

You can then execute workflows manually at any time or schedule them to run at specific times. From the Process Monitoring perspective you monitor its progress and, if necessary, modify the properties of its tasks. If, for example, the execution fails, you can roll back to a specific task.

Special Case: Unlinked Tasks

As a rule, you define the order in which tasks are processed within workflows by linking them with connecting lines. However, there are situations in which you may want to have unlinked tasks in a workflow, that is, tasks without a predecessor/successor.

This applies only to Standard workflows; IF and ForEach workflows are linked automatically and, therefore always have a predecessor/successor.

The following rules apply to tasks in a workflow that are unlinked:

The system only waits for a branch without a predecessor and/or successor (open branch) if the workflow is not part of another workflow.
A workflow can contain a sub-workflow with an open branch. The processing of the sub-workflow continues and finishes even if its open branch is still processing a task. The superordinate workflow continues as soon as this sub-workflow gets to its END object and does not block. Please note that the setting Block and send abort signal to parent (Time & Dependencies properties tab), which sends messages to the superordinate workflow becomes obsolete when the superordinate workflow continues.
In workflows, you can also create completely open branches. These branches are then neither linked to the START object nor to the END object. They start when the workflow starts.
Forecast calculations also consider the open branches.

Internal and External Dependencies

Internal dependencies among tasks within a workflow are defined via the connector lines and the settings in the Time & Dependencies tab. However, defining external dependencies is also possible.

For example, you have WORKFLOW_A which contains JOB_A1 and JOB_A2. The internal dependency forces JOB_A1 to complete before JOB_A2 can start.

Now, let's suppose that you also have WORKFLOW_B containing two tasks, namely JOB_B1 and JOB_B2. You need JOB_B1 to wait for JOB_A1 to successfully complete before starting. This is an external dependency and you design it inserting JOB_A1 as such in WORKFLOW_B. It looks like this:

You will find detailed information on how to define such dependencies here: