Skip to Content

SAP NetWeaver Landscape for Idiots

SAP landscapes seem to be  very complex and therefore developers aren’t especially fond of going into details about them. I’ll try to explain in this weblog how the whole system builds up and why these parts are needed.
First of all, there is one component we call a server. This is where all our software runs (and we’re not discussing here why this makes sense). Despite the fact that after even the install of a developer version (that has only one server) there are more parts, those actually would not be needed. Actually, if you know the right port number you are even able to access this server and work with it directly.

More Servers

This situation changes immediately once we put a second server into this environment, that is configured exactly the same way as the first one.   Basically this is done to gain performance and again we are not caring why this is the case. From this point on we have two servers on a single machine (which in turn could be called a server), it is a good idea to call these server nodes. Once we have two (or more) server nodes a problem occurs that we did not have before: Which server should a client connect to?
To solve this problem there are several solutions, out of which we choose this one: another component is introduced, named a dispatcher. This component is dispatching requests between the client and the server nodes. The dispatcher’s job has several tasks. One is load balancing. We don’t want to go into the details here, just assume the dispatcher forwards requests to server nodes one after another.

Dispatcher specials

But this is not all. Unfortunately we have to take into consideration that in the same session of one user this user may come back to the server node several times with requests. For the dispatcher this is not a problem as long as it would be for example a web server that is handling static web sites. In that case it does not matter on which server node each of the subsequent requests of one session would end up as the answer always would be an HTML page that is the same on all server nodes.
But in a second case we are running a program that is answering the request and any subsequent request could depend on its predecessor’s data. We call this context and therefore we need to handle all requests that are coming in for the same session to be forwarded to the same server node to find its session context again. This is simply done by putting a session tag into the request, so the dispatcher knows which server node is running this session.

Java or ABAP

So far  we did not look into any specialty of ABAP or Java  part of  Web AS. As you might know, you can run application servers that are purely ABAP or Java, or you could run them together. The description of the landscape so far  applies to both. In case you have an integrated system also called full blown NetWeaver server, there are  two of the constructs we have described so far, one ABAP, one Java.
Again we have a dispatching challenge here, but a different one than before. We need to distinguish where any request that is coming in should go. That is easy to decide for the Internet Communication Manager (ICM), due to the fact that every request carries that information in the calling URI. In addition, the ICM has some web server functionality to prevent you from always going down to the application server level just for pumping through graphics.

More Machines

Until now we were speaking about a single host system (despite the fact that you style=”font-style: italic;”>could install the already described stuff also on different machinery). Building a system that has more than one host brings up some more tasks. First of all there is the challenge for any client of such a system to find out where all those machines are located. Out of all possible solutions,  it has been found that it is a good idea to have one single component that takes care of this. This component is called the message server.

The Central Unit

The message server plays style=”font-style: italic;”>the central role in a software cluster (That is a bunch of machines running all the same software to serve more  clients then one system could). Unfortunately, when we would go into the details (which we will not do here), we would find out that the different systems in the cluster need to talk to each other to keep the system consistent. The message server not only knows where all the machines are, but also takes the role of the message distributor. If it would not be there, any communication in the cluster would have to be done directly between all servers. Once your cluster starts to grow, this means an explosion in communication efforts (the formula is something with a square sign in – Oh, style=”font-style: italic;”>you want to know it? It’s a good excercise and I kindly ask you to find out and put it into the comments of this weblog!)

NOTE:Note that there are several definitions for cluster. This could mean at least three different things:

  1. software cluster is a mechanism that makes a bunch of application servers react as if they where a single system.
  2. hardware cluster is a  hardware system that connects machinery in a way so one system can take over if  another system breaks down. This is also called switchover system
  3.  database cluster is a way to distribute a database system.

The message server keeps cluster communication straight and serves signals that need to be broadcasted to all servers from a single place (There are exceptions, like the one that a message server can allow servers to open a direct connection for larger messages, but that again is a detail).
Now we are set. This is basically what you need to set up a complete distributed system (at least as long as it is from SAP). One thing  to add:

Dispatching again

