Here is v1.0 of the tool I developed for defining dependencies between AE systems.
Introduction
The tool is designed to replicate the options and behaviors of the AE's own built-in External Dependency feature. For this reason, the tool includes the abbreviation EXTDEP in its name. It works like this: you insert the EXTDEP workflow in the place where you would normally define an external dependency. Click on the child workflow, click the Properties button on the right side of the workflow toolbar, and then click on the PromptSets tab in the lower frame to reveal the dependency options.
The EXTPDEP workflow is designed such that it can be used as a drop-in replacement for External Dependencies. For this reason, the EXTDEP prompt set is designed to mimic the External Dependency options as closely as possible.
EXTDEP options in detail
As depicted above, the options for the EXTDEP prompt set are almost identical to the ones for the built-in External Dependency feature. However, there are some small differences. Note that in the descriptions below, the term this workflow means the workflow inside which the EXTDEP workflow is placed as a child/predecessor task.
| Option |
Description |
|
Remote task *
|
The name of the predecessor task in the remote system. The task can be any executable UC4 object.
* A value in this field is required.
|
| Within parent |
The name of the parent workflow of the predecessor task |
| With alias |
The alias of the predecessor task |
| With parent alias |
The alias of the parent workflow of the predecessor task |
| Check expected status |
The status of the predecessor task must match a status code included in the condition selected here. Default: ANY_OK_OR_UNBLOCKED.
See the Broadcom AE documentation for a list of conditions and their respective status codes.
|
|
Remote task
|
was activated with the same logical date as this workflow
|
The remote task must have the same logical date as this workflow. |
|
ended after the end of the previous run of this workflow
|
The remote task must have ended after the end of the previous run of this workflow. (Default) |
|
ended after this workflow start
|
The remote task must have ended after the start of this workflow. |
|
ended within a specific margin before this workflow start (see next field)
|
The remote task must have ended within a certain margin before the start of this workflow. |
| Margin (minutes) |
The margin before the start of this workflow within which the remote task must have started. This value is applicable only if 'ended within a specific margin…' is selected above. Format: Minutes. |
| Mismatch action |
Wait |
Keep trying. (Default) |
| Skip task |
End the EXTDEP workflow with status ENDED_OK. |
| Cancel the workflow |
Cancel this workflow. |
| Execute another object on mismatch |
Check this checkbox to execute another object the first time a mismatch occurs – that is, the first time the dependency checker fails to find a predecessor task in the remote system that matches the above specifications. |
| Define timeout |
Check this checkbox to enable the three timeout options below. |
| Timeout (minutes) |
The time interval after which a timeout should be considered to have occurred. Format: Minutes. |
| Timeout action |
Wait |
End the EXTDEP workflow with status ENDED_NOT_OK. (Default) |
| Skip task |
End the EXTDEP workflow with status ENDED_OK. |
| Cancel the workflow |
Cancel this workflow. |
| Execute another object on timeout |
Check this checkbox to execute another object if the timeout interval is reached. |
| Object to execute |
The name of the external object that should be executed if a mismatch or timeout occurs. The external object will be executed no more than one time. |
| Check interval (minutes) |
The number of minutes to wait between subsequent checks. Each check requires launching a REST job to check for matching tasks in the remote system, so please do not set this lower than 5 minutes unless absolutely necessary. Format: Minutes. Default: 10 minutes. |
How it works
SYSTEM.GLOBAL.EXTDEP.JOBP is a workflow containing a single REST job. This job uses the UC4 REST API to query the remote UC4 system and check for completed runs of the specified predecessor task. If a matching task is found, the REST job ends OK. If no matching task is found, then the Mismatch action comes into play. For instance, if the mismatch action is Wait, the job waits for the specified Check interval and then tries again. If the Define timeout option is enabled and the Timeout interval is reached, then the Timeout action comes into play, e.g., Cancelling the parent workflow.
A particular remote task cannot fulfill the same dependency twice. The EXTDEP workflow tracks already-resolved dependencies in the VARA object SYSTEM.GLOBAL.EXDEP.RESOLVED_DEPENDENCIES.VARA_STATIC. The unique identifier of a dependency is the combination of:
- the parent workflow name; and
- the task ID (Lnr) of the EXTDEP workflow within the parent workflow.
Customizing EXTDEP for your environment
Before you can use this tool in your environment, you'll need to change SYSTEM.GLOBAL.SET_REMOTE_SYSTEM.JOBI and update it with a mapping of local and remote system names. The tool is currently designed based on the assumption that there is a one-to-one relationship between local system and remote system for each environment (experimental, development, testing, and production). That is, when the EXTDEP workflow runs in the local development system, it always checks for tasks in the remote development system, and vice versa. This is the use case for which the tool was developed, but obviously you could update the tool for your needs, e.g., adding a pick list to the prompt set for selecting the remote system.
You'll also need to create one connection object per system. See SYSTEM.GLOBAL.SET_REST_CONN.JOBI for the expected naming convention.