Inside Automation Engine > Workflow > Workflow Logic

Workflow Logic

Properties can be assigned to each particular task of a workflow which as a result, can influence the order in which workflow tasks are executed. Detailed description about the tabs and the fields/control elements are found in the User Guide. This document serves to explain the particular settings and possible effects. The order in which the different settings are checked is significant.

The following table describes the logical checking order in writing, the workflow logic diagram gives details in pictures.

The calendar conditions of the workflow tasks and their validities are checked when the workflow is activated. The activation aborts when the validity period of a calendar key 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	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.	Checkpoint
	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.	Earliest

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

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.	Earliest

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 would be possible before.	Earliest

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

Status of predecessors	Defining dependencies on the results of the previous tasks can also be useful. In the Else section, 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

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
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
	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
	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

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 by using the Dependencies tabof the successive task.	Postconditions