Show TOC

Fundamentals of the RFC Connection Between TREX and SAP SystemsLocate this document in the navigation structure

Use

When a TREX system is connected to an SAP system, both systems communicate with each other through an RFC connection.

More than one communication partner is involved in an RFC connection. The SAP system first sends its requests to an Gateway. The Gateway forwards the requests to a TREX RFC server. The TREX RFC server forwards the requests TREX-internally. The graphic below depicts this.

There are different types of RFC connections. To connect a TREX system, the system supports the activation type 'Registration'. With this activation type, one or more TREX RFC servers register with the Gateway and maintain a constant connection to it.

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.

Local SAP Gateways for the Application Servers

With this variant, each application server sends the requests to its local Gateway. On the TREX side, TREX RFC servers are registered with each local Gateway. The TREX configuration depends on the structure of the SAP system. In addition, you must distinguish between TREX RFC servers in single-thread mode and those in multithread mode during configuration:

TREX RFC Servers in Single-Thread Mode

In the case of TREX RFC servers in single-thread mode, there are at least as many RFC servers (instances/processes) running on each TREX host as there are application servers. Each RFC server instance connects itself through an Gateway that runs locally on each application server. The graphic below depicts this.

TREX RFC Servers in Multithread Mode

In the case of TREX RFC servers in multithread mode, exactly one RFC server (instance/process) runs on each TREX host and within this one RFC server, at least as many threads are started as there are application servers. The graphic below depicts this.

Note

The multithread mode is recommended for the TREX RFC server. A single RFC server instance that starts more than one thread in multithread mode consumes less memory than many RFC server instances in single-thread mode. (For details of the configuration, see Changing the Number of RFC Server Instances or Threads). In the case of an initial TREX installation, the TREX RFC server is configured for multithread mode by default so you do not have to make any changes.

The TREX configuration depends on the structure of the SAP system. Each TREX host runs at least as many TREX RFC servers as there are application servers. If application servers are added to or removed from the SAP system, you must change the TREX configuration.

In the case of a distributed TREX system, each TREX host is connected to each application server in 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.

Central Gateway

With this variant, communication takes place through a single Gateway. The Gateway can run on any machine. The SAP system sends all requests to the central Gateway. On the TREX side, one TREX RFC server is registered with this Gateway in the default configuration. The graphic below depicts this.

The TREX configuration does not depend on the structure of the SAP system. If application servers are added to or removed from the SAP system, there is no impact on the TREX configuration.

The disadvantage of this variant is that the central Gateway is a "single point of failure." If it goes down, the connection between the SAP system and the TREX system is unavailable.