The R/3 System supports the following communication connections:

• Presentation frontend (SAPgui) to the R/3 System
• Connections from the R/3 System to printers
• Connections to other R/3 Systems
• Connections to external applications

The following communication connections exist within an R/3 System:

• From the application server to the database
• From the application server to the message server
• Communication between application servers

The following graphic shows you all the different ways an R/3 System can communicate. The graphic includes TCP connections only. The R/3 System can consist of one or more different hosts. The communication connections within the R/3 System are described later.

The arrows show in which direction the TCP connections are set up.

The following describes these connections in detail.

The R/3 System uses spool work processes to process print requests. There can be one or more spool work processes, which themselves can run on one or more application servers. The way in which the spool work processes print depends on your configuration. The system can print in one of the following ways:

• Output to local operating system spooler, on the application server host (no network connection)
• Output to the standard "line printer service" (lp) of the target host (TCP service printer with the TCP port number 515)
• Output to the SAP printer daemon (SAPlpd) that is running on the target host (TCP port number 515)
• Print output using the dialog connection of the SAPgui frontend. The existing SAPgui connection is used, which means that no specific port is needed.

Each R/3 application server has an SAP gateway that it uses to communicate with other SAP Systems, or with other applications that use the SAP communication interfaces for CPI-C or RFC.

CPI-C (Common Programming Interface for Communications) is a standardized protocol for the simple transmission of data between two programs. CPI-C uses half duplex transmission. This means that only one party at a time can transmit data. The receiving party must keep receiving data until it is its turn to transmit.

RFC (Remote Function Call) is SAP's own communications interface. RFC communication always involves a caller (RFC client) and a receiver (RFC server). The RFC server provides one or more function modules that can be called. An RFC client can call one of these function modules, transmit data, and then read the results of the function module. Both the server and the client can be either external programs or the SAP System.

The SAProuter program helps you to set up and control remote connections easily. SAProuter functions as an intermediary between the source system and the target system. First, the source system sets up a TCP connection to SAProuter and tells it to which target system it wants to connect. SAProuter then sets up a connection to the target system. A SAProuter connection from a source system to a target system consists of multiple TCP connections.

If necessary, a connection can be made using multiple SAProuters in sequence. If this is the case, all SAP connections between the SAProuters are relayed through defined TCP ports between defined partners (SAProuters). This makes it much easier to implement mechanisms that protect access to the connections.

Separate organizational units that administrate their networks and security separately can also take advantage of double SAProuters. Each unit defines its own SAProuter as a communication port for all SAP communication that goes outside its limits. SAProuter then becomes an application level gateway that can run, for example, on a firewall host. You can use authorization tables to control who may set up a connection with whom.

Each organizational unit can allow or disallow connections as it wants.

When you start the program, you can determine under which port you want to access the SAProuter.

The following section describes these connections in detail:

The connection between the R/3 application servers and the database server is based on a Remote SQL database interface.

The TCP port you use depends on the individual database system:

The various instances (application servers) use the message server to access central services, such as the enqueue or update services. The message server also receives regular information from all instances about current system load and the services that are on offer. This means that the message server can provide information on load balancing for different applications, such as the SAPgui or background applications.