The Influence of the Network on Cost

In addition to performance, the network infrastructure also influences the costs of an SAP system. This applies to both the up-front investments in the SAP infrastructure, as well as to the daily operating costs of such a system landscape. The network's transmission capacity as well as the infrastructure must be provided within an SAP implementation project. In most cases, even existing network infrastructures have to be upgraded and additional workplace connections have to be installed. This usually requires an investment in additional passive and active components (cables, switches, routers, etc.) to enhance local network infrastructures. Compared with these investments, the daily operation costs, management, and maintenance are low, but still relevant.

A totally different situation appears for network connections crossing the borders of the company's property. Such connections typically have to be rented from telecommunication providers. In spite of the competition on the liberated telecommunications market, bandwidth over long distances is still a rare and, therefore, expensive resource (especially true when you have to cross national boundaries). The accumulation of costs for providing transmission capacity and leased lines can exceed the investments of the complete SAP hardware in the long run. Therefore, it is highly recommended to do a best guess estimate of the bandwidth demand at the very beginning of an SAP project to negotiate the telecommunications prices without time pressure.

Lastly, the costs due to insufficient network performance also have to be taken into account. The loss of working hours due to long response times is a cost factor. When an enterprise network is not properly designed, or is regularly congested, increasing the performance of the SAP servers can sometimes (but not always) reduce the overall response time. However, the additional server hardware necessary can significantly raise the investment costs in the hardware infrastructure. As previously shown, the processing capacity has to be increased significantly in order to reduce the SAP system response time by just one second. If more powerful servers don't help alleviate the response time problem, then productivity losses can occur, which are harder to measure. Therefore, providing a performing network infrastructure is an essential part of an SAP implementation project.

The formulas given in most publications for the bandwidth demand within an SAP network infrastructure take only the transaction data transmission between the user workstation, the application server, and the database server into account. However, many more data streams are generated within any SAP system in addition to the regular online dialog activity.

Transmission of image files of optical archiving systems, as well as graphics, like the CAD drawings displayed within the product data management (PDM) system, generate a high network load. In addition to this, several R/3 modules provide specific interfaces to external systems generating a high, as well as time-critical network load. The logistic module, for example, provides interfaces to mobile data acquisition devices (barcode scanners), forklift-truck management systems, LVRs, and warehouse management systems. Another example is the interface for Point-of-Sales (POS) systems within the SAP solution for the retail industry. The supply chain of a retail solution represents an excellent example of a time-critical data transfer. As described in Chapter 1, the data from the POS systems from multiple retail shops has to be transferred to headquarters within a relatively short timeframe. During the night, the SAP system calculates the replenishment planning requirements for refilling the in-store shelves. This data has to be transferred in a timely fashion to the warehouse management system within the distribution centers, allowing the early morning delivery trucks to depart on schedule.

The required network bandwidth is determined, obviously, by the amount of data sent over the network for each unit of time. Network workload is never constant—it increases due to user population changes and the improvements in functionality with every new SAP release. The bandwidth for all the data traffic mentioned earlier depends on too many parameters to make general sizing rules applicable to all situations. There is no single formula to guarantee the perfect setup of an SAP network infrastructure. However, the following network-focused chapters do provide some useful guidelines and estimates for data traffic inside and outside of SAP systems.

For the operation of an SAP network infrastructure, it is highly recommended to monitor it regularly. Using sophisticated network monitoring and management tools, bottlenecks can be detected and removed before problems occur.

Bandwidth Demand for SAP Server Communication

In the three-tiered SAP system architecture, the business logic is executed on the application servers. The system must transmit from the database server not only the data that is displayed but also data needed for calculations. Consequently, the amount of data moved between the SAP application servers and the database server is at least one order of magnitude greater than between the application server and the front-end PCs (see Figure 7-2). The average data transmitted between the application server and database server is approximately 20–40 kilobits in each typical online dialog step. This amount can vary greatly depending on which transaction is executed, how much data is in the system, or if it is a long-running report.

The data traffic between the Client PC and application servers is much lower. However, the load per transaction has to be multiplied with the number of users working concurrently on the system. All this traffic is concentrated on the database server. Therefore, it's a good idea to have high-speed connections between the database and application servers. A separate segment for the SAP servers, isolated from the general network, is therefore recommended to prevent unnecessary data packages eating up server resources. Central systems need no separate network because the communication between the database and the SAP application is handled internally.

