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's Enterprise Software Academy. There is a course available for this topic. For more information, see the Education section at the end of this topic.

This page includes the following:

Overview

As of this version, 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:

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:

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 randomly selects one to execute the File Transfer. If the TLS Gateway selected is not able to connect both Agents (for example, due to a firewall configuration), another active TLS Gateway is selected automatically until max. 20 TLS Gateway instances have been tried out.

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 can be grouped in net areas.

More information:

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:

Education

The Enterprise Software Academy provides a wide range of free online trainings. If you have not already done so, register at Enterprise Software Academy to start profiting from our education offer.

You can find the list of courses available for Automic products here: Automic Course Catalog.

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

TLS Gateway