External Workflow Dependencies

An external dependency in a Workflow is the representation of an external task that must end with a specific status for one or more tasks in the Workflow to start processing. This means that external dependencies are predecessors of one or more tasks within the Workflow. To differentiate external dependencies from the rest of the tasks in the Workflow, their task boxes have dotted lines.

After adding an external dependency and connecting it to its successor, you define the status that the external dependency must have for its successor to start running. You do this in the Time & Dependencies tab of the successor task.

The status of the external task is not the same as the status of the external dependency. An external dependency can only have one of the following status:

ENDED_OK

the external task's expected end status occurred. Thus, the external dependency is fulfilled
ENDED_INACTIVE

the external dependency is inactive due to calendar conditions or manual interference
ENDED_SKIPPED

the expected end status of the external task did not occur within the defined time span. According to the specification made in the external dependency, it is skipped.

External dependencies can only be defined within standard workflows.

To Define External Dependencies in Workflows

Insert the external task.
1. Right-click on any empty space on the editor.
2. Select Add existing Object.
3. In the Add Existing Object dialog scroll through the folder structure to find the task and select it.
4. Activate the Insert as External Dependency checkbox.
5. Click OK.
Connect your external dependencies with one or several workflow tasks. These tasks are then succeeding the external tasks. External dependencies of workflows do not have predecessors.
Define the expected end status of the external task:
1. Right-click the task box and select Properties. The properties pane contains two tabs, Calendar and External Dependency.
2. Open the External Dependency tab. Here you retrieve the external task's end status.
  For example:
  The above example checks whether the external task ended with the status ENDED_OK since the last time the workflow has been executed. If not, or if it has not been executed in the specified period of time, a waiting time of 1 hour is defined. The workflow aborts if the expected status could still not be achieved after this timeout period and executes TASK 2.

The table below describes the available options:

Command	Description
Task Definition section
External Task	The name of the external task.
Within Parent	All potential parent workflows, that is, any other workflow where this task is included. This field is only available if the external task stems from 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.
With Alias	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, $, @, _, -, . You can also use predefined variables. They always refer to the workflow that includes the external dependency. 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#
With Parent Alias	Alias for the external task's workflow. This field is only available if the external task stems from 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.
Execution Settings section
Check 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 time as defined in the option group below (Check if the external task was activated with the same logical date as the workflow). 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.
Check if the external task was activated with the same logical date as the workflow	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.
Check if the external task end is	Indicates when the expected end status should be checked: after the last workflow execution end Checks start 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. 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 database 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 hh:mm:ss before this workflow start Checks start 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 this workflow start Checks start when the workflow starts. See External Task End Check for examples and illustrations that may help you understand this concept.
Else section
Wait	The time specified in the Define Timeout area 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: 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. 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.
Cancel the workflow	The workflow that contains the external dependency aborts.
Action: Execute another object on mismatch	Activate this checkbox and, in the Execute field determine the object that should be executed if the conditions are not met.
Define Timeout	Settings that are defined here are only available if Wait has been checked selected. 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. Cancel the Workflow The workflow that contains the external dependency is aborted.
Action: Execute another object on timeout	Activate this checkbox and in the Execute field define the object that should be executed if the conditions are not met.
Execute	Select the object that should be executed.

Agent Groups in Mode "All"

This setting means that the agent group processes a task on all its agents. If an external dependency has been set on this task in a workflow, the external dependency is fulfilled when one of the tasks has ended. The workflow does not wait until the tasks have ended on all agents.