HCL Workload Automation, Version 9.4

Migrating a workload to another HCL Workload Automation scheduling environment while maintaining dependencies

This scenario describes how you can split the workload between different HCL Workload Automation distributed environments, keeping the dependency flow. This situation can happen, for example, when specific activities are migrated to a newly added HCL Workload Automation master domain manager.

Business Goal

Two insurance companies are merged. Each of them has implemented its own HCL Workload Automation distributed solution to run a workload. As result of the merge, to avoid workload duplication and unify processes, some activities must be migrated from one master domain manager to the other.

To accomplish this task, the administrator of TWSA needs to ensure that the workflow dependencies are maintained even though part of the activities are moved to TWSB managed environment.

Figure 1 shows the workload flow that must be migrated from TWSA to TWSB:
Figure 1. Processing flow to migrate
The figure shows the processing flow to migrate

Roles

This section lists the user roles needed to run the scenario:
HCL Workload Automation Administrator
Manages HCL Workload Automation workload by creating and modifying jobs.
HCL Workload Automation Operator
Manages HCL Workload Automation workload by submitting and monitoring jobs.

Software requirements

The following software must be installed and configured, before running this scenario:
  • Two HCL Workload Automation networks.
  • A Dynamic Workload Console

Setting up the environment

To run this scenario do the following:
On TWSA
  • Ensure that the version of HCL Workload Automation installed is at least 8.6.
  • Define remote engine workstations that map TWSB master domain manager, and possible backup masters, and a dynamic pool workstation that contains all these remote engine workstations. This configuration helps you in managing, in a transparent way, failover situations or maintenance activities of TWSB master domain manager.
  • Verify that you can successfully telnet to the TWSB system using the port number specified in the remote engine workstations definition.
On TWSB
  • Ensure that the version of HCL Workload Automation installed is at least 8.6.
  • If you specified in the global option, bindUser, a user different from the TWS_user, ensure that the specified user has the required authorizations to bind the job stream containing JOB2, as well as JOB2 itself, in the plan.
  • Ensure that the resources that were needed to run JOB1 and JOB2 on TWSA are available with the same naming convention on TWSB.

Running the Scenario

About this task

To complete this scenario, as TWSA Administrator, you need to perform the following operations:
  1. Migrate JOB1 and JOB2 from TWSA to TWSB.
  2. Remove the dependency on JOB2 from the JOB3 definition.
  3. Define a shadow job on TWSA , JOB2SH, pointing to JOB2 running on TWSB
  4. Define a dependency on JOB2SH for JOB3 on TWSA.
Figure 2 shows the new workload flow between the two environments:
Figure 2. New processing flow
The figure shows the new processing flow

As TWSB Administrator, generate the plan on TWSB.

As TWSA Administrator, generate the plan on TWSA.

Then, as TWSA Operator, do the following:
  1. Log in to the Dynamic Workload Console to monitor the workload flow.
    Note: If the engine connection to TWSB was defined on the Dynamic Workload Console, then the TWSA Operator can monitor both the status of JOB2 defined on TWSB, and the status of the shadow job JOB2SH defined on TWSA, from the same user interface.
  2. Monitor when the status of the shadow job becomes BOUND. This means that the association of JOB2SH with the instance of JOB2 was established.
  3. Rerun and recovery of the JOB2 instance are managed automatically by the product and mapped to the shadow job status. If JOB2SH is submitted successfully, but then goes to ERROR, then you have to contact the TWSB administrator to understand why the bind failed.

Expected Results

You moved and automated the workflow dedicated to run an activity from one HCL Workload Automation environment to another, maintaining the workflow dependency.