Connecting to a Communication Process

As of this version, the communication between the Automation Engine and the Java components as well as the Windows, UNIX and Java Agents and the TLS Gateway uses TLS/SSL through a secure WebSocket (WSS). These components establish a connection with the Java communication process (JCP), which uses trusted certificates to prove its identity to other communication partners.

All other Agents and components that do not support TLS/SSL establish a connection with a communication process (CP). A connection to the database of the AE is not required for this purpose because data exchanged between clients and the Automation Engine is exclusively exchanged through CPs.

This page includes the following:

Overview

Communication processes (CPs) are single-threaded and can process requests sequentially. Multiple communication processes (CPs) are required to balance the workload created by Agent and/or CallAPI connections. Depending on the number of clients (non-TLS/SSL Agents, CallAPIs), it is recommended using a corresponding number of CPs per node. For more information, see Automic Automation System Requirements and Sizing.

Non-TLS/SSL Agents and CallAPIs connect randomly to a communication process (CP) listed in the CP_LIST section of the respective INI file and may reconnect to another communication process (CP) depending on the workload and ranking of the CPs. See also CP_ENDPOINT.

Java communication processes (JCPs) are multi-threaded and can process multiple requests in parallel. Therefore, it is not necessary to evenly balance the number of connections because the performance is not increased significantly. It is recommended using one Java communication process (JCP) per node.

You can also set up a system with multiple REST processes, which can be convenient for load balancing capabilities. However, it is recommended using a third party load balancer for this purpose.

TLS Agents and components connect randomly to a Java communication process (JCP) listed in the JCP_LIST section of the respective INI file and do not reconnect to another JCP. They keep the connection to that JCP until the next connection build-up. See also JCP_ENDPOINT.

The number of Agents, the number of connections per communication process, and the number of concurrent users logged in do have an upper limit. For the current upper limit of each, refer to the log files of the primary work process (PWP) and the communication processes (CP or JCP).

Selecting a Communication Process (CP)

Connections are established in several steps.

  1. If the CP_LIST section of the Agent's INI file is empty, the Agent connects to the communication process (CP) specified in the cp= parameter of the [TCP/IP] section of the Agent's INI file.

    If the CP_LIST section of the Agent's INI file has a list of CPs available, the Agent randomly connects to one of the CPs listed. The Agent then identifies the CP with the lowest number of connections within the CP_LIST, shortly breaks the connection to the randomly selected CP and connects to the CP with the best connection count.

    One communication process can handle 99999 connections on all platforms. The exceptions is zLinux where the limit is 65000.

  2. Upon establishing a connection, the CP provides the client (Agent, CallAPI) the performance values for the connection and information about all addresses of CPs known in the system.

  3. The addresses are used to update the corresponding sections of the INI file entries.

Selecting a Java Communication Process (JCP)

Connections are established in several steps.

  1. If the JCPLIST section of the Agent's INI file is empty, the Agent connects to the Java communication process (JCP) specified in the connection= parameter of the [TCP/IP] section of the Agent's INI file.

  2. Upon establishing the connection, the JCP sends the Agent information and the JCPLIST section of the Agent's INI file is populated automatically.

  3. If the connection between the Agent and the JCP is broken or if the Agent is restarted and the JCPLIST section of the Agent's INI file has a list of JCPs available, then the Agent randomly connects to one of the JCPs listed.

    Since JCPs are multi-threaded and can process multiple requests in parallel, the Agent does not need to consider the number of connections.

You can also set up a system with multiple JCPs, which can be convenient for load balancing capabilities. However, it is recommended using a third party load balancer for this purpose.

See also: