Installing agents

How to install an HCL Workload Automation fault-tolerant agent or dynamic agent in your distributed or end-to-end network by using the twsinst script.

About this task

This picture describes the steps required for installing the master domain manager. You are now at step 7: installing the Dynamic Workload Console

When you install a fault-tolerant agent, also the remote command line client is installed.

Use only the twsinst script to install agents. If you are installing a dynamic agent, you can optionally add the Java run time which is needed to run job types with advanced options, and to configure a gateway to open communication with the dynamic workload broker.

When you install a dynamic or a fault-tolerant agent, also the following access methods, that extend the job scheduling capabilities of HCL Workload Automation to other software products, are installed:
PeopleSoft
To run and monitor PeopleSoft jobs from the HCL Workload Automation environment.
SAP R/3
To create, schedule, and control SAP jobs by using the job scheduling features of HCL Workload Automation.
z/OS
To define and schedule jobs that run in a z/OS environment with JES2, JES3, or HCL Workload Automation for Z
See Scheduling Applications with HCL Workload Automation for details about configuring and using the access methods.
During each step of the installation process, the twsinst script creates files in the installation directory that you specified in the command. If you do not specify an installation directory in the -inst_dir option in the command, the script creates files in the following directories:
On Windows operating systems
%ProgramFiles%\HCL\TWA_TWS_USER
On UNIX operating systems
/opt/HCL/TWA_TWS_USER
Where TWS_USER is the user for which you are installing the HCL Workload Automation instance that you specify in the command.

The dynamic agent installation process automatically adds the workstation definition to the database and registers the workstation definition to the dynamic workload broker installed on the master domain manager or the dynamic domain manager that you specify during the installation process.

You can organize dynamic agents in pools to help organize your environment based on the availability of workstations and the requirements of the jobs to be run. Normally, when you create a pool, you add the dynamic agents to a workstation definition of type pool.

You can also register an agent with a pool by directly editing the pools.properties file located in <TWS_home>/ITA/cpa/config. See Automatically register agents to pools for more details.

You can optionally enable secure SSL communication for dynamic agents by downloading and deploying to dynamic agents the certificates already available on the master domain manager using the wauser and wapassword parameters when you run the twsinst installation script. Ensure the certificates are available on the master domain manager in the TWA_DATA_DIR/ssl/depot path.

An alternative method for enabling SSL communication, which applies to dynamic agents and fault-tolerant agents, involves using the sslkeysfolder and sslpassword parameters when you run the twsinst installation script.

You only need to provide the path to the certificates and the password you want to define for the keystore and truststore. HCL Workload Automation automatically generates the keystore and truststore with the specified password and configures WebSphere Application Server Liberty Base and your agents in SSL mode.

Enabling SSL during installation requires Java run time, which you can add at installation time using the addjruntime parameter, also available in the twsinst installation script. For more information, see Agent installation parameters - twsinst script.

At installation time, you can optionally create a subfolder on the master domain manager to contain one or more *.crt files to be added to the server truststore as trusted CA using the sslkeysfolder parameter. This can be used for example to add to the list of trusted CAs the certificate of the LDAP server or Db2 server. Additionally, you can store here any intermediate CA certificate to be added to the truststore. The subfolder must be named additionalCAs.