In addition to the load generated by interactive applications, background jobs have to be taken into account. They generate a similar load for each processing step to that of the interactive applications. However, there is no delay because of think time between the processing steps as with interactive users. External programs that use RFC to communicate with the SAP system also generate load between database and application server. If the external program executes a similar action to an interactive SAP transaction, the data traffic between the application server and the database is generally comparable to this transaction because the data must be updated in the same way.

There are other applications along with the SAP system necessary for operating it. For example, management agents, the heartbeats of cluster solutions, and so on generate additional load in the server network. The most important of these functions is backing up the database. The data traffic generated by this action has the same order of magnitude as accessing the database. In large installations, a separate network for backup purposes is recommended.

Low Latency IP Stacks

High-performance network interface cards are necessary, but also be wary of the drivers delivered with them. Poorly performing IP stacks can also degrade the system performance. A single transaction can cause a multitude of requests and responses going back and forth between the servers in a three-tier system. Any data package has to ripple up and down the IP stack in both servers. Even microseconds can add up to numbers influencing the system performance. Many vendors now offer high-speed network interface cards and switches with extremely low latency, such as Hewlett Packard's HyperFabric for Unix systems, Compaq's ServerNet II, and GigaNet's products for Windows NT/2000. The standard TCP/IP communications stack has been tuned to reduce the delays normally associated with moving data from network media to the application layer and back down to the media. The result is significantly improved performance for applications using TCP/IP over these types of technologies.

HP HyperFabric provides Full-duplex 1.28 Gbps with short-message latencies of ~31μs to 80μs (latency times up to 250μs are requested for FDDI interfaces; GigaEthernet is in the range of 120μs). As much as 50% lower CPU utilization than traditional networking technologies has been reported. Fast switches using wormhole routing technology for high-speed switching are available. Switches can be cascaded providing up to 2-km switch-to-switch distance. Smaller systems can be interconnected using crossover cables for a direct point-to-point connection. HyperFabric supports the TCP/IP protocol and the hardware SCN feature for SAP applications running Oracle Parallel Server. High-availability functionality is provided by HP MC/ServiceGuard.

For Windows 2000-based SAP systems, GigaNet offers high-speed network technology that can be used both with the traditional TCP/IP stack or with the new Windows Direct Sockets Path (DSP) technology found standard in Windows 2000 Data Center. Although DSP is no longer a TCP/IP protocol stack, SAP does support it between the database and application servers based on a homogeneous Windows 2000 Data Center environment. DSP offers significant performance improvements because it does not have the overhead of the TCP/IP stack.

Bandwidth Demand for SAP Front-End Communication

The classical SAP R/3 three-tier architecture is designed to minimize the data traffic between application server and the SAPGUI. Because all the graphics are done locally on the presentation client, the transmissions contain nearly pure content. Up to release 4.5 the amount of data transferred between the application and presentation servers increases moderately with each new release of SAP R/3, because SAP has improved the compression logic for the GUI to lower the rising bandwidth demand.

With the introduction of a new usability concept in R/3 release 4.6, the architecture of the GUIs has fundamentally changed. With the Enjoy SAPGUI, many transactions were redesigned to improve usability. The richer interaction model also increases the data necessary for a transaction screen. In previous R/3 releases, menu entries were downloaded from the application server only when the user actually opened a menu. Now the entire menu structure is transmitted with every screen, cutting out several communication steps, to improve the response time when users scroll or open a tree. However, consequently this results in an overhead of about 3KB per screen.

If a list of items is presented to the user, the amount of data transferred for each dialog step depends on the number of items that are present in the database. If the list gets very large, a bandwidth-saving feature is built into the list control. Only a portion of it is transferred at once and the rest is fetched later as the user scrolls down the list.

Because of the architectural changes the amount of data transferred now depends on the data that the application is currently processing. Due to their complex screens, EnjoySAP transactions have several communication steps (round-trips) to the front-end for each dialog step. However, because the number of dialog steps for each business process has decreased significantly, the number of communication steps to the front-end for each business process has only increased slightly.

There is no easy way to determine how much traffic an average SAP user places on a network. The load depends on the SAP transactions used, the user behavior, and, to a lesser extent, on the application data. Table 7-1 shows the number of transferred net kbit per screen change, measured by SAP.

Table 7-1. Front-End Network Traffic for Enjoy and mySAP.com

Release	4.0	4.5B	4.6A LSC	4.6A
FI	11.1	11.2	13.7	30.6
SD	10.9	11.8	36.8	60.6
MM	10.9	10.9	11.4	35.8
Average	11.0	11.3	20.6	42.3

