SAP Web Dispatcher

This documentation is copyright by SAP AG.

What is the SAP Web Dispatcher?

The SAP Web Dispatcher is the entry point for HTTP(S) requests into your system, which consists of one or more NetWeaver application servers.
It combines the advantages of a "software web switch", a "reverse proxy" and an "application gateway".
The SAP Web Dispatcher contributes to security by accepting/denying incoming connections and ensures an even distribution of requests 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.

How to configure SAP Web Dispatcher for URL Rewriting?

As of release 7.10 the SAP Web Dispatcher includes a modification handler which can be configured for rewriting URLs :
With the parameter icm/HTTP/mod_<xx> you can configure modifications of HTTP Requests and define rules by which the SAP Web Dispatcher changes the HTTP request before it forwards it. This includes header field manipulation, URL rewrite and other functions. A complete set of possibilities of configurations can be found in the online documentation, as well as a detailed description of how to configure rewriting URLs.

http://help.sap.com/saphelp_nwpi711/helpdata/en/4d/684daeecd446e7b5e9999496166e3f/frameset.htm

back

How can the SAP Web Dispatcher be monitored?

You can use the Web administration interface to administrate, monitor, and set traces in the SAP Web Dispatcher. Detailed information can be found in the online documentation under the following link -->
http://help.sap.com/saphelp_nwpi711/helpdata/en/5c/b711385ef74d2aada9a7bf12eacd0c/frameset.htm

Alternatively, you can access the Web Dispatcher administration and monitoring functions from the command line. Detailed information can be found in the online documentation under the following link -->
http://help.sap.com/saphelp_nwpi711/helpdata/en/48/7f2fb37df935e1e10000000a42189c/frameset.htm

You should only use these if you have problems with the Web administration.

back

How to set connection/processing timeout period for ICF services

Session Timeout

While the SAPGUI is directly connected to the Application Server using a socket the Application Server can frequently check this socket and verify if the GUI is still alive. Web services are connected only while a HTTP request is received/send and therefore it is not possible to check if the browser GUI is still alive or not. As long as the web service is not stateful the backend does not hold resources and a cleanup is not necessary. For stateful web services the backend holds the session context and this resource has to be deleted when a timeout is reached.

There are a couple of ideas to inform the Application Server about the status of the browser GUI, - e.g. through automatically sending a ping request every 5 minutes using JavaScript to reset the timeout counter, or e. g. sending a close request to the Application Server if the browser GUI is closing to inform the Application Server to cleanup resources immediately instead of holding unneeded resources until the timeout happens.
Depending on the strategy the application has chosen you should set the timeout to a shorter or longer period.

General/Default session timeout setting within the SAP kernel:

Kernel parameters:

rdisp/gui_auto_logout
rdisp/plugin_auto_logout

The SAP kernel regularly checks whether a session is still in use. Any session that is no longer in use is removed. If the parameter rdisp/gui_auto_logout is set, this timeout also applies to HTTP sessions as well as GUI sessions. If you want to reduce the timeout for the HTTP sessions, you can do so using the parameter rdisp/plugin_auto_logout.
To reduce the session timeout in general for all HTTP sessions, set a shorter timeout than for the other SAP GUIs with the parameter rdisp/plugin_auto_logout.

Sample:

rdisp/gui_auto_logout = 14400
rdisp/plugin_auto_logout = 3600

SAPGUI sessions will be closed after 4 hours (14400 seconds) while HTTP sessions are already terminated after 1 hour (3600 seconds) of inactivity. (Please use transaction RZ11 for detailed parameter description)

It is possible to overwrite this general timeout setting in transaction SICF for each individual service by specifying a different timeout for a specific service. However, the rdisp/gui_auto_logout parameter always offers the longest possible timeout value by default, so that the session is terminated in any case when this value is exceeded.

Setting service specific session timeout within transaction SICF:

Navigate within the transaction SICF to the specific service or to a specific service tree, double click to get to the service settings and change the session timeout to any value shorter than the general setting of parameter rdisp/plugin_auto_logout.

Processing /Connection Timeout

It may happen that you get a 'Connection Timed out' page as an answer a long time before your configured session timeout limit is reached. Usually this timeout is raised because of a processing timeout, which happens if you have long running applications.

Connection timeout, <x> displays the current configured processing timeout

The processing timeout period is configured in the ICM component and defines a timeframe in which the called ICF web service, the application, has to return a result page. If the ICM component does not receive a result page from the application within the configured time period, the ICM itself is sending the 'Connection timed out' page to the browser GUI.
The processing timeout time can be configured differently for each server port, using the kernel parameter:

icm/server_port_<nr>

Sample:

icm/server_port_0 = PROT=HTTP, PORT=1080, PROCTIMEOUT=60

This sample setting means, that all HTTP requests received at port 1080 and forwarded to the ICF framework have to return within 60 seconds (this is the default value) otherwise the ICM component will send a 'Connection timed out' page as a response to the browser - the application has 60 seconds time to send a response/result page. If the application needs more time to process the request, the user will see the 'Connection timed out' page instead of the real result page. This processing time out frequently happens, for example, if ABAP sources have to be compiled first.
Setting the PROCTIMEOUT to -1 means the maximum processing time is not checked at all.
The configured processing time can be displayed and changed using transaction SMICM -> Goto -> Services:

The processing timeout value cannot be specified on a per service basis. Configure an additional virtual host if you have the need to set a specific processing timeout value for a group of services.

For more details regarding the ICM timeout settings see SAP Note:
824554  ICM and SAP Web Dispatcher Timeout Parameter

back

