The communication protocol used between the SAPgui and the R/3 application servers is block-oriented. This means that the entries made by the user are not sent to the application server immediately. The user enters and edits the data locally on the terminal until it is released. Only then is a request with a data packet sent over the network to the application server. The server processes this request and then sends the response back to the SAPgui. This action is known as a dialog step.

As well as the dialog steps, other communication also takes place, for example:

• You issue a request when you open SAPgui menus, since only then are the menus fetched from the application server.
• The application server controls the progress display in the SAPgui status bar. You can deactivate it if the connection is poor.
• Keep-alive data packets are exchanged if the SAPgui is inactive for long periods of time. These packets only consist of a few bytes.
• Frontend printing through the SAPgui can place a heavy load on the network (see Network Load Due to Printing).

A communication basically consists of a request initiated by the frontend, to which the application server reacts with a response. Keep-alive data packets are an exception, since the application server sends them to the SAPgui without being requested to.

The communication between the SAPgui and the R/3 System has been optimized to keep the load on the network as low as possible. Only the contents of those elements that actually appear on the screen are transmitted. The graphics are formatted on the frontend. In addition, the data is compressed.

It is difficult to make a general statement on how much load the SAP frontend places on a network. The load depends on the SAP transactions used, the speed of the user, and to a lesser extent, on the application data.

SAP uses SAP standard benchmark measurements for the applications FI, MM and SD to determine the amount of data in each dialog step. These benchmarks simulate typical actions in these applications. The network load does not differ greatly between the applications and stands between 0.5 KB and 3 KB for each dialog step. For R/3 Release 4.0 an average of 1.7 KB is transmitted across the network for each dialog step. Other applications may return different values, however, experience has shown that the standard benchmark value is a good approximation of actual requirements. For more exact planning, however, it is advisable to carry out detailed tests with the actual user profiles.

We cannot make a statement on the network load caused by downloading large tables (for example, for external table calculations), since the data involved depends entirely on the application data.

Transactions that use the new SAP control technology can differ greatly from traditional transactions in the amount of network load they cause. The amount of data that has to be transmitted depends more strongly than before on the data being processed by the user. This can, for example, be due to the fact that an editor control always has to transmit the entire text to the frontend for processing. This means that the amount of data that has to be transmitted depends on the size of the text. On the other hand, however, the user can now edit the text on the frontend and data is not continually being exchanged with the application server. This leads to fewer dialog steps in an application, and more data in each dialog step. When you attempt to estimate the network load produced by transactions that use controls, you must use actual user profiles for your analysis. Only in this way can you be sure that your planning data is reliable.

Regardless of the type of transaction, the raw data from the SAP database tables is always processed on the application server. A consequence of this is that there is about 10-20 times more data flowing between the application server and the database than between the application server and the frontend. The following graphic depicts typical data traffic between the frontend application server and the database:

You can use the following formula to estimate the network bandwidth needed between the application server and the frontend for N users. It takes into account the average amount of data traffic in each dialog step, the number of users, the time a user takes to process a screen ("thinking time") and the response time of the system. This formula has been tried and tested in practice, however it is still only a first estimate of the actual bandwidth requirements.

The parameters of the formula are:

The required network bandwidth is estimated as follows:

Note the following:

• Experience has shown that working at the theoretical maximum capacity of a connection can lead to a strongly peaked distribution of network delay times. This is because the work steps of the users are not distributed evenly over time. The fewer users working in parallel, the more frequent are these peaks.
• There is no safety reserve built into the formula. We recommend that make your bandwidth at least double the result of the formula.
• A bandwidth of 9600 bit/sec is the minimum acceptable bandwidth when working with one user.
• This formula only applies to SAP dialog transactions (without controls) up to and including R/3 Release 4.5.
• The most imprecise part of the formula is the thinking time assumed for the user. The most reliable way of estimating this is to observe the way users work productively over an extended period of time.
• The formula only gives the requirements for SAPgui data traffic. You must also take load caused by other applications (printing, web browser, access to file server and so on) into account when you estimate your required bandwidth.