In addition to dialog steps, keep-alive data packets are exchanged to detect inactive clients (consisting only of a few bytes). The amount of data that has to be transmitted depends on the data being processed by the user. For example, an editor control always has to transmit the entire text to the front-end for processing. Therefore, the amount transmitted depends on the size of the text. No statement can be made regarding the network load caused by downloading large tables (ex: for external table calculations), because the data involved depends entirely on the application.

Besides the bytes transferred per screen change, the bandwidth demand for user-based online transaction traffic depends also on how often the screens are changed. As already discussed in the sizing chapter, the screen changes per hour depend on user behavior. According to SAP, the typical medium user performs approximately one screen change every 30 seconds. Depending on the time of day, approximately 50–60% of the users who logged on are actually interacting with the SAP system. The uneven distribution of system usage over time makes it difficult to determine exact bandwidth considerations, however, the common load characteristic is network friendly, generating a relatively flat network profile without spikes.

The following formula from SAP can be used to estimate the required bandwidth between the presentation and the application servers. 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. In order to ensure acceptable network response times, line utilization should not be higher than 50% because data is not transferred in a continuous stream but rather has peak times within a statistical fluctuation. Only SAP dialogs are considered. The formula is based on measurements of the R/3 FI, MM, and SD Standard Application Benchmarks for release 4.6 using the LSC flag.

C_Network = Bandwidth required for SAPGUI data (in kilobits per second)

N_User= Number of users working simultaneously

t_Think = Thinking time needed by a user to process a screen (in seconds)

t_Resp = Response time needed by the system (in seconds)

Please note the following:

• The formula describes the SAPGUI dialog communication ONLY! Printing, graphics or up/download as well as the usage of X-controls were not taken into account.

• 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 you make your bandwidth at least double the result of the formula.

• The most imprecise part of the formula is the thinking time assumed for the user. One way to determine the think time of users is to analyze the statistical records (transaction STAT) over an extended period.

• 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.

In comparison with the classical SAP R/3 component, the other mySAP.com component products, like Business Warehouse (BW), Advanced Planning and Optimization (APO), and others, transfer much more data downstream per request. As a rule of thumb, BW or APO users generate five times the network traffic of a typical R/3 user. On the other hand, the user numbers for these systems are significantly low and their think time is usually higher compared with an R/3 system.

JavaGUI

The SAP GUI for the Java™ Environment is installed completely as an application on the respective computer and communicates directly with the SAP application server. Therefore, the SAP GUI for Java can be expected to cause the same network load as the common WinGUI. However, the LSC flag is not being supported.

WebGUI

From a network perspective, the SAP GUI for HTML (WebGUI) can be considered as a standard web application. Compared with even the newest EnjoySAP GUI, common Internet pages use many more visual components like wallpapers, logos, banners, and animated bullets. Consequently, the WebGUI is at the lower end of bandwidth demand. Basically, one HTML file is transferred per business transaction. The size of the HTML file is the indicator of the traffic that goes across the network (see Table 7-2). With SAP compression implementation, the network load for the WebGUI will be reduced 70 to 90%.

The network traffic between the two parts of the SAP Internet Transaction Server (ITS) consists of the HTML pages generated by the AGate, the requests produced by the browser, and a minimal protocol overhead. In tests performed by SAP, each dialog step creates average traffic of about 16KB. Enabling the built-in DES encryption algorithm results in an overhead of about 10%.

Table 7-2. HTML File Size in Kilobits for WebGUI

FI	391.5
SD	596.7
MM	431.4
Average	473.2

Because ITS did not support compression, the amount of data transmitted between application server and AGate is two times the normal WinGUI traffic. WebRFC and WebReporting use RFC to send the HTML text of the generated web page from the SAP system to the AGate. Because RFC uses data compression, the actual network load is smaller than the HTML page size. In tests performed by SAP, each dialog step creates average network traffic of about 5KB between application server and AGate.

NC and NetPC

Network computers (NC) and NetPCs can be deployed as front-end systems with the SAPGUI installation centralized on a terminal server. Data transmission between application server and front-end is then directed to the terminal server where the SAPGUI is executed. The additional computing tier generates additional network traffic. Any user keyboard or mouse input must be transferred to the terminal server, as well as all the graphical output from the terminal server to the client.

The additional network traffic depends on how many keystrokes and mouse movements are used for each dialog step. SAP measured 20–40KB for each dialog step in a typical SD Benchmark (see Figure 7-3). This is about ten times more than for the SAPGUI itself. Citrix Meta- frame clients generate about 30% less network traffic due to improved compression. However, the bandwidth demand is still several times the bandwidth used for a locally installed SAPGUI. To avoid voluminous traffic traversing WAN links, a dedicated terminal server can be installed at remote sites. This way, the traffic between terminal server and clients is restricted to the local area network.

Switch Off the Splash Animations like the splash wave screen on the upper right in the SAPGUI slow down performance considerably during an operation via a terminal server. You can deactivate this animation via an entry in the registry of the Terminal Server: HKEY_CURRENT_USERSOFTWARESAPGeneralAppearanceAnimation: Off HKEY_CURRENT_USERSOFTWARESAPGeneralAppearanceSplashOff: 0x1 Turning off the Enjoy Design (Control Panel → SAP Configuration), deactivating the right screen in the Easy Access Menu (Easy Access Menu → Extras → Settings → Do not display image) and the LSC option (SAP LOGON → Properties → Advanced → Low Speed Connection) further reduce network traffic by reducing the number of less important screen changes.

Bandwidth Demand for Print Output

Within SAP R/3, the output of documents to peripheral devices is controlled by a dedicated spooling work process. Every application server running a spool process can generate print jobs and is therefore a source of output network traffic. As mentioned previously, documents can be generated by SAP systems in many ways. Printers, fax machines, telex, and so on can be attached directly to the SAP application server, avoiding network traffic caused by output generation. Having the printer locally in the data center makes sense for high-volume (bulk mailing or faxes) or sensitive print jobs (earnings statements). Most of the printers, however, are normally located in the various work areas where the printouts are needed.

Like the network traffic of standard SAPGUI dialog users, print output is not really a challenge for state-of-the-art local network infrastructures. Although printer output has a higher bandwidth demand for continuous operation than common SAPGUI users, there are fewer printers than users in a common SAP environment. For remote WAN connections, however, there is a more sensitive situation. Because of the relatively low bandwidth available and higher prices of wide area links, special attention should be devoted to the bandwidth demand of the different options for SAP output.

Output Devices

The output device type is the SAP printer driver. The device type contains the information needed to format data for output on a particular type of printing or fax device. The formatting system uses the information in the device type to prepare raw data from the SAP system for output on a printer. Therefore, the output device type determines the formatting language or printer language to be used. SAP supports several common printer languages, including Postscript from Adobe and PCL from Hewlett Packard. The SWIN (SAP Win) device type uses Windows formatting and Windows fonts for printing. The addition of formatting information to the raw body text also adds overhead to the print data. Therefore, the choice of the output device influences the bandwidth demand.

According to an SAP whitepaper, the additional overhead for common printer languages is approximately

• 20% for Postscript devices

• 10% for HP PCL devices

• 8% SAPWIN devices

Print Job Size

Each output job contains information about the chosen output device, the format type (portrait, landscape, duplex, simplex, etc.), and the resolution. This extra information adds overhead to the output data. Small print jobs of only one page may result in approximately 100% overhead due to the print job administration in relation to the transmitted data. A print job of ten pages lowers the administration overhead to approximately 10%, according to SAP.

Access Method

Just as the choice of the output device type determines the printer language, the choice of the access method defines the protocol used for the transmission of print data. The SAP system distinguishes between local and remote access for spooling. A local print job does not necessarily mean that the printer is attached directly to the server from where the print job was started. The terms “local” and “remote” are defined from a point of view of the SAP system. Local simply means that the printer can be accessed through the operating system of the application server executing the SAP Spool process. For remote printing, the Spool services of a remote computer are used. Remote in this sense refers to anything that is not a part of the SAP system itself. From a network point of view, printing is really considered local only for printers physically attached to a printer interface of the computer executing the SAP Spool process. In all other cases, the print data traverses the network.

The Spool process can access any printing system that can handle the lpr/lpd protocol (line printer requester/line printer daemon). The communication is based on the Berkeley protocol (RFC 1179), introduced with the grandfather of all Unixes, the Berkeley System Distribution (BSD). Various data formats like PostScript or HP's PCL can be transmitted using this protocol. However, Windows does not have a line printer daemon (lpd). To be able to print using lpr/lpd, SAP developed its own lpd program for Windows PCs called SAPLPD, which is installed with the WinGUI. SAPLPD contains some extensions of the lpd protocol, for example, data compression, encryption using the SAP standard SNC (Secure Network Communication), and data transmission using the SAProuter.

