TLS Gateway

As a system administrator, you use the TLS Gateway to facilitate the file transfer between TLS/SSL and non-TLS/SSL Agents. You can also configure it to provide a communication process (CP) port, if needed.

Note: The TLS Gateway is an Agent (HOST) object but it does not behave like any other Agent. The TLS Gateway only establishes the connection between TLS/SSL and non-TLS/SSL Agents, thus aiding the file transfer between them. It cannot be used to start the execution of tasks, nor for monitoring or reporting purposes.

Important! Check Broadcom Software Academy. There is a course available for this topic. For more information, see the Education section at the end of this page.

Overview

The communication between the Automation Engine, the Java components and the Proxy as well as between the Automation Engine and the TLS/SSL Agents (Java, Windows, UNIX Agents) uses TLS/SSL through a secure WebSocket (WSS). These components establish a connection with the Java communication process (JCP) and/or the REST process (REST).

Non-TLS/SSL Agents, such as BS2000, NSK, OS/400, VMS and z/OS require the TLS Gateway, which allows the file transfer between TLS/SSL and non-TLS/SSL Agents. The TLS Gateway can also be configured to provide a CP port in environments in which no CPs are available, thus allowing non-TLS/SSL Agents to connect to a CP.

When you upgrade the Automation Engine to this version, the system still has communication processes (CPS) running, so that your existing Agents can connect to the Automation Engine as they always do. Once all Agents have been upgraded to their new TLS/SSL version and you no longer have non-TLS/SSL Agents running, you can shut down and uninstall the communication processes (CPs) and the TLS Gateway instances.

However, if you need to continuously support non-TLS/SSL Agents in your system, you need the TLS Gateway. In this case, it is recommended to keep your communication processes (CPs) running.

Note: For high availability reasons, it is recommended to install at least two TLS Gateway instances on different computers.

More information:

• Types of Server Processes
• Securing Connections to the AE (TLS/SSL)
• Installing the TLS Gateway

TLS Gateway as an Agent

The TLS Gateway connects as an Agent to a Java communication process (JCP) in the Automation Engine system and it should run near the Agents it supports.

Just like with any Agent, you assign the TLS Gateway to the clients to which it should have access and define the relevant rights. It requires only the X -Execute right; all other rights have no effect on the component. The TLS Gateway is displayed along other Agents on the Agents page of the Administration perspective in Client 0 and in the clients to which it has been assigned.

Also, you have to authenticate the TLS Gateway according to the Agent authentication method that is defined in the UC_AS_SETTINGS variable.

More information:

• Agents (HOST)
• Assigning Clients to Agents
• Agent Authentication
• UC_AS_SETTINGS - Advanced Security

File Transfer

Once the TLS Gateway is running and assigned to the relevant clients, you can carry out File Transfers between TLS/SSL and non-TLS/SSL Agents without further configuration.

The Automation Engine knows the TLS Gateway instances in each client and selects one to execute the File Transfer. To select one, the system first looks for a TLS Gateway within the net area of the sender Agent. If there are more than one TLS Gateway active, the system picks one of them at random. If there are none active or if the ones available are not able to connect to both Agents (for example, due to a firewall configuration), the system searches for active ones within the net area of the receiving Agent. Here too, if there are more than one TLS Gateway active, the system picks one of them at random. The system tries to connect until max. 20 TLS Gateway instances have been tried out. For more information, see Net Areas in the Automation Engine.

However, you can overrule the random selection by manually assigning a TLS Gateway or a list of TLS Gateway instances to a particular non-TLS/SSL Agent. This option is useful if, for example, your Agents are distributed over long distances and you want to ensure that a TLS Gateway is used, that is co-located with the non-TLS/SSL Agent it has to serve.

To do so, use the UC_TLSGATEWAY_ASSIGNMENT variable. The variable is supplied with Client 0 but you can copy it to other clients, if you prefer to have a different assignment in a particular client. For more information, see UC_TLSGATEWAY_ASSIGNMENT - Assigning TLS Gateway to non-TLS/SSL Agents.

TLS Gateway as a CP Port

In environments in which no communication processes (CPs) run, you can configure the TLS Gateway to provide a CP port for non-TLS/SSL Agents.

For security reasons, this functionality is deactivated by default and must be explicitly enabled. To do so, set the TLS_GATEWAY_CP key of the UC_SYSTEM_SETTINGS variable to Yes.

You also have to define the cp= parameter in the [TCP/IP] section of INI file of the respective non-TLS/SSL Agent and make sure it points to the port that is defined in the cp_port= parameter in the [TCP/IP] section of the INI file of the TLS Gateway.

Optionally, if you are using net areas, you can define them using the NetArea= parameter in the [TCP/IP] section of the INI file of the TLS Gateway.

The TLS Gateway that is being used is listed in the TLS Gateway column on the Agents page of the Administration perspective. The Net Area column shows the name of the net area to which a TLS Gateway acting as a communication process (CP) is assigned. These columns are not displayed by default but you can add it to your view.

Note: The Net Area field is populated only for TLS Gateway instances that are used as a communication process (CP) and are assigned to a net area. It does not apply to the Agents nor to TLS Gateway instances acting as an Agent as only communication processes (CPs and JCPs) can be grouped in net areas.

More information:

• TLS_GATEWAY_CP variable
• Agents (HOST)
• TLS Gateway INI file
• Agent BS2000 INI file
• Agent BS2000 Event Monitor INI file
• Agent NSK INI file
• Agent OS/400 INI file
• Agent VMS INI file
• Agent z/OS INI file
• Net Areas in the Automation Engine

Renaming/Deleting a TLS Gateway

You can rename and/or delete a TLS Gateway from the Agents list in any Client that you have access to, given the following applies:

• You have write (W) permissions on the TLS Gateway
• The TLS Gateway is inactive
• The TLS Gateway is not used in multiple Clients

Note: If you try to rename or delete a TLS Gateway that is used in multiple Clients, an error message is displayed.

To rename and/or delete a TLS Gateway, right-click it and select Rename/Delete.

Using Scripts

You can use scripts to easily create, download and extract TLS Gateway packs, as well as start them.

We have gathered a number of deployment script examples for the TLS Gateway. They allow you to deploy and start the TLS Gateway without having to create your own script. You can also merge separate scripts used in the examples into one large script.

More information:

• Script Examples - Windows
• Script Examples - UNIX

Education

The Broadcom Software Academy provides a wide range of free online trainings. For information about how to navigate through the Academy and on how to register for courses, see Free Online Courses.

The following course(s) are associated with this topic:

Automic Automation TLS Gateway