Cross dependencies definition

Prerequisites

To configure cross dependencies, ensure the following requirements are met:

• Connection parameters: It is highly recommended to define an Endpoint item to handle the connection to the remote engine. The endpoint replaces the legacy Remote engine workstation functionality and encapsulates the connection parameters (URL and Port) required to communicate with the target system. While highly recommended for security and reusability, setting an endpoint is not mandatory. Connection parameters can alternatively be defined inline directly within the shadow task connection panel.
• Authentication: Communication between engines is secured using Cross dependencies API Keys. Generate an API Key on the target engine and configure it within the endpoint definition (or inline within the task connection parameters) on the local HCL Universal Orchestrator engine to authenticate the bind requests. Find out more in Managing authentication using API Keys.
  Note: Cross dependencies API Keys are valid only for HCL Universal Orchestrator to HCL Universal Orchestrator connections. The API Key must be created on the remote engine and used on the local engine where the shadow task is defined. For connections to HCL Workload Automation for Z, the connection JWT must be provided by an administrator of the remote engine.

Overview

You can synchronize processes running on HCL Universal Orchestrator with those running on remote engines, including other HCL Universal Orchestrator instances and HCL Workload Automation for Z.

This capability enables you to extend your orchestration beyond a single environment, creating a hybrid automation landscape where a local workflow waits for the successful completion of a task on a remote mainframe engine before proceeding.

Shadow tasks

To implement a cross dependency, define a Shadow task in your HCL Universal Orchestrator database from the Graphical Designer. A shadow task is a specific task type that does not perform any actual work: it represents a task running on a remote engine and shadows its status.

The shadow task acts as a proxy. When you add a shadow task to a workflow, you create a dependency on the remote operation it represents. The workflow does not proceed until the shadow task reaches a successful status, which happens only when the remote task completes successfully.

This enables you to visually filter and select the target workstation, workflow, or task from a generated list. Upon selection, the system automatically populates all the required target identification fields in your shadow task definition, preventing manual entry errors and ensuring accurate bindings.

Data flow and binding

The communication between the HCL Universal Orchestrator engine and the remote engine follows a specific binding process:

1. Submission: When the workflow containing the shadow task is submitted, the shadow task is set to WAIT status.
2. Binding request: The shadow task sends a binding request to the remote engine. This request contains the information necessary to identify the target task (workstation, workflow, and task name).
3. Registration: The remote engine searches for the target task in its plan.
   • If the target task is found, the remote engine registers the shadow task as an external dependency. The shadow task status in HCL Universal Orchestrator changes to BOUND.
   • If the target task is not found, or if it does not satisfy the matching criteria, the bind fails, and the shadow task fails.
   Note: As the target task runs on the remote engine, the remote engine sends status notifications (such as STARTED, SUCCESSFUL, or ERROR) back to the shadow task in HCL Universal Orchestrator. The shadow task updates its status to reflect the remote task status.