Skip to Content

So you have an ICF service developed in ABAP system (eg. ECC) or using a standard one (eg. CRM_UI), the question remains how do I call it from the browser such that my request can actually go to multiple application servers and the system load be balanced. Well, there are multiple ways to slice this onion. Question is does standard ABAP based SAP system have any solution to offer? Let’s find that out.

Concept:

The concept is pretty smple here. An ABAP system performs load balancing using logon groups (defined in SMLG). A logon group contains multiple application servers / dialog instances.

LogonGroups.png

Let’s say a user tries to login through a logon pad entry that is defined based using group/server selection (and not by custom application server) as the connection type. The login request first goes to the message server and depending upon the Logon Group provided the message server checks the performance of each application server in the specified logon group. It then assigns one application server with best quality and that’s how a user is now associated with that application server. However, that was a TCP/IP request. How does it work for HTTP requests? Well, it is the exact same concept.

We know that the HTTP (and SMTP) functionality is provided by the ICM framework from the Netweaver / WebAS. So, like there are typical port numbers for TCP/IP communication with the SAP system (eg. 32nn, 36nn, etc where nn is the instance number of the SAP system), we have HTTP (and SMTP) ports as well to the order of 80nn (a.k.a. ICM port). Therefore logically each application server can be accessed from the browser using the link _http://<server name>.<domain>:<icm port>/<service path>/<service name>. This works perfectly fine if the intention is to get to that specific application server over and over again (… until the system is over-loaded and crashes!!).

EndUserRequestToNetweaver.png

Solution:

Let’s expand on the same concept above where the user was coming in through the SAP Logon Pad using a Logon group. In this case, we need a way to have a connection to the HTTP port of the message server. How do I find that?

Logon to the ABAP system (ECC, CRM, etc) and from the transaction SMMS –> menu –> Goto –> Services you can find the HTTP port of the message server. Now you need to modify your URL from the above as – _http://<message server host>.<domain>:<ms http port>/<service path>/<service name>. As soon as you enter this URL in your browser, you will find the page is redirected to an application server with its ICM port. Hurray! you now have an idea how you can load balance HTTP requests coming into the ABAP based SAP system.

The solution isn’t complete there though! If you have multiple logon groups and you are serious about balancing load between set of servers instead of across all application servers, how do you use the appropriate logon group for a particular webdynpro service?

In order to do that, you need to assign the logon group of your choice to the service in question. You can assign that in the transaction SICF –> search for your service –> under Service Data tab –> choose the appropriate logon group in the field Load Balancing. Once you setup the right logon group to the service and desired application servers to the logon group, you have your ABAP webdynpro service “load balanced”.

LoadBalancingMSServer.png

Conclusion:

With logon groups (SMLG), assignment of logon groups to the ABAP webdynpro services (SICF) and the right URL (_http://<message server host>.<domain>:<ms http port>/<service path>/<service name>) we can achieve load balancing natively within the ABAP based SAP systems. This does not mean you should not or cannot use load balancing components such as SAP web dispatcher or any other hardware load balancer. This just indicates that there is functionality available in standard ABAP stack and ICM framework.

For the JAVA based SAP systems such as Portal, we still need a load balancing component outside of the system such as SAP Web dispatcher or hardware load balancers such as CSS, F5, etc.

Additional References:

SAP Documentation – http://help.sap.com/saphelp_nwpi711/helpdata/en/47/c5935087b62d66e10000000a42189c/content.htm

OSS Notes:

1040325 – HTTP load balancing: Message Server or Web Dispatcher?

1225587 – WebDynpro ABAP with Loadbalancing in the Enterprise Portal

654982 – URL requirements due to Internet standards

945516 – Web Dynpro ABAP in a portal environment

To report this post you need to login first.

4 Comments

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

  1. Michelle Crapo
    We are just getting into Web Dynpro applications – more than a couple.  We need all the information on load balancing that we can get.

    Thank you for the information!

    Michelle

    (0) 
    1. Pise Mangesh Post author
      You’re welcome. We tested this kind of configuration with a lots of concurrent users (>500) and the system was doing a good job load balancing the requests and we could see that in SM50 and SMLG in the backend system. There is still an option to discuss whether a h/w load balancer or SAP Web dispatcher is more suitable depending upon the use case(s).
      (0) 
  2. Jonathan Wilson
    Hi Mangesh,

    Thanks for a very clear and well written blog, although I would like to highlight that there are limitations in this approach.

    While it is possible to perform HTTP load balancing via the message server as described, due to the use of HTTP redirects, there are a number of scenarios where this approach will not work.

    These are highlighted in the Additional References you have provided, specifically Note 1040325.  To avoid these issues, the recommendation from SAP (which I support) is to always use the Web Dispatcher (or equivalent) for HTTP load balancing.

    Cheers,
    Jon

    (0) 
    1. Pise Mangesh Post author
      Thanks for calling that out specifically. I agree and therefore one has to still make sure all the due dilligence is done. For example whether the ABAP webdynpro is statefull or stateless, accessed directly or via portal, load expected, etc. While the focus of the blog was to indicate that mechanisms in the ICM framework of the ABAP stack exist natively. However to leave the reader with additional research material, I did also provide additional references.
      Thanks for your feedback, though, again.
      (0) 

Leave a Reply