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.
  To enable communication between two environments, you must establish a trust relationship so that each environment recognizes the other as valid. The agent that facilitates this communication must contain the security certificates for the remote environment. Before you configure cross-dependencies, ensure that you copy the required certificate files to the appropriate agent directory. For more information about configuring trust and managing the agent directory structure, see the following topics:

  • Folder structure and file management for HCL UnO agent in Unix operating systems
  • Folder structure and file management for HCL UnO agent in Windows operating systems
  • Deploying the product components

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.

Communication and network requirements

Cross dependency management relies on two communication phases: a subscription phase, where the source engine sends a subscription request to the remote engine to track the target task, and a notification phase, where the remote engine sends status updates back to the source engine.

Shadow task on HCL Universal Orchestrator, target task on a remote engine

The subscription phase is initiated by HCL Universal Orchestrator, through the agents associated with the workstation where the shadow task is defined, or through the Cloud Executor. The request reaches the UnO Gateway microservice on a HCL Universal Orchestrator target, or the Controller on a HCL Workload Automation for Z target.

The notification phase is handled by the remote engine, which sends status updates back to the UnO Gateway microservice.

Shadow task on a remote engine, target task on HCL Universal Orchestrator

The subscription phase is initiated by the remote engine (the HCL UnO agent, the Cloud Executor, or the HCL Workload Automation for Z Controller), which sends a subscription request to the UnO Gateway microservice. This request is authenticated with a dedicated Cross dependencies API Key generated in HCL Universal Orchestrator, which includes a target workstation name.

The notification phase is handled by HCL Universal Orchestrator, which sends status updates back using the agent or agents associated with the workstation specified in the API Key.

SaaSFor HCL Universal Orchestrator SaaS deployments, the UnO Gateway is exposed publicly over HTTPS (port 443) with a tenant-specific hostname.

On-premises remote engines must be able to open outbound HTTPS connections to the UnO Gateway; because they typically sit behind a firewall and are not reachable directly from the internet, select a local workstation or workstation pool when you define the shadow task or the API Key.

High availability configuration

Configure high availability (HA) for cross dependencies based on the direction of communication:

Inbound communication to HCL Universal Orchestrator

HCL Universal Orchestrator microservices run in an active/active model. Deploy HCL Universal Orchestrator for HA, with at least 2 PODs per microservice in Kubernetes, or at least 2 HCL Universal Orchestrator instances behind a load balancer for Docker and native installations. No additional external configuration is required, provided the UnO Gateway itself runs in HA mode.

Outbound communication from HCL Universal Orchestrator to remote engines

Where supported, use the Cloud Executor as the workstation for the shadow task and the API Key. If a local HCL UnO agent is required to traverse a firewall, assign a workstation pool with at least 2 agents instead of a single agent.