SAP Frontend Communication (SAP Library - Network Integration Guide (BC-NET))

SAP Frontend Communication

The SAPgui is the user interface of the SAP System and is the presentation level in the 3-tiered client-server architecture of the SAP System. It displays the user interface and the interaction of the users with the system. The SAPgui is a graphical, window-based program that you control using a keyboard and mouse. It runs on a PC that is linked by a network to the SAP server computers.

The following sections explain the attributes and requirements of network communication for the SAPgui. The network load arising from the SAPgui is described under Frontend Network Load.

SAP offers the SAPgui on various platforms: Microsoft Windows, OS/2, Unix and Macintosh. All this variants have the same network requirements. In addition to the SAPgui, there is a SAP frontend written in Java and a version that lets you operate the SAP System using a Web browser. These frontend types have other network attributes and are not described here. For more information on Web applications, see Internet Transaction Server Technology.

Accessing the online documentation is naturally a part of working with the SAP Frontend, but is separately implemented on a technical level. For more information, see SAP Online Documentation.

Network Protocol

The TCP/IP protocol is used exclusively to communicate between the SAP System and the SAPgui. The following graphic displays the relation between the frontend as the client and the SAP System as the server:

Additional proprietary protocols (for example, IPX, NetBEUI) are often used in PC networks. The frontend computer is often equipped with two protocols, which use the same network adapter on the PC. Two protocols coexisting on one computer do not hinder the operation of the SAPgui. However, you must make sure that there are no conflicts between the different software components. The following graphic displays using 2 different protocols on one frontend computer.

The TCP/IP protocol has established itself as the standard network protocol. Therefore, it is already integrated in all modern operating systems. The operating systems supported by SAPgui with a specific R/3 Release and TCP/IP stacks, which are the concrete implementation of the protocol on a computer platform, are listed in the brochure SAP System Requirements. You can find this in SAPNet under http://sapnet.sap-ag.de/SSR . The hardware used (for example, token ring- or Ethernet-adapter) is determined not by SAP software, rather the operating system and the TCP/IP stack.

Attributes of SAPgui Communication

TCP Ports

For more information in the TCP ports used by SAPgui, see Communication Connections of the R/3 System. The following table is a quick overview of the most important ports that are used when working with a SAPgui:

Connection	Symbolic port name	Example: <nn> = 01
SAPgui – application server (dispatcher)	sapdp<nn>¹⁾	3201
SAPgui – message server (load distribution)	sapms<SID>²⁾	3600 ³⁾
RFC program – application server (gateway)	sapgw<nn>	3301
As required – SAProuter	sapdp99⁴⁾	3299 ⁴⁾

nn is the instance number of the SAP Application server.

SID is the 3-character system ID of the SAP System (for example, PRD).

Can be chosen at random, but must be defined in /etc/services . Another port is often chosen for each SAP System, but this is not necessary.

The default is 3299, but you have a free choice.

You can use the SAProuter to route all communication between the frontend and the SAP System through a port to a computer. for more information on the SAProuter, see the SAP Library under BC - SAProuter.

Establishing a Connection

All connections are established from the frontend, and never from the SAP Server.

If you use the message server for load-balancing, the SAPgui (or the SAPlogon for R/3 Releases before 4.0) first makes a TCP connection to the Message server at logon to determine the most suitable application server. The connection can occur with one or several SAProuters; in this case, the TCP connection is only made to the SAProuter, which in turn connects to the next communication partner. The connection to the message server is subject to a timeout that by default takes 10 seconds. You can configure the timeout in the SAPlogon options directly and in the SAPgui using the environment variable TDW_TIMEOUT .

At logon, the SAPgui establishes a TCP connection to the dispatcher on the application server, that can also connect over the SAProuter, just like the connection to the message server. There is also a timeout with this connection with a default of 10 seconds. If this time is exceeded, the SAPgui reports an error and terminates the connection. You can configure the timeout using the environment variable TDW_TIMEOUT .

All modes that are opened during a session use the same TCP connection. To do this, the data flow of the various modes is sent through a multiplexer to the SAP System.

Desktop components such as F1 help or Screen Painter communicate with the SAP System using RFC. To do this, they connect to the SAP gateway on the same application server with which the SAPgui is also connected.

Duration of the Connection

The SAPgui uses a TCP connection for the entire time that the user is logged on to the SAP System. Therefore, it is not necessary for each dialog step to establish a new connection. The SAP System is also informed if the user ends the session with SAPgui without logging off from the system. In this case, the user is automatically logged off from the system.

If the connection between the SAPgui and the application server is interrupted for a long period of time, the operating system (more specifically, the TCP/IP stack) terminates the connection and signals this to both programs that are using the connection. In this case, the SAPgui reports an error and closes itself. The dispatcher makes an entry in the system log and ends the user session, which results in all the resources that were used by the session, are released after a short waiting period. During this wait time the user can log on again use the previous context of the session.

The SAPgui therefore requires a stable network connection during the entire duration of the user session.

Keep-Alive

If the user's SAPgui session ends, the SAP System must be informed as quickly as possible to release the resources that were used by this session. It is important that data records are released that are being processed by the session and are therefore locked.

When the TCP connection is ended, the system is automatically informed if the SAPgui process is terminated on the frontend. However, the operating system continues to run. The situation is different if the frontend computer is turned off, or fails, or the network connection is broken. Since the SAP System normally waits for queries from the SAPgui and does not send data by itself to the frontend, it is not informed about this situation, because no error has occurred. The user session would remain in the system until the auto-logout is triggered (profile parameter rdisp/gui_auto_logout ) or it is manually deleted.

To avoid this situation, the application server sends a network packet to the SAPgui, if it has not sent any data for a specific period of time. The application server expects an answer from the SAPgui within 40 seconds, otherwise the user session ends. This procedure is repeated periodically.

The wait time is 1200 seconds by default and you can configure this time using the profile parameter rdisp/keepalive . A value of 0 deactivates the mechanism, which we only recommend in conjunction with a relatively short auto-logout time.

Network Address Translation

Network Address Translation (NAT) modifies the IP addresses and if necessary the TCP port numbers in the network packets. This occurs transparently for the entire network protocol stack. NAT reduces official IP addresses when many computers communicate over the Internet, and it connects communication partners that cannot otherwise be reached directly due to address conflicts.

When using Network Address Translation with the SAP System, there are several limitations which are arise from network addresses being transferred within the transaction data. There are two possibilities:

The addresses from SAP server computers to the SAPgui may not be modified.
The addresses from SAP frontend computers to the SAP server may be modified.

If you use the SAP message server for load-balancing, it sends the IP addresses and TCP services of the available SAP server back to the GUI. These IP addresses are then used to connect to the most suitable server. This procedure makes it necessary for the frontend computers to be able to reach the application server under the IP address that they have in their local network. (For the rules on assigning these IP addresses, see Configuring SAP Servers with Multiple Network Cards.) This is why the addresses of the SAP server may not be translated on the transmission path.

In certain cases, due to the network topology, the frontend computer may not be able to establish a direct TCP/IP connection to the SAP server without Network Address Translation. In this case, you can use a SAProuter to establish the connection. For more information see Communication Using SAProuter and in the SAP Library under BC - SAProuter.

Network Address Translation is mostly used, however, in the other communication direction, which means for the network address of the frontend computers. This does not cause any problems for SAP communication, if there are no server services running on the frontend computer that require a connection from the server to the frontend. For example, you can start RFC server programs from SAPgui, as it used for many desktop components. Frontend- printing is also possible, but you cannot use the computer as the print server in the SAP printer administration.

Dynamic Host Configuration Protocol

The Dynamic Host Configuration Protocol (DHCP) automatically configures the network configuration of computers that are linked to a network. This is used primarily for administrating workstation computers in local networks and for dial-in connections. Using DHCP can lead to the same computer is assigned a different IP address after each restart or after each logon to the network.

You can generally operate SAP frontends with DHCP and changing IP addresses if there are no server services running (in the same way as mentioned in the previous section). Buffering name and address resolution in the SAP server (see Name and Address Resolution for R/3 Servers) has consequences when operating frontend computers with DHCP:

The SAP System resolves IP addresses into names when you log on. This name resolution is buffered in the SAP Server. If another frontend logs on with the same IP address, the old name (now incorrect) is still stored in the system. Therefore, the incorrect name is entered in some log files. However, in the User Overview (Transaction SM04) the correct name is displayed, which is sent to the application server when logging on from the SAPgui.

For the SAP printing administration, it is not useful to specify a computer with a changing IP address as the print server. This also applies if your name resolution is able to map the host name correctly to the changing IP addresses (for example, with dynamic DNS). The reason is that the name resolution by the SAP server is performed only once and then buffered. New accesses to the same host names do not result in new name resolution, so that the print request is not sent to the correct computer. Buffering in the SAP System cannot be deactivated.