Lpr/lpd transmits the print data uncompressed over the network. Therefore, the network load corresponds to the number of characters to be printed and the print job overhead. The SAPLPD access method differs from the lpr/lpd protocol in that the print data are compressed. For full body text pages, the compression rate reaches up to 3:1. This type of front-end printing is most suitable for large print jobs. Front-end output on devices directly attached to user work stations generates additional load on the dialog work process, as well as the most network traffic overhead. Therefore, front-end printing is only suitable for occasional interactive printing of small documents.

Measurements from SAP show the combined effect of output devices, access methods, and print job sizes on network bandwidth. Tables 7-3 through 7-5 show the ratios of transmitted data to plain text without formatting (approx. 5200 characters per page) for SAP release 4.0B with SAPLPD version 4.08.

Table 7-3. Size of Formatted Print Files Compared with Raw Files: Front-End

Front-End Printing	1 page	10 pages	100 pages
SWIN	376%	235%	258%

Table 7-4. Size of Formatted Print Files Compared with Raw Files: UNIX lpd

UNIX lpd	1 page	10 pages	100 pages
Postscript	234%	130%	122%
HP PCL	160%	112%	110%
SWIN	145%	110%	108%

Table 7-5. Size of Formatted Print Files Compared with Raw Files: SAP LPD

SAPLPD	1 page	10 pages	100 pages
Postscript	146%	53%	38%
HP PCL	133%	50%	36%
SWIN	128%	47%	35%

As mentioned earlier, pure ASCII text is not used for printouts in most cases. At a minimum, customer-related paperwork, such as offers, invoices, billings, and so on, have to align with the company's corporate identity policy. As an example, purchase orders often use recurring text, such as General Terms and Conditions, printed on the back of a page.

Electronic forms generated by SAPscript or server-based printing solutions cause a considerably higher network load due to the large amount of redundant data and format information that is transmitted to the printer.

Printer-Based Forms use the printer's functionality to store and process forms resident in the printer's memory. This way, the data flow to the printer is kept to a minimum, just as it is when using preprinted forms. According to test results from iXOS, an IDES printout with logo was reduced from 23.4KB (using SAPscript) to 2.08KB using a printer-based forms solution. The network load was reduced by a factor of 10–55% depending on the form's layout.

Bandwidth Demand for CPI-C Connections

The CPI-C (Common User Programming Interface-Communication) protocol is the technology basis for all connectivity between one SAP system and other computer systems. This can be another R/3 system, an R/2 system residing on a host with a proprietary operating system (MVS/VSE or BS2000), as well as any other external system. Therefore, CPI-C supports IBM's proprietary SNA LU 6.2 protocol as well as the common TCP/IP protocol. 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 its turn to transmit.

The CPI-C protocol transmits data in character format in packets of up to 30KB. Because there is no data compression with the CPI-C protocol, the network load during data transmission is proportional to the amount of transmitted user data. Measurements by SAP with varying amounts of data and packet sizes for R/3 release 4.0 show 2KB overhead per CPI-C connection plus a general 10% overhead for the raw data. This data led to the following formula for calculating the network bandwidth:

The parameters of the formula are:

C_CPI-C = Required bandwidth for CPI-C in kilobit/second

N_Connection = Number of connections in time period t

V_Data = Amount of user data (in kilobytes) to be transmitted in t

t = Time period in seconds

Bandwidth Demand for RFC Data Transmission

RFC (Remote Function Call) is a communications layer SAP built on top of CPI-C. RFC enables the functional coupling among SAP systems, as well as with external systems beyond SAP system borders according to business demand. Therefore, RFC plays a central role for communication within a mySAP landscape. In conjunction with RFC, the transmission of data (plain text, IDocs, binary data, etc.) can be initiated. A prominent example is synchronizing master data within distributed SAP systems using Application Link Enabling (ALE).

RFC is also the basis for communication with a wide range of external systems. Depending on the characteristics and the time distribution, the traffic generated by external systems of ten can be higher than traffic generated by user-generated dialog transactions. Just a few examples are given next of the nearly uncountable number of SAP modules using the RFC functionality:

• SAPconnect to fax, pager, email systems, SMTP- and X.400-Gateways

• SAPphone Telephony Integration (Call Center functionality)

• MM-MOB to mobile data-entry devices, like barcode readers with radio support

• WM-LSR to warehouse control systems, forklift control systems, carousels, and so on

• PM-PCS to process control systems (measurement transfer and counter readings)

• SCADA to Supervisory Control and Data Acquisition Systems

• SAP Retail Point-of-Sales (POS) interface to electronic cash register systems

The RFC interface resides logically one layer above CPI-C (see Figure 7-4). This way, network load caused by RFC has to be superimposed on the load initiated by the CPI-C protocol. The network load is influenced by several factors when you use the SAP RFC protocol to transmit data. The data sent over the network consists of the application data that is transmitted and the RFC protocol overhead. RFC protocol overhead is caused by the data needed for establishing the connection, calling the function module and data coding, compression, flow control, and backup. However, RFC compresses the data before handing them over to CPI-C for transmission.

Most of the overhead is marginally low compared with data transmission, however sending each RFC separately causes a higher network load than sending RFCs in groups. According to information from SAP, valid for R/3 release 4.0, a few points must taken into consideration regarding the required network bandwidth, as described in the next paragraphs. Each time a connection is established, logon data and other system parameters, such as character codepages, are exchanged. This causes a system load of approximately 2.5–3KB on the network for each connection to the SAP system. RFC connections from the SAP system to external systems have similar bandwidth demands. An existing connection can be used for several function calls to different modules on the same target system. A new logon to the SAP system is not needed. Sending a group of previously assembled IDocs causes lower network load than sending each independently. The registration procedure causes a 1238-byte overhead. For RFC servers that are pre registered on the gateway, approximately 3KB more data are transmitted compared with the programs started on the gateway.

The SAP system uses different types of RFC data transmission:

• Synchronous RFC (sRFC)—In a synchronous call, the RFC client waits for the result of the call before the program is continued.

• Asynchronous RFC (aRFC)—It starts the function module in the background. The RFC client does not wait for the result of the call.

• Transactional RFC (tRFC)—This type of RFC call ensures that the call is processed only once in the target system. If a connection is terminated, the RFC client repeats the call.

• Serialized RFC (qRFC)—In a serialized call, the process writes the request to a queue. The process does not wait for the transmission of the call. The RFCs collected by the queue will be sent together to their destination. This way the network load is reduced.

Synchronous RFC and asynchronous RFC create both the connection overheads mentioned previously. Transactional RFC causes a marginally greater overhead of approximately 600 bytes for each call.

Data is normally compressed before being transmitted. Because the compression factor of the data depends on the content, a general statement about the required bandwidth of an RFC transmission cannot be made. Measurements by SAP for three examples can be used as a rule of thumb under certain conditions:

• Transmission of approximately 100KB of already compressed data. An overhead of approximately 10% more than the transmitted data has been measured.

• Transmission of approximately 100KB text data from IDES to tables. Table rows are filled with empty characters up to the end of the row (corresponds to the representation of IDocs in the SAP system). A total of approximately 30–40% network load compared with the raw data was measured.

• Transmission of approximately 100KB in text data with random characters that do not conform to a specific model. A total of approximately 90–100% network load compared with the raw data was measured.

Only connections between external programs and an SAP system were considered for these measurements. The statements are limited to transmitting data using tables and not simple or structured parameters. Unfortunately, no statement has been made about RFC connections between two R/3 systems. As a worst-case scenario, a maximum of 1.1 times that of the transmitted data has to be expected.

Business Information Warehouse (BW)

The architecture of the Business Information Warehouse system (BW) follows the same three-tier approach as the classical R/3 system. Therefore, the traffic patterns are similar. The network load between application and database server is almost the same as with R/3. However, the transmission of large tables from the SAP BW application server to the SAP BW front-end generates significantly more spiky network traffic than standard R/3 GUI dialog usage.

The appropriate transfer rate for the data upload from the operational SAP R/3 system to the SAP BW system depends on volume and frequency of loading processes. SAP recommends a minimum transfer rate capacity of 10 Mbps if weekly updates into SAP BW are planned. With several transfers per day, even higher transfer rate capacities are recommended.

Advanced Planner and Optimizer (APO)

SAP APO can be considered to be as network consuming as SAP BW. The network load between the application and database servers is almost the same as with SAP R/3. Between the liveCache and application servers only a small amount of information is transferred. Most work is done internally in the liveCache itself. Of course, for larger configurations it depends on the volume processed by liveCache, especially if you have an OLTP system connected for Available to Promise (ATP) functionality. Therefore, a load similar to the traffic between application and database servers can be taken into account to be on the safe side. The load resulting from occasional transfers of production plans from the application server to the optimizer PC is usually small. The traffic between the SAP APO application server and its front-end workstations is most of the time similar to standard SAPGUI traffic. However, geographical data representation in the Supply Network Planning (SNP) module could increase the load about two to three times.