SAP Web Dispatcher
1. What is Web Dispatcher?
The SAP Web Dispatcher is an application-level gateway (proxy) for HTTP requests to an SAP Web Application Server. The SAP Web Dispatcher is used as a software Web switch between the Internet and an SAP System. The SAP Web Dispatcher consists of one or more Web Application Servers. As a result, you have only one point of access for HTTP(S) requests in your system. In addition, the SAP Web Dispatcher balances the load so that the request is always sent to the server with the highest capacity.
It acts as the single entry point for all web requests destined for applications running on the SAP Web AS. It distributes and load balances these requests among the different application server instances. As such, the SAP Web Dispatcher represents a “first line of defense” against all kinds of attacks at the network and protocol level – mainly denial of service attacks by network flooding, and protocol attacks via malformed URLs and HTTP requests, such as buffer overflow attacks.
At the same time, the SAP Web Dispatcher provides load balancing for both stateless and stateful SAP applications, whether they are Business Server Pages (BSP) or Java-based (J2EE) applications. The Web Dispatcher functions keep track of the current load of the application server instances and take care that web requests belonging to one session are always sent to the same application server instance holding that session.
2. Balance the load between multiple Java / ABAP Application servers of a single SID
One of the basic functionality of web dispatcher is that, it can help to balance the load between the application servers. Web Dispatcher does not establish connectivity directly with the application servers, rather it will establish the connectivity to Message Server to ensure the load is balanced across application servers.
Below are few features of Web Dispatcher related to Load Balancing:
- Client IP address-based
- Static round robin
- Weighted round robin
- Dynamic load balancing
Load Balancing and Security Requirement with End-To-End SSL (with one web dispatcher supporting multiple application servers of a single SAP system)
In the below scenario, Web Dispatcher is placed in DMZ, it is acting as a reverse-proxy and as a load balancer. The user initiates an HTTPS request and the same protocol (HTTPS) is used to establish connectivity from Web Dispatcher to ASCS, this method is called End-To-End SSL. Architecture
3. Technically possible to have a single Web Dispatcher instance to support multiple backend systems
As of Netweaver 7.2, it is technically possible to a single Web Dispatcher to support multiple back end system.
The common pros and cons of the approach is outlined in below table.
| Area | Standalone | Single Host Multiple Systems |
Comments |
| Performance | + | – | In a stand-alone installation there is no competition for hardware resources. However, hardware cost needs to be factored in. |
| Administration | – | + | When systems are separate administration overhead increases. A single action may have to be repeated multiple times on separate systems. Each system has to be started and stopped individually, for example. Configuration actions – such as profile parameters. In a single system, actions only have to be performed once. |
| Monitoring | + | – | It is very easy to see that there are fewer systems to monitor in a single host systems. However, there is a higher degree of complexity in diagnostics. When an error does occur there are more possible causes in a single system scenario. In separate systems it is always known what application is causing the problem. |
| Availability | + | – | Separate systems may be stopped and started individually Separate Systems increase availability and hardware costs High Availability with “Single Server with Multiple Systems” is Complex |
| Backup/Recovery | + | – | All systems affected by a Crash / Restore in Single Server with Multiple Systems |
| Infrastructure Security |
+ | – | Firewall only possible in separate systems (with increased administration). BU specific security requirement may not be achievable. |
| Licensing | – | + | Depending on how third party tools are licensed there is an opportunity for reduced licensing fees with a single system. If tools – such as operating system and database tools, monitoring tools, scheduling tools, back-up tools, high availability solutions, print solutions, and so on – are purchased and licensed by server then implementing on fewer servers will result in lower costs for the tools. |
| SAP Software Maintenance |
– | + | Combined systems are upgraded and patched together |
Load Balancing and Security Requirement with SSL Termination (with one web dispatcher against multiple SAP systems)
As of Netweaver 7.2, it is possible to use single Web Dispatcher instance connect to multiple backend systems, in addition to that 7.2 is backward compatible and can be connected to systems upto Web AS 6.10.
In this scenario, SSL termination is also depicted below, the user initiates an HTTPS request to Web Dispatcher, while communicating with SAP systems, Web Dispatcher uses the HTTP protocol.
The main disadvantage of this approach is that the hardware requirement and implementation effort will be little higher. Detailed comparison between E2E SSL and SSL Termination will be discussed in the following sections.
4. General guidelines on Hardware Requirement?
The hardware consumption of the Web Dispatcher is highly influenced by the below variants.
Scenario :
- No SSL
- Termination of SSL
- Termination and re-encryption of SSL
System Load :
- Messages per second
- Message Length (Average length of SAP application is 16 Kbytes
We have two different options listed below to size Web Dispatcher, we can choose one of the method based on the information that we have on the requirement.
User Based Sizing for CPU:
- Number of Active Concurrent Users during the peak period : N
- Average think time between 2 successive user interaction steps : ThT
- Average Number of Messages per user interaction step : m
- Messages per second = N * m / ThT
| CPU Sizing | Example | SID 1 | SID 2 | SID 3 | SID 4 |
| Number of Active/Concurrent User : | 10000 | ||||
| Average Think Time Between 2 Successive
Interaction Steps in Seconds |
20 | ||||
| Average Number of Messages Per Interaction Step | 2 |
| Messages Per Second | 1000 | ||||
| Category | Example | SID 1 | SID 2 | SID 3 | SID 4 |
| SAPS in case of HTTP | 1600 | ||||
| SAPS in case of HTTPS Termination | 2900 | ||||
| SAPS in case of HTTPS Re-Encryption | 3480 | ||||
|
|
Total SAPs for All the Systems | ||||
| Total SAPS required | |||||
* Realistic values for Average Number of Messages per Interaction Step can be obtained by carefully monitoring the network statistics
Throughput Based Sizing for CPU :
Peak Load Duration : T
- Number of Transactions which are processed within the peak load duration : K
- Average number of messages per transaction : n
- Messages Per Second = K * n / T
It is recommended to monitor network traffic for the application scenario to get the more realistic values for m and n mentioned above.
| CPU Sizing | Example | SID 1 | SID 2 | SID 3 | SID 4 |
| Peak Load Duration | 1800 | ||||
| Number of transactions which are processed within the peak load | 60000 | ||||
| Average Number of Messages per Transaction | 10 | ||||
| Messages Per Second | 333 | ||||
| Category | Example | SID 1 | SID 2 | SID 3 | SID 4 |
| SAPS in case of HTTP | 533 | ||||
| SAPS in case of HTTPS Termination | 967 | ||||
| SAPS in case of HTTPS Re-Encryption | 1160 | ||||
| 2660 | Total SAPs for All the Systems | ||||
| Total SAPS required | |||||
* Realistic values for Average Number of Messages per Transaction can be obtained by carefully monitoring the network statistics
5. End-to-End SSL / SSL-Termination pros and cons
SSL is required in case of any need to protect the business data such as user credentials (e.g. passwords) and data security. It basically encrypts entire communication between browser and server.
Web Dispatcher in End-To-End SSL mode
Pros :
- Client authentication with X.509 certificates
- End-to-End data security
- Load balancer is “untrusted” component
Cons :
- Persistence based on client IP address only
- Load balancing problems :
- Proxies
- End of Session
- IP Address based persistence usually OK in internet
- No logon groups
- No distinction between J2EE and ABAP applications
Web Dispatcher in SSL Termination mode :
Pros :
- Persistence based on application session ID
- Logon groups
- Detection of application type (ABAP/J2EE), select correct server
- Request parsing and URL filtering
- SSL re-encryption is possible
Cons :
- Harder to configure
- Web Dispatcher becomes “trusted component” (secure channel to WebAS needed)
- Make sure Web Dispatcher does not become performance bottleneck as it needs higher CPU capacity
6. Key Points
We have various scenarios that can be used while implementing Web Dispatcher, the scenario to be chosen comes down to one’s requirement of security, performance, cost, effort, etc., Some of the interesting facts about web dispatcher are listed below.
- Web Dispatcher is a software load balancer and application layer gateway for SAP Web AS
- Web Dispatcher is not a reverse proxy, not meant to be.
- As of Netweaver 7.2, it is possible to have single web dispatcher to cater to multiple backend systems, NW 7.2 based Web Dispatcher is backward compatible and supports up to 6.10
- Both End-to-End SSL and SSL Termination are available, SSL options to be chosen based on the requirement and by carefully analyzing the hardware and cost involved in setting up the chosen SSL option
- It is recommended to perform the sizing exercise with the realistic inputs
- No additional cost involved for license, Web Dispatcher is delivered at free of cost (part of Web AS)
