Reverse Invoke
Reverse invoke is the technology that enables network connections to be set up from a secure network (Intranet). This increases network security since no external connection can get through the firewall into the network. If you want to set up a connection between a host in the demilitarized zone (DMZ) and a host in the Intranet (behind the firewall), the host in the DMZ is not allowed to open the connection - it must be opened by the host in the Intranet.
When a Web application is running in an SAP system the connection looks like:
When the browser starts a Web application in an SAP system, it connects to the SAP Web Dispatcher, which is located in the DMZ. The Web Dispatcher is used as the point of access into the SAP system. It distributes the workload and forwards requests to an appropriate server in the SAP system. The connection is set up however by the Internet Communication Manager (ICM) in the application server, and not by the Web dispatcher. The firewalls can be configured as follows:
The firewall at the front allows inbound connections to the HTTP(S) port of the SAP Web dispatcher.
The firewall behind the DMZ does not allow any external connections through.
The connection between the SAP Web dispatcher and the ICM (application server) is called the reverse invoke connection.
Reverse Invoke Connections: Client and Server
With a reverse invoke connection the program that sets up the connection (here the ICM) acts as the server, and the program in the DMZ (here the SAP Web Dispatcher) acts as the client. Although the ICM sets up the connection and as such acts as the client from the viewpoint of the TCP/IP, from a logical viewpoint the ICM is the server.
Since the connection is set up from the server, it is not sufficient that the client knows the address and port of the server. The server must also know the address and port of the client so that it can register as the server on the client.
If, as shown in the graphic, the SAP Web dispatcher is the client, and the ICM in the Intranet is the server, the client has opened an external port (external entry point). An inward port is opened ( registration port) on which servers can register. The server (here the ICM) must know this port (and the address) to set up the connection. The server can register through this connection - it notifies the client of the address/port combination through which it receives connections ( pseudo port). 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. The connection request logically goes from the client to the server.
The reverse invoke connection is set up in the following steps:
The client opens a port ( registration port), which is known to the server.
The server connects to the registration port and registers its own service ( pseudo port). The connection remains open.
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.
Implementation
The reverse invoke function is implemented in the SAP NetWeaver Application Server in the network layer ( NI Network Interface), which allows it to be used by all SAP programs based on NI.
Reverse invoke is implemented in such a way that there is a separate connection for each connection set up to the server. The client keeps a control connection and a number of data connections for each server. The number depends on the number of connection requests. The logical data connections to the server are not bundled through one connection (no multiplexing).
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. You can also deactivate the pool. Then the connections are opened only on demand.
To regulate the number of servers that can register on the client, the client can be provided with an access control list (ACL). This ACL consists of IP addresses and masks that can be accepted and rejected.
The connections can be based on either IPv4 or IPv6, UDS connections (Unix Domain Sockets) are not supported.