External Dependency Tab

As a developer and object designer, after inserting and connecting a task as external dependency in a Workflow, you define its properties on the External Dependency tab. This topic provides instructions to configure the properties of an external dependency in a Workflow.

For more information, see External Dependencies in Workflows.

This page includes the following:

Task Definition Section

The external dependency task can be part of other Workflows. In this section, you indicate which instance of the task you want to establish the connection to.

The Within Parent drop-down list contains all the Workflows in which this task is inserted. Select the Workflow in which the instance of the task that you want to use is inserted.
Tasks can be inserted multiple times in a Workflow. Their names and titles (if available) are always the same. The alias, however, is unique and refers to one instance of the task within a Workflow.

Enter the alias of the instance you need in With Alias.
Workflows can be embedded in other Workflows. Embedded Workflows behave like any other task in a Workflow. They can also be inserted multiple times and they can have an alias that uniquely identifies them.

In With Parent Alias, enter the alias of the parent Workflow that is inserted in yet another Workflow.

Input information for With Alias and With Parent Alias:

Maximum length: 200 characters
Allowed characters:
- A-Z, 0-9, $, @, _, -, ., {, } and &
- The characters that your administrator has defined as acceptable in the ALIAS_SPECIAL_CHARACTERS key in the UC_CLIENT_SETTINGS system variable. For more information, see UC_CLIENT_SETTINGS - Various Client Settings.
You can enter variables in these fields. They must be the same variables that are used in the task alias fields in the Workflows where they are inserted.
If &$NAME# should be part of the alias, use &$NAME# somewhere in the Workflow script, even if it is only with :PRINT&$NAME#

Execution Settings Section

In this section you define the following settings:

The status that the external dependency must have for its successor to start processing
The period within which the external task must end with the status that you have specified
What should happen if the conditions that you have defined are not met

To Configure the Execution Settings Section

(Optional) In Check Expected Status, select the status that the external task must have to be considered in this Workflow.

If you do not select anything, the system ignores the task status and only checks whether the time conditions (activation and end time) are met.
Define when the expected status should be checked:
- Activate Check if the external task was activated with the same logical date as the Workflow if you want the system to compare the activation time of the external task with the Workflow logical date.
  - If they match, the end status of the external task is compared with your selection in Check Expected Status. If necessary, the Else conditions are applied.
  - If the dates do not match, the external task is ignored. The status of the external dependency is set to ENDED_INACTIVE and the Else condition applies.
- Select Check if the external task end is to specify the period within which the external task must have ended with the status that you have specified.
  
  Important! If the external dependency end time does not lie within this period, the successor task in the Workflow is not processed and the settings in Else (on condition mismatch) are applied.
  - Select after the last workflow execution end if you want the system to check the status of the external dependency as soon as the previous execution of the Workflow has ended. The status with which the previous execution has ended is irrelevant for this check.
    
    If no previous execution is available, the Workflow start time is used as time reference here. Previous executions are not available in the following cases:
    - the Workflow is new
    - the Workflow is a new duplicate of another Workflow
    - the execution data of the Workflow have been removed using the utilities
  - Select hh:mm:ss before this Workflow starts to define the period within which the external task must have ended.
    
    The period that you define here starts before the current execution of this Workflow starts. This graphic illustrates it:
    
    Important! The system is designed to avoid overlapping situations. This means that an instance (an execution) of a task is used in only one instance (execution) of the Workflow in which it is referred to as external dependency.
    
    Example:
    
    Consider the situation illustrated in this graphic:
    
    The external task must end successfully two hours before the Workflow starts, so you select within 2:0:0 hh:mm:ss before this workflow start.
    
    08:00 - The external task ends successfully
    
    12:00 - The Workflow starts but it must wait because the execution of the external task is too old; it ended before the designated hour before the Workflow start
    
    12:05 - The next (second) execution of the external task ends successfully
    
    12:05 - The Workflow can continue its execution now because the second execution of the external task ended successfully within the designated two hours before its start
    
    12:10 - The Workflow ends successfully
    
    13:00 - The next execution of the Workflow starts but it must wait. Although the latest execution of the external task lies within the designated two hours, that execution has already been considered by the previous Workflow execution. In this case, the designated hour starts with the end of the latest instance (execution) of the Workflow, namely at 12:10.
  - Select after this Workflow start to consider the status of the task only if it ends after the start of the current Workflow. This graphic illustrates it:
In the Else (on condition mismatch) section you specify what should happen if the previous status and time conditions are not met:
- Select Wait if you want the Workflow to wait and, if there is a timeout, to define what should happen.
  
  Activate Define Timeout to expand a section where you define the period you are willing to wait and what should happen afterward. After this period of time, the external task is rechecked. You have the following options:
  - Select Timeout after to define the time you are willing to wait.
    
    The value of "MIN_EVENT_INTERVAL" that is set by the administrator in the UC_SYSTEM_SETTINGS variable also affects the timespan. It is used if the timeout value lies below the value that is specified in MIN_EVENT_INTERVAL.
  - Select Wait to stop the execution until a user manually intervenes.
    
    The timeout is repeated in the intervals specified in Timeout after. If you have selected Notification (CALL) object to be executed if there is a timeout, it starts whenever a timeout occurs.
  - Select Skip to ignore the external dependency.
  - Select Cancel the Workflow if you want the Workflow that contains the external dependency to abort.
  In the following constellations, the system does not wait for the timeout:
  - The UC_SYSTEM_SETTINGS variable includes the entry EXTERNAL_CHECK_INTERVAL . The administrator can use it to define the interval in which the status of external dependencies is checked. For more information, see UC_SYSTEM_SETTINGS - Systemwide Settings.
  - An external task can 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, A and B continue processing after all predecessors have ended.
Activate Action: Execute another object on timeout and select the object that should be executed if there is a timeout.
Save your changes