If the TREX system is connected to a Java application, the Java application communicates with both the name server and with the Web server. The Java application asks the name server via TCP/IP for the address of a Web server. It then sends the request to the Web server using HTTP/HTTPS. The Web server forwards the request TREX-internally. The graphic below depicts this communication:
There are multiple Web servers in a distributed TREX system. As soon as the Java application receives the address of one Web server, it communicates with that Web server for as long as it is available. If the Web server does not answer (for example, because it is overloaded), the Java application swaps to another Web server.
If the TREX system is connected to an ABAP application (that is, to an SAP system), both systems communicate though an RFC connection. The SAP system sends its requests to an Gateway. The Gateway sends the requests to a TREX RFC server. The TREX RFC server forwards the requests TREX-internally.
With regard to the SAP gateway, there are two variants:
Communication takes place using the local SAP gateway of the application server.
Communication takes place using a central Gateway.
In the case of a distributed TREX system, SAP strongly recommends using the local SAP gateways of the application servers. On the TREX side, TREX RFC servers are registered with each local Gateway. Each TREX host is connected to each application server of the SAP system.
The graphic below depicts this.
Using the local SAP gateways has the following benefits:
The local SAP gateways process the requests quicker than a central Gateway.
The Gateway is not a single point of failure. If an application server and its local Gateway fail, the requests are distributed among the remaining application servers and still continue to reach the TREX system.
If you use a central Gateway and the Gateway fails, the RFC connection fails too. It is not possible to switch to another central Gateway automatically.