Skip to Content

Archived discussions are read-only. Learn more about SAP Q&A

Unusual Web Dispatcher design

I'm implementing someone else's design and it is to my eyes a pretty unusual one. We have a standalone Web Dispatcher (742, on Windows 2008 R2) sitting in a DMZ of sorts (though the traffic does still go through firewalls), let's call it WD1. Routing is set up such that web traffic to a certain domain/URL ends up pointed to this Web Dispatcher (in actual fact it is two standalone instances, not clustered - hardware load balancers point the traffic to either one). So far, so normal. However, we then pass the traffic to another standalone WD (again 742, Windows 2008 R2, let's call it WD2) in a different subnet (behind another firewall). WD2 is clustered (MSCS), and follows a set of rules to pass traffic to specific backend SAP systems in the same subnet. Where this gets particularly complicated is that those SAP systems are not really the "backend" but rather consist of a Portal (where most of the traffic naturally goes) and some AAS instances of the true backend systems, (the PAS and central instances of which are then themselves on another subnet behind another firewall).

I'm aware of the concept of multiple levels of separation (just read the wikipedia page on DMZs and you'll see the concept of CMZs), but I've never seen it implemented like this in the SAP world.

A sample access scenario is described below:

End user -> Browser -> routing ends up at WD1 in subnet1 -> points to WD2 in subnet2 -> points to various SAP systems in subnet2 based on URL path after domain -> SAP systems communicate with their backends in subnet3 to produce a response -> return response to WD2 -> returns response to WD1 -> returns response to Browser

My questions:

  1. Has anyone seen a similar set up, and can they comment on how well it worked (in terms of ease-of-configuration, maintainability and performance)?
  2. If you have seen this in operation, generally speaking, what is the best division of responsibilities between the two WDs? Should one act as a reverse proxy (we do have the typical requirement of the URL appearing consistent and "clean" to the end users), while the other acts as the brains of the operation, redirecting appropriately?
  3. A specific issue we've seen here is that we're using the parameter wdisp/system_X to point traffic to the appropriate system. I've seen mention in the documentation at times that this parameter is no longer recommended for use, but no alternative is proposed. Is this still the correct parameter for pointing traffic via one WD to multiple SAP systems?
  4. wdisp/system_X only allows us to redirect to the message server of the destination application (using parameters MS[S]HOST and MS[S]PORT). This is to allow the WD to understand the metadata of the application, but in our design we cannot directly contact the message server of the backend systems. There is also the option to use the parameter SILOC instead to specify the metadata in a flat file. Has anyone had any success with this parameter?
  5. Given that we will ultimately need to have end-to-end SSL from the WD1 and WD2 point of view (we only switch to plain HTTP on subnet3), do we need to configure session stickiness on the hardware load balancers pointing to WD1 instance #1 and #2? I think so but said I'd throw it in here as well!

Linking two Web Dispatchers as proposed would be known as a "Web Dispatcher Cascade", and it is discussed at the SAP note 740234.

This is not a common setup.

The most common setup would be the WD1 connecting directly to the systems at subnet2.

1 View this answer in context

Helpful Answer

Not what you were looking for? View more on this topic or Ask a question