Reverse InvokeLocate this document in the navigation structure

Reverse invoke enables a secure connection from an application server in the protected network to a server within the demilitarized zone (DMZ). Since external requests are only forwarded to a server in the protected network if this server has already opened a connection to the server in the DMZ, the network is made more secure. This connection is called a reverse invoke connection. External connections or connections from the DMZ to a host within the protected network cannot therefore be opened directly when reverse invoke is used. An existing reverse invoke connection is used by the server in the DMZ to forward requests that are directed to and permitted by this server.

The reverse invoke function is implemented in the SAP NetWeaver Application Server in the NI network layer, which allows it to be used by all SAP programs based on NI.

Figure 1: Reverse Invoke in the SAP System

The figure below shows external requests to the SAP system. The SAP Web Dispatcher is in the demilitarized zone (DMZ) and is the central access point into the SAP system. It distributes the workload and forwards requests to an appropriate server in the SAP system. When reverse invoke is used, the connection is set up however by the Internet Communication Manager (ICM) of an application server in the protected network, and not by the SAP Web Dispatcher.

With a reverse invoke connection the program that sets up the connection acts as the server, and the program in the DMZ acts as the client.

Figure 2: Client and Server

Opening a Reverse Invoke Connection:

  1. The client opens a registration (reg.) port.
  2. The server connects to the registration port and registers its own pseudo port.
  3. To set up a connection from the client to the pseudo port of the server, the client does not open a new connection, but uses the existing reverse invoke connection.

The figure shows an SAP Web Dispatcher that has opened an external port. Another port is opened to the protected network that the servers can register on. This port is called the reg. port. The server must know the address and port of the client so that it can register as the server there. When the server registers it tells the client its pseudo port, that is, the address and port combination through which it receives connections. The server does not physically accept connection requests on this port, but the client can process connection requests from a browser to this server/port through the existing connection.

A separate connection is opened for each connection to the server. The client keeps a control connection and a number of data connections for each server, which depends on the number of connection requests. Consequently, no multiplexing takes place. To set up connections faster, they are set up during registration and kept in a pool. The number of connections in the pool can be configured and they should be configured per unit of time independently of the number of connection requests. Pooling can also be deactivated, then the connections are only opened on demand.

In the client you can specify an access control list (ALC), which regulates which servers are allowed to register. This ACL consists of IP addresses and masks that can be accepted and rejected. The connections can be based on IPv4 and IPv6. UDS (Unix Domain Sockets) connections are not supported.