Workflow 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

This topic provides information on the following:

Overview

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 relationships between tasks 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:

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.

Not only the position of the tasks in the workflow and their connections determine the order in which they are processed; some of the properties that you can define in the tasks also play an important role to decide when they are executed. Have a look at Workflow Logic, where these dependencies are described.

See Working with the Workflow Editor.

Types of Workflows

When executing a STANDARD workflow, you can still modify its design from the Workflow Monitor, provided it is either active or stopped; that is, if it has already started or if it is in generation. For this purpose, you open the Workflow Monitor and click the Modify button on the toolbar; this stops the Workflow and makes it editable.

However, FOREACH and IF workflows cannot be modified at runtime. This is the reason why the button is always disabled on their monitors.

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:

Internal and External Dependencies

Dependencies in workflows allow you to synchronize the execution of tasks. On the one hand, 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 TASK_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:

Dependencies are object-based only: an object is dependent on another executable object.

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

Conditions in Workflows

As happens with external and internal dependencies, conditions serve to orchestrate the execution of tasks depending on certain situations. However, they are not object-based. Rather, they point to external elements instead, such as system resources, files that are available or not, etc. For example, a job can only execute if a file is present in a particular directory.

Next Steps:

  1. Start creating a Workflow: Adding Objects.

    Although you can change the name of the object later on, we recommend that you define and apply consistent naming conventions to your objects. You can find some useful ideas at Using Consistent Naming Conventions for your Objects.

  2. As happens with all other objects, Workflows have several definition pages. You can start defining the standard ones now or you can leave it for later. See Defining the Standard Pages.

    Some of the most important Workflow parameters are defined on its Attributes Page, such as the settings that determine when tasks will be activated (see 2. Generation) or whether the tasks in the Workflow should use all the same Agent in an Agent Group or not.

  3. You add, arrange and work with the tasks in a Workflow using the editor; see Working with the Workflow Editor.

  4. Apply properties to the tasks in the Workflow. Properties affect the order and outcome of the Workflow executions. See Defining Task Properties in Workflows.

    Have a look at Workflow Logic, where you can find a description of the validation checks that take place during the execution of a Workflow; the graphic at the bottom of the topic will help you understand how and when the properties defined for each task affect the order and outcome of the task executions.

  5. Once you have finished defining the Workflow parameters and the properties of its tasks, you can execute it. See Executing Workflows.

    Consider the special case of external dependencies, that is, tasks that affect the execution of the Workflow although they are not inserted in it. See External Workflow Dependencies.

  6. If necessary, you can modify the design and properties of the Workflow at runtime. See Modifying Active Workflows at Runtime.

See also: