Introduction

The SAP Web Dispatcher lies between the Internet and your SAP systemSAP system. It is the entry point for HTTP(s) requests into your system, which consists of one or more NetWeaver application servers. As a "software web switch", the SAP Web Dispatcher can reject or accept connections. When it accepts a connection, it balances the load to ensure an even distribution across the servers.

You can use the SAP Web Dispatcher in ABAP/Java systems and in pure Java systems, as well as in pure ABAP systems.

SAP Web dispatcher architecture

Figure 1 : The SAP Web Dispatcher architecture

The SAP Web dispatcher performs the following tasks:

  • Selection of appropriate application server (persistence with stateful applications, load balancing, ABAP or Java server).
  • Configuration for multiple systems - You can place a SAP Web Dispatcher in front of multiple SAP systems, and configure which requests go to which system, or perform load balancing across system boundaries.
  • URL filtering - You can define URLs that you want to be rejected, and by doing so restrict access to your system.
  • Web caching – you can use the SAP Web Dispatcher as a Web Cache to improve the response times and to conserver the application server cache.
  • URL rewriting, manipulation of HTTP header fields – The Web Dispatcher can manipulate inbound HTTP requests in general on the basis of defined rules.
  • Depending on the SSL configuration you can forward, terminate, and (re)encrypt requests.

First of all, the SAP Web Dispatcher checks the type of the incoming request. The process flow described here works only if the request is not an administration request.

An HTTP request (or a decrypted HTTPS request) is assigned to a server in two stages.

First, the SAP Web Dispatcher decides whether the incoming HTTP request should be forwarded to an ABAP or a Java server. It ascertains a group of servers in the SAP system that could execute the request. It gets information about the groups from the back end (AS ABAP or AS Java), or from a file.

The load is then balanced within this group. When the load balancing process has decided on the server that the request is to be sent to, the SAP Web Dispatcher forwards it to the ICM of this application server.

If the request should be sent to an AS ABAP, then you must check whether a logon group (maintained in transaction SMLG) has been defined for this URL. The SAP Web dispatcher checks the list of logon groups to see if one has been defined. If it finds one, the load balancing must be executed within this logon group.

Both static and dynamic elements are used for load balancing with the SAP Web Dispatcher. The Web Dispatcher provides various procedures for load balancing.

Since with End-to-End SSL HTTPS requests the SAP Web Dispatcher is unable to read the URL, it can only distribute HTTPS requests in turn to the HTTPS-enabled servers in the system. This also takes into consideration the capacity of each server. To be able to process Java requests, each HTTPS-enabled server must have integrated the AS Java. The ICM of the server that receives the HTTPS request can decode the URL and then decide whether the request should be sent to AS ABAP or AS Java.

If the requests are not load balanced or if the SAP Web Dispatcher is not able to load balance the requests, then the requests may not be executed or may take too long to complete. To avoid such anomalies, administrators should continuously track the flow of HTTP requests on the SAP Web Dispatcher. This is where eG Enterprise lends helping hands to administrators.