If you followed accurately you may have a question at this point: Don’t we have a dispatching problem again when using different machines? Or is the message server the dispatcher for a cluster? Yes and no. When using SAPGui, the system actually is using the message server as a dispatcher by calling a list of servers from it and chosing one of them to connect to. But when using the web there are more requirements, like SSL handling and actual forwarding of requests. This is done by a new piece of software, the Web Dispatcher. The Web Dispatcher is again doing dispatching like we had it before and a couple of more things. Most important is that it has its own process and because of that can sit in between the firewalls of your web system, in the so called Demilitarized Zone (DMZ).  If there would be no Web Dispatcher you would have to expose one of the other pieces of the system into the DMZ and that is not a real secure area to be in.
Actually I’m lying: there are alternatives for the Web Dispatcher, like reverse proxies (parts of web servers) or hardware load balancers. The difference is that those parts have not built in capabilities to read all the information from a message server (remember? Where are all my servers!) And you had to configure that for those parts (and changes too!). Though, they are not really alternatives.

I guess this is pretty much it. Any questions anybody?


To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Benny Schaich-Lebek Post author
    Just added the rest of the article, as it was cut behind some awkward HTML. mmmmh. Maybe I should keep that in mind: the comment area was not available also!


  2. Anonymous
    So,when the responses are returned to the client, is webdispatcher (in an ssl configuration) “acting” as a reverse proxy or does the web AS and/or portal server send the message out directly to the client?  (assume no 3rd party reverse proxy in the mix).
    1. Benny Schaich-Lebek Post author
      Exactly. Everything else would be security risk due to  exposing ip numbers to the outside of the firewall and allowing the server to directly communicate through the complete firewall.

      And, BTW a client does not accept an answer for a http request from another ip adress then it send it to.


      1. Dagfinn Parnas
        Not sure about how to use in NetWeaver, but you could use loopback network adapters which allows one server in a cluster to respond with the cluster ip-address instead of its own. This can help performance since everything don’t need to pass through the reverse proxy (although for security you should probably do it when communicating from the internet)
  3. Gideon Lenz
    Hi, please correct me if i am wrong, but isnt the formula for communication processes like this.

    number of bidirectional communication processes x.

    if n is the numer of machines:

    f(x) = (n² – n) / 2

    3 systems:

    9 – 3 / 2

    = 3 mappings

    1 communicates with 2 and 3
    2 communicates with 1 and 3
    3 communicates with 2 and 1


    4 systems:
    (16 – 4) / 2 = 6

    5 systems:
    (25 – 5) / 2 = 10

    6 systems:
    (36 – 6) / 2 = 15

    10 Systems:
    (100 – 10) / 2 = 45

    20 Systems:
    (400 – 20) / 2 = 190

    now imagine you are invited to a big party and everyone wants to say goodbye to everyone at the end of the evening.

    let s assume there are 100 guests

    numer of hand shaking processes:

    x = ((100 * 100) – 100) / 2
    x = 9900 / 2
    = 4450

    as mentioned before, correct me if i am wrong but i think this may be the formula.


  4. Raul Herrero
    Thank you Benny.

    Can you talk about the difference between high-availability (performance) and reliability (redundancy). For instance, I have 10 windows hosts to work with; Should I have 1 web-dispatcher (single point of failure), 1 central instance (single point of failure)  and 9 clustered app servers (homogenous or heterogeneous)?

    Or should I have 2 dispatchers (fail-over mode), 2 central instances (fail-over mode) and 6 clustered app servers (homogenous or heterogeneous)?

    I believe that the latter would provide a good mix between performance and redundancy.

    What do you think?

    1. Benny Schaich-Lebek Post author
      Hi Raul,

      this is planned to be one of my next weblogs. But I also can answer your question, of course:
      First of all, I have a problem with your definition of high availability having to do with performance. Running a HA environment helps nothing for your performance. On the other hand, software cluster systems that primarily support your performance *do* have impact on your HA (Because systems are redundant).
      As long as you do not have a switchover environment for your spof, it will not be secure in case of system failure of those spof, meaning you would get a failure of the complete system.

      So, the question to answer for you is: Can you afford system downtime or not? Your switchover systems won’t help you for performance, as they are in idle mode as long as they wait for switchover!



Leave a Reply