External Dependency Tab

Ext. task [(Parent)]

The name of the external task. If it runs in a workflow, the workflow name is additionally shown in parentheses.

An alias for the external dependency.

As opposed to other tasks, an alias of an external dependency serves as a filter. This means that when you assign an alias to an external dependency, the external task must also show this alias. Otherwise, the external dependency cannot be fulfilled.
For example: You define the alias ALIAS01 for an external dependency that points to the task JOB01. Therefore, the external dependency will only be fulfilled when the task JOB01 starts with the alias ALIAS01.

Maximum length: 200 characters
Allowed characters: A-Z, 0-9, $, @, _, -, .

Predefined variables, placeholders for Variable objects and object variablescan also be used. The variables always refer to the workflow that includes the external dependency. Click in order to open the Variable Picker dialog.

In the UserInterface settings, you can define if and when the dialog should open in which you define an alias name when you add a workflow task by using the drag & drop function.

Every script variable of the workflow will be resolved for an alias, if the variable is also used within the workflow script.
If &$NAME# should be part of the alias, it is necessary to use &$NAME# somewhere in the workflow script, even if it is only with :PRINT&$NAME#

Alias for the external task's workflow.

This field is only available if the external task stems from a different workflow. Proceed as follows in order to insert a workflow task into a different workflow as an external dependency: Drag the relevant workflow task by keeping the ALT button pressed and drop it in a different workflow.

The same limitations and rules apply as for the Alias field.

When the external dependency points to a task that runs within a workflow, the system additionally limits its verification to the alias and the parent alias (if specified). This means that when an alias and/or parent alias is defined in the properties of the external dependency, these fields are compared with the alias of the external task or the alias of its workflow. The external dependency can only be fulfilled when they comply with each other.

Only valid, when...

This setting can be used instead of the lead time satisfaction. It checks whether the external task has been activated on the same logical date as the workflow. Executions that have already ended and executions that are still active are considered. They are compared with the external task's activation date.

If the logical dates match, the external task's end status is compared with the expected status and the Else condition is applied if needed.

The dependency is ignored and obtains the status ENDED_INACTIVE if the external task has not run or is not running on the same logical date.

For example:

The workflow "MM.FRIDAY" is processed on March 24. It obtains an external dependency to the job "GET.FILES". This job has started a short time before the workflow has started. Therefore, the external dependency is considered.

The external dependency ends with status ENDED_INACTIVE if the job's last statistical record has been written on March 23.

The external task's activation date is only checked if the external dependency's succeeding task is allowed to start.

Expected status

The status that is expected for the external task's end of execution.

If no status is selected, the system only checks whether the task has ended within the lead time satisfaction. Its status (such as ENDED_OK, ENDED_CANCEL) is irrelevant in this case.

• ANY_OK_OR_UNBLOCKED - The external task ends without an error or the blocking condition of the workflow that includes the external task has been removed.

• ENDED_OK_OR_UNBLOCKED - The external task ends with ENDED_OK (return code 0) or the blocking condition of the workflow that includes the external task has been removed.

If one of these special status options is set, the external dependency will also be fulfilled when the external task runs within a workflow whose blocking condition is removed subsequently and manually.

Note that the information about removing a blocking condition only refers to the workflow of the external task. This condition is irrelevant if the external task does not run in a workflow.

Lead Time Satisfaction

Details about the lead time satisfaction are available in a separate document.

Since last workflow execution

The lead time commences at the end of the workflow's last execution. The status of this last execution is irrelevant in this case.

If no previous workflow execution is available, the workflow uses its own start time as the beginning point of its lead time satisfaction. This happens in the following situations:

• The statistical records have been removed using utilities.
• The Workflow object has newly been created.
• The Workflow object has been duplicated.

The first item requires that databaseA database is an organized collection of data including relevant data structures. reorganization intervals are considered.  For example, a workflow that runs once a week  cannot find any statistical records if these records are deleted every day.

Within ... before workflow start

The lead time satisfaction commences before the workflow starts. The length of this period depends on the value that has been specified. There is a limit if the end of the last workflow execution also lies within this period.

After workflow start

The lead time satisfaction commences when the workflow starts.

Else

This area serves to define a reaction to the external task that has never achieved the expected status in lead time satisfaction or if it has not ended.

Wait

The time specified in the area Timeout is the waiting time. After this period of time, the external task is rechecked.

In the following constellations, the system does not wait for the timeout:

1) The variable UC_SYSTEM_SETTINGS includes the entry EXTERNAL_CHECK_INTERVAL that the administrator can use in order to define an interval in which the status of external dependencies is checked. 

2) An external task can also have several successors. Successor A could be in a waiting condition and successor B is checking the external task. If the check result is that the expected status has been reached, the processing of successor A and B continues (provided that all other predecessors have also ended).

Skip

The external dependency is skipped.

Workflow cancel

The workflow that contains the external dependency aborts.

Alarm

Activate this checkbox and determine the object that should be executed in "Alarm object."

Timeout

Settings that are defined here are only considered if "Wait" has been checked in the Else area.

Timeout after ...

Time span for waiting.

The value of "MIN_EVENT_INTERVAL" which is set by the administrator in the variable UC_SYSTEM_SETTINGS also affects the time span. Because it defines the minimum value, it is used if the timeout value lies below the value that is specified in MIN_EVENT_INTERVAL.

Wait

The workflow's execution is in a waiting condition without limitation. Manual action is needed.

Timeout is repeated in the intervals specified in timeout after... If you have specified an Alarm object, it starts whenever a timeout occurs.

Skip

The external dependency is skipped.

Workflow cancel

The workflow that contains the external dependency is aborted.

Alarm

Activate this checkbox and determine the object that should be executed in "Alarm object."

Alarm object

Enter the name of the object that can be called by clicking on the three dots, or select it in the Explorer.