High Availability of the SAP Web Dispatcher 
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:
The necessary resources (shared memories, sockets, administration structures) of the SAP Web Dispatcher are loaded when it is started.
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,…).
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
Restrictions for operating systems
Option -auto_restart is not supported under z/OS and Windows.
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).
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.
Scenarios
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
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.
Example
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:
The client (browser) sends the request through the Web Dispatcher to the portal system.
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.
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.
