Workflow Logic

The order in which tasks are inserted in a Workflow and the connectors between them determine the task processing sequence. However, as a developer and object designer, you can define tasks properties that alter that sequence.

The graphics in this topic illustrate the internal processes that tasks undergo when they are part of a Workflow. In the following graphics, green ELSE Condition processes indicate that sub processes start. The Description sections after the graphics provide an explanation of the processes. They also contain links to the related topics in the documentation.

Processes until the Task Starts

Description

1. Have all predecessors been processed?

   A task always waits until all its direct predecessors have reached the expected status, such as Skipped or Ended. Its status is Waiting for predecessor if they have not ended yet.

2. Is a breakpoint set in the task?

   All predecessors have ended. The system checks if a breakpoint has been defined for the task.

   Breakpoints cause the Workflow to stop at this point. The Workflow changes to BLOCKED. Breakpoints can be canceled in the Workflow monitor.

   Where to set a breakpoint: Set Breakpoint in the General Tab

3. Are Calendar conditions assigned to the task?

   If there is no breakpoint or if it has been canceled, the system checks whether Calendar conditions have been assigned to the task.

   You can specify that tasks should be executed on particular days only. These days are defined in Calendar Events. If the defined Calendar condition does not apply, the task is not executed and it ends with the status ENDED_INACTIVE.

   Where to set it: Calendar Tab

4. Is an earliest start time defined?

   If there are no Calendar conditions or if they apply, the system checks the earliest start time.

   If a task must not start before a certain point in time, you can define its earliest start time. The status of the task is Waiting for start time.

   Where to set it: Earliest Start Time in the General Tab

5. Is the task set to Active?

   When you add a task to a Workflow, it is set to Active by default. That is, the task is executed as soon as it is its turn. You can deactivate it if you want the Workflow to stop at this task.

   Where to set it: General Tab

6. Are preconditions defined for the task?

   You can define specific conditions and actions to be processed before Workflow tasks start. These processes can also affect the execution of the task. The verification is made in the time interval that has been specified in the variable UC_SYSTEM_SETTINGS, setting CONDITION_CHECK_INTERVAL. This process ends if the final action of the latest start time has been reached.

   This step is skipped if there are no definitions for Preconditions.

   In ForEach workflows, you can define whether the preconditions of the individual tasks should be evaluated only once or repeatedly in each loop iteration. See FOREACH Workflows

   Where to set it: Preconditions tab, see Preconditions, Postconditions, Conditions

7. Do the predecessors have the statuses defined in the task?

   If the task has no preconditions or if these have already been processed, the system checks the status with which the predecessors have ended.

   You can defined the status that the predecessors should have for the task to start. You can also specify he further handling of the task and Workflow if one or all dependencies are not met.

   Where to set it: Dependencies section in the Time & Dependencies tab

8. Is a latest start or latest end defined?

   If the status of the predecessors match or if no specific status is defined, the system checks the latest start or end time defied for the task.

   The task ends with the status ENDED_TIMEOUT when this point in time has been exceeded. It is also possible to specify an Else condition as described in the previous step.

   When starting the task, its expected runtime (ERT) can serve as a basis for calculating the expected end time. If the result exceeds the defined time, the task is not executed and ends with ENDED_TIMEOUT. The handling that is specified in the Else section becomes effective.

   Where to set it: Dependencies section in the Time & Dependencies tab

9. Are PromptSets assigned to the task?

   If the tasks has PromptSets, they are evaluated now. The values provided by the PromptSets are used in variables and VARA objects. If user input is necessary, the status of the task is Waiting for user input.

   Where to set it: Prompts Tab

10. Is the task already generated?

    The task generates either at activation time or at runtime depending on its setting on the Attributes page. If it is set to generate at activation time, at this stage of the process the task has already generated. This is because the activation time of a task in a Workflow is the activation time of the Workflow itself.

    If it is set to activate at runtime, the task generates now.

    For more information, see Generating at Activation or at Runtime.

11. The task starts. It goes through the 3. Processing and 4. Completion stages.

Processes After the Task is Generated

At this point of the task execution there are two possible scenarios.

• The task ends and the minimum runtime is evaluated
• The maximum runtime is evaluated and, if it has been exceeded, the follow-up actions are carried out

This graphic illustrates both scenarios:

Exceeded Maximum Runtime

A task runtime can be monitored during its execution. This monitor helps you react quickly to exceeded maximum runtimes. You can define what should happen if processing the task takes longer than predefined. The task can be canceled or ended, or  another task be executed. The following Workflow tasks are processed as usual.

If the maximum runtime is not exceeded, the task ends and the next task starts. Where to set it: Runtime Properties

Minimum Runtime not Met

At the end of task execution, the system can check if the specified minimum runtime has been kept. A task not running as long as usual is an indicator that something has gone wrong.

If the runtime is shorter that defined, the same settings can be specified as with the maximum runtime.

Where to set it: Runtime Properties

Post Processes

When a task has ended, you can verify further conditions and execute further actions. These actions can differ from the Preconditions and can also affect the status of the task or of the Workflow. The complete verification process takes place only once.

This functionality is useful to react to the end status of a task. You can start any object or can cancel a Workflow or task if a particular status has been reached or not.

Note: The condition STATUS is not considered if the task obtains the status ENDED_INACTIVE. You can still verify this end status in the Time & Dependencies tab of the successive task.

Where to set it: Postconditions tab, see Preconditions, Postconditions, Conditions

ELSE Condition

Some properties let you define alternative actions. This graphic illustrates the possibilities of the Else condition: