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.
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 Enterprise Portal
Scenarios without SAP Enterprise Portal
Scenarios with ROUTER protocol
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
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.
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.
Soft Shutdown and Startup of Parallel Web Dispatchers
The previous section described the cases where SAP Web Dispatchers can be operated in parallel. If multiple SAP Web Dispatchers are running in parallel, they should be started and stopped in “soft” mode to ensure that the performance of running applications is not affected.
To do this, the SAP Web Dispatcher reports information about its state. When the SAP Web Dispatcher is started, it reads its configuration from the connected back end. It does not reach the Running status until it has read the configuration from all connected back ends, or as the case may be, until it could not read them within a specified time. When it stops, the Web Dispatcher leaves the Running status, but continues to process requests.
After a predefined time, it can respond to pending requests, but does not accept any new requests. The SAP Web Dispatcher informs an upstream load balancer whether the load balancer is to forward requests to the SAP Web Dispatcher. If multiple SAP Web Dispatchers are to run in parallel, individual SAP Web Dispatchers can be stopped and started with no effect on end users.
ConfigurationParameter wdisp/status_poll_interval (default 0 seconds) specifies the time internal in which an upstream load balancer queries the state of a Web Dispatcher (see below). The Web Dispatcher quits the state Running as soon as it receives a soft shutdown request. However, SAP Web Dispatcher still accepts new connections for the duration of the configured poll interval in order to give the load balancer time to recognize the change of state.
Parameter icm/max_init_time (default 120 seconds) specifies the time in which the Web Dispatcher tries to read the configuration from the back end. If the SAP Web Dispatcher reads the back-end configuration successfully, it returns the state Running. If the time runs out before the SAP Web Dispatcher has read the configuration successfully, the state still changes to Running.
Performing a Soft Shutdown
Soft shutdown can be initiated from an SAP start service method, from Web administration (monitoring), or from the operating system signal SIGQUIT.
Querying the SAP Web Dispatcher State
Two methods are supported for quering the state of the SAP Web Dispatcher (e.g. from an upstream load balancer):
SAP start service method (sapcontrol .....-function GetProcessList)
Publically accessible URL <PREFIX>/publicicp/show_init_statepub.icp
In this case, only new requests should be sent to the SAP Web Dispatcher if the state is Running (or GREEN) in SAP start service or Running (show_init_statepub.icp). Otherwise the Web Dispatcher cannot guarantee that the requests are forwarded to the back end. In addition the state is displayed in the web administration interface.
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.
