HCL Workload Automation, Version 9.4

The engine connection does not work

You define an engine connection, you verify that the values entered for the engine connection are correct, and then you click Test Connection. The test fails and a connection error message is returned.

Cause and solution:

Assuming that system_A is where you installed the Dynamic Workload Console, and system_B is where you installed HCL Workload Automation, follow these verification steps to investigate and fix the problem:
  1. Verify that there is no firewall between the two systems as follows:
    1. Make sure the two systems can ping each other. If you are trying to connect to a z/OS® engine you must check that the system where the Dynamic Workload Console is installed and the system where the HCL Workload Automation z/OS connector is installed can ping each other.
    2. Make sure you can telnet from system_A to system_B using the port number specified in the engine connection settings (for example, 31117 is the default port number for distributed engine).
    3. Make sure you can telnet from system_A to system_B using the CSIv2 authentication port numbers specified during installation (for example, 31120 is the default server port number and 31121 is the default client port number).
    If either of these two steps fails then there might be a firewall preventing the two systems from communicating.
  2. Check if you can connect using the composer command line interface, or the Dynamic Workload Console to the HCL Workload Automation engine on system_B using the same credentials specified in the engine connection. If you cannot, then check if the user definition on system_B and the user authorization specified in the HCL Workload Automation security file are correct.
  3. If you are using LDAP or another User Registry on the Dynamic Workload Console make sure that:
    1. The connection to the user registry works.
    2. The User Registry settings specified on the Integrated Solutions Console in the Security menu under Secure administration, applications, and infrastructure are correct.
    3. You restarted the affected WebSphere Application Server of both the Dynamic Workload Console and HCL Workload Automation, after configuring the User Registry
    4. You ran the updateWas and (on Windows) updateWasService scripts after restarting WebSphere Application Server
    For more information about how to configure the Dynamic Workload Console to use LDAP or about how to test the connection to a User Registry, refer to the chapter on configuring user security in the HCL Workload Automation: Administration Guide.
  4. If you set up to use Single Sign-On between the Dynamic Workload Console and the HCL Workload Automation engine, make sure you correctly shared the LTPA_keys as described in the chapter on configuring SSL in the HCL Workload Automation: Administration Guide.
    Note: Make sure that you correctly shared the LTPA_keys also if you get errors AWSUI0766E and AWSUI0833E. The problem occurs when the realm values are the same for more than one WebSphere Application Server (Dynamic Workload Console, HCL Workload Automation z/OS connector, or HCL Workload Automation engine). These steps are usually described only when you configure the Single Sign On, but they are required also when you have the same realm. You have the same realm when you configure all WebSphere® Application Servers with the same LDAP user registry and when you install all WebSphere Application Servers on the same machine.
If this checklist does not help you in identifying and fixing your problem then activate tracing on the Dynamic Workload Console by running the steps listed in Activating and deactivating traces in Dynamic Workload Console (adding also the Java™ packages com.ibm.ws.security.*=all:com.ibm.tws.*=all), and on the HCL Workload Automation engine by running the following steps:
  1. Connect as ROOT to the system where the HCL Workload Automation engine is located.
  2. Edit the file TWA_home/wastools/TracingProps.properties, add the statement: 
    tws_with_sec=com.ibm.ws.security.*=all:com.ibm.tws.*=all
    and then save your changes.
  3. Run the following script to start tracing: 
    <TWA_home>/wastools/changeTraceProperties.sh 
<[-user TWS_user> -password <TWS_user_password>] -mode tws_with_sec
    where
    [-user <TWS_user> -password <TWS_user_password>]
    The user and password are optional. By default, the script looks for the credentials in the soap.client.props file located in the properties directory of the WebSphere Application Server profile.
Connect to the Dynamic Workload Console again, test the connection to the HCL Workload Automation engine, and then check the information stored in the following trace logs:
  • On the Dynamic Workload Console: 
    <JazzSM_profile_dir>/logs/server1/trace.log
    where <JazzSM_profile_dir> is
    On Windows operating systems
    C:\Program Files\IBM\JazzSM\profile
    On UNIX operating systems
    /opt/IBM/JazzSM/profile
    On the HCL Workload Automation engine: 
    <WAS_profile_path>/logs/server1/trace.log
    where the default path for <WAS_profile_path> is <TWA_home>/WAS/TWSprofile
In these files you see the information about the error that occurred. If useful, compare the connection information stored in the traces with the information set for WebSphere Application Server security on both sides. Refer to the IBM® Workload Scheduler: Administration Guide to list the information about the security properties.