How do I setup the SAP Web Dispatcher for high load scenarios?

To generate a profile that can be used with the correct parameter settings for serving high load scenarios, you can start the SAP Web Dispatcher with the -bootstrap option. This option provides a selection for small, medium and large systems and when choosing large system, it will automatically generate a profile that fits for high load scenarios.

Further details can be found here ->

http://help.sap.com/saphelp_nwpi711/helpdata/en/41/23a3e979f846d898e37ad48339dc39/frameset.htm

Despite the SAP Web Dispatcher parameters within the profile, you also have to take care of setting the correct relevant operating system parameters as regards the amount of resources that are required due to the setting of the SAP Web Dispatcher profile (e.g. Semaphores, File handles, Sockets.)

A summary of relevant operating system parameters can be found in the following SAP Notes:

538405 Composite SAP Note: SAP Web Dispatcher

715400 Max. number of memory pipes (MPI) restricted to 4,000

552286 Troubleshooting for the SAP Web Dispatcher

Additional optimization hints :

953784  SAP Web Dispatcher Connection Pooling

943248 SSL fine-tuning (SAPCRYPTOLIB,icman,sapwebdisp)

back

How to configure SAP Web Dispatcher for SSL?

A How-to Guide is available under the following link, which describes in detail how to setup the SAP Web Dispatcher for SSL -->

https://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/60d6de2e-085b-2b10-7a8f-bc9ae1e0bba6

Additional information of how the SAP Web Dispatcher supports SSL and a description of the relevant parameters can be found underhttp://help.sap.com/saphelp_nw70ehp1/helpdata/en/36/fd39eacf4cde4a8fe32d7f29b3db16/frameset.htm

back

What do I have to check when using a Reverse Proxy in my system landscape?

The Reverse Proxy must meet the following requirements to work with SAP systems :

1.) The host header name may not be changed by the application gateway.
The SAP system generates absolute URLs based on the host and port information found in the host header name.

2.) The client protocol may not be changed unless signalled to the SAP server.
The incoming protocol version (HTTP or HTTPS) is also used to construct the URL. If there is a requirement to change the protocol from HTTP to HTTPS or vice versa, then an additional header variable has to be set to indicate the protocol to use for URL generation.
The default header variable used to signal the protocol requested by the client is 'ClientProtocol'. For the SAP NetWeaver JAVA this can be changed by modifying the value ProtocolHeaderName in the HTTP Provider Service.
The header variable used by SAP NetWeaver ABAP cannot be modified.

Parameters which are important when using SAP Web Dispatcher as Reverse Proxy:

1.) If there is a change in protocol in the SAP Web Dispatcher, the application server requires this information, to generate absolute URLs (it can get SAP Web Dispatcher host and port names from the header field Host).

wdisp/add_client_protocol_header

This parameter determines whether the protocol between the browser and SAP Web Dispatcher (HTTP or HTTPS) is notified to the application server.
This information is sent in the header field clientprotocol.

2.) If the client IP address is needed in the backend by the application than you have to activate the following parameter.

wdisp/add_xforwardedfor_header

The parameter determines whether the SAP Web Dispatcher includes the IP address of the client in the header field x-forwarded-for.
If it does, the application on the application server can read the route that the request has taken.
If the parameter has the value false, Web Dispatcher leaves the header field unchanged.

3.) If the SAP Web Dispatcher ports for the configured protocols are needed in the backend by the application than you have to activate the following parameter.

wdisp/handle_webdisp_ap_header

With this parameter the SAP Web Dispatcher notifies the application server of its ports (access points) for the different protocols in an HTTP header.
In the application server the protocol can be switched without any manual configuration (for example, from HTTP to HTTPS), or a redirect can be programmed.

Additional interesting SAP Notes :

929082 Apache as reverse proxy for the SAP Web Application Server

833960 supported Application Gateway Configurations

back

How do I set up my own error pages for web services?

Please kindly read the following text in the SAP help portal.
It describes a procedure, how to maintain own error pages for a specific error in the transaction SICF:

1. http://help.sap.com/
   -> SAP NetWeaver -> SAP NetWeaver 7.0 Library
2. search for pattern "Components of SAP Communication Technology"

Components of SAP Communication Technology
Communication Between ABAP and Non-ABAP Technologies
Internet Communication Framework
Development
Server-Side Development
Creating and Configuring ICF Services
Creating a Service
Setting Up Error Pages

back

How to analyze the distribution of stateless http requests by the SAP Web Dispatcher?

This section will explain how to analyze the requests distribution conducted between the involved servers with Web Admin Interface.
The Web Admin interface is a service provided by Web Dispatcher where you can manage its features. For further information about how to configure and use it follow the SAP documentation below:

http://help.sap.com/saphelp_nw73/helpdata/en/48/80c48a109a1b5ae10000000a42189c/frameset.htm

To check the requests distribution, go to Web Admin Interface and navigate from left menu:

In this window you do find the Application Server List for ABAP and JAVA in distinct tabs. For each Application Server there is a column REQUESTS with statistics about STATELESS and STATEFUL requests.

The Web Dispatcher perform a distributions of requests, it is not able to perform a distribution of the load. If is suffering troubles with the load of a specific Application Server, this is not directly caused by the Web Dispatcher. It balances the stateless requests to ensure an even distribution across the servers. In such way, only the statistics about stateless connections should be balanced equally, you have to see a similar situation between the servers.

Note that stateful request that must be returned to their server, they are not involved in load balancing. The load balance only is done for stateless requests.

The balancing will never achieve a completely balanced distribution, deviations around 10% and 20% are tolerable.

back