Show TOC

Background documentationHigh Availability of the SAP Web Dispatcher Locate this document in the navigation structure


You have different options to ensure high availability of the SAP Web Dispatcher.

  • High availability at process level (on same host)

  • High availability with standby Web Dispatcher (with HA solution)

  • High availability with several parallel Web Dispatchers

High Availability at Process Level

You can provide for high availability of the SAP Web Dispatcher at process level, which will protect against software errors. This will not protect against the whole machine crashing.

RESTART Option in the Profile

You can use the RESTART command in the instance profile to enable the start service to restart the process if the system crashes.

To do this, add the restart line for the program to the instance profile. For example,

Restart_Program_00 = local sapwebdisp pf=$(DIR_PROFILE)/BIN_WD77

This option is available on all platforms, but only if the SAP Web Dispatcher was started by the start service sapstartsrv.

Start Option: -auto-restart

On UNIX platforms the option -auto_restart is also available when starting the Web Dispatcher. In this case the Web Dispatcher behaves as follows:

  1. The necessary resources (shared memories, sockets, administration structures) of the SAP Web Dispatcher are loaded when it is started.

  2. This process is then duplicated by the system call fork(), that is, there are now two processes that know exactly the same shared memories, sockets, and administration structures. The original process (parent process P) takes over the monitoring function (watchdog), whilst the new process (child process C) takes care of the actual tasks of the SAP Web Dispatcher (forwarding requests, load balancing,…).

  3. The monitoring process P then checks every n seconds the status of the SAP Web Dispatcher process C.

    If the C process ends (whether this is required or unexpected), the watchdog P recognizes this and the state of the process that was frozen after it was started is duplicated again (fork).

This has the following advantages:

  • Fast recreation of the SAP Web Dispatcher, because the resources do not have to be created for the first time

  • “Zero downtime”, because requests to the SAP Web Dispatcher do not get lost but are stored in the system queue and can be processed after the process is duplicated by the SAP Web Dispatcher work process (C). Requests that were being processed when the crash happened will, of course, be lost.

Caution Caution

Restrictions for operating systems

Option -auto_restart is not supported under z/OS and Windows.

End of the caution.
Ending the HA SAP Web Dispatcher

If you want to stop the SAP Web Dispatcher, ensure that you stop the watchdog process (P) (this is started if you stop the other process!). To do this, send a SIGINT to the watchdog’s PID. You can take this from the trace file dev_webdisp_watchdog.

Stopping the watchdog also stops the SAP Web Dispatcher work process C.

High Availability of SAP Web Dispatcher with External HA Software

The SAP Web Dispatcher can be monitored by HA software, and restarted if the system crashes (on a different host).

This graphic is explained in the accompanying text.

You can use this procedure in all scenarios:

  • Scenarios with SAP NetWeaver Portal

  • Scenarios without SAP NetWeaver Portal

  • Scenarios with ROUTER protocol (End-to-End SSL)

More information:

Microsoft Cluster Service (MSCS) configuration, SAP Note 834184

Option shm_attach_mode in section Starting SAP Web Dispatcher.

High Availability with Parallel Web Dispatchers

You can provide high availability with parallel SAP Web Dispatchers too. Both Web Dispatchers have the same configuration and forward their requests to the target system. Since stickiness is achieved by using a cookie, a stateful request will get to the correct application server in any case.

Then a load balancer distributes the requests to the Web Dispatchers. You can also use DNS load balancing for this.

This graphic is explained in the accompanying text.


You can work with parallel Web Dispatchers in the following scenarios:

  • Scenario without Enterprise Portal

  • Web Dispatcher is positioned in front of an EP system

Caution Caution

This procedure cannot be used in the following scenarios, unless additional effort is put in to setting up the configuration):

  • Web Dispatcher is positioned in front of a back-end system with Applications in the Enterprise Portal (see example below)

  • The Web Dispatcher is operated with the ROUTER protocol (End-to-End SSL)

The configuration of parallel Web Dispatchers with a load balancer will work in these scenarios if the load balancer forwards requests from a user (from an IP address or IP address mask) always to the same Web Dispatcher.

End of the caution.


You have a portal system EP with one Web Dispatcher (WD1), positioned in front of the portal servers, which performs load balancing for incoming requests.

In the Portal there is an iView, through which you can access an SAP application in a back-end system. The back-end system consists of multiple instances with one Web Dispatcher WD2 for load balancing.

Communication with the various components works as follows:

  1. The client (browser) sends the request through the Web Dispatcher to the portal system.

  2. The user triggers a request in an iView, which must then be processed in the back-end system. In the Portal a URL is generated and sent to the client.

  3. The client uses this URL for the next request, and through the Web Dispatcher in the WD2 back-end system reaches an instance in the back-end system. The response to the request is created here, and sent back to the client.

For this procedure to work, the Web Dispatcher must keep an internal status in front of the back end system (WD2), and can only be configured for high availability through two parallel Web Dispatchers if an external load balancer is placed in front of the Web Dispatchers, which guarantees that requests from the same user are always forwarded to the same Web Dispatcher.

High availability at process level is also provided here, or the HA setup with external software.

Web Dispatcher WD1 can however be configured for high availability without any restrictions by using a parallel activated Web Dispatcher (see above).

This process is represented in the graphic below.

This graphic is explained in the accompanying text.