Workflow Logic

Properties can be assigned to each task of a workflow which, as a result, can influence the order in which workflow tasks are executed. This topic explains the particular settings and their possible effects and provides a description of the internal processes of a task within a workflow.

The following table describes the order of the validation checks performed when tasks are executed and the option on the Graphical User Interface that you set for it. The diagrams below provide a graphical approach to the same.

The calendar conditions of the workflow tasks and their validity are checked when the workflow is activated. The activation aborts when the validity period of a calendar event has been exceeded. Tasks that are not processed because of calendar conditions obtain the status inactive only when the breakpoint has been deleted (provided that there is one).

Checking Order	Description	Field/Properties tab
	Repeated checks during workflow execution
Checkpoints	It is possible to specify one time checkpoint per task, which is then regularly checked while the workflow is executed. You can define an alternative task that is to be activated when a task was not started at the defined point in time.	Time Checkpoint (Time & Dependencies tab)
	Checking before the start of a task
All predecessors ended	A task always waits until all its direct predecessors have been executed!

Breakpoint	Breakpoints can be set in the properties and during the execution of a workflow. The workflow then changes to the status "blocked" at the specified points. Breakpoints can also be canceled with the appropriate command in the context menu of the Workflow Monitor.	Settings, General Tab

Calendar	It is also possible to have a task only executed on particular days. These days can be specified in calendar keywords. If the defined calendar condition does not apply, the task ends with the status ENDED_INACTIVE.	Calendar Tab

Earliest start	If a task must not start before a certain point in time, the earliest start time can be defined in here. The task waits until this point in time is reached, even if execution were possible before.	Earliest Start Time, Time & Dependencies tab

Active	If a task is part of a workflow but should not be executed, you can set it inactive. It obtains the status ENDED_INACTIVE in this case.	Settings, General Tab

Preconditions	You can define specific conditions and actions which will be processed before workflow tasks start. Your definitions can also affect the task's and workflow's executions. 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.	Preconditions, Preconditions, Postconditions, Conditions tab

Status of predecessors	Defining dependencies on the results of the previous tasks can also be useful. In the Else are you can specify the further handling of the task and workflow if one or all dependencies are not met. A task always waits until all its direct predecessors have been executed!	Dependencies section, Time & Dependencies

Latest start	A latest start time can also be specified. The task then ends with the status ENDED_TIMEOUT when this point in time has been exceeded. Additionally, it is also possible to specify an Else condition just as described above in the section status of predecessors.	Dependencies section, Time & Dependencies
or
Latest end	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 will not be executed and ends with ENDED_TIMEOUT. The handling specified in the Else section then becomes effective.	Dependencies section, Time & Dependencies
	Checking during task execution
Maximum runtime	A task's runtime can be monitored during the execution of the task, thereby enabling reaction to exceeded maximum runtimes. The task can be canceled or ended and/or another task be executed. Succeeding workflow tasks are continued as usual.	Runtime Properties
	Checking at the end of a task
Minimum runtime	At the end of task execution, it can be checked if the specified minimum runtime was kept. If not, the same settings can be defined as with monitoring the maximum runtime.	Runtime Properties

Final conditions and actions	When a task has ended, you can check further conditions or execute further actions. They can partly differ from the possible Preconditions and can also affect the task's or the workflow's status. The complete verification process takes only place once. This functionality is useful to react to a task's end status. You can start any object or cancel a workflow or task if a particular status has been reached or not. Note that the condition STATUS is not considered if the task obtains the status ENDED_INACTIVE. You can still check this end status in the Time & Dependencies tab of the successive task.	Postconditions, Preconditions, Postconditions, Conditions tab

Workflow Validation Checks - Graphics

These diagrams illustrate the internal processes that tasks undergo when they are part of a workflow.

PromptSet dialogs are displayed only during the start of the workflow task if you have defined it so in its Prompts Tab.

ELSE Condition