Skip to Content

My blog is based on past experience while designing technical architecture for some of my clients, who has concurrent users more than 50 and/or language packages installed more than 7.

In this blog I have shown all possible options for load balancing and how do sizing for Sourcing 5.1/CLM2.0 Also I have included Advantages and dis-advantages of each options so that it willl be helpfull for architect to decide which is best suitable option for their client landscape 

Sizing:  The sizing guidelines are based on a simplistic sizing model for a small and large installation. For the purpose of this sizing guide, when the number of concurrent SAP E-Sourcing users remains less than 50, it is considered a small installation and when the number of concurrent users exceeds 50, it is considered a large installation.

For small installation you would not need any load balancing as SAP sourcing single instance can handle till 50 concurrent users. But for most of the installation concurrent users exceeds 50.

Simple formula for Sizing:

No of instances required = [(total no. of concurrent user/50) + 1]

E-Sourcing Disk, RAM and CPU size can remain same or little higher as per guide

  • Dual 2.8 GHz Pentium Xeon, 2MB cache or Dual 1GHz UltraSparc IIIi or equivalent
  • 8GB RAM, 70GB Disk

Database size: Initial

  • Dual 2.8 GHz Pentium Xeon, 2MB cache or Dual 1GHz UltraSparc IIIi or equivalent
  • 8GB RAM, 300GB Disk (Disk size can be increased according to data growth in application)

Sourcing Load Balancing: E-Sourcing implements a basic clustering scheme for application scaling and load balancing. A cluster is a logical group of SAP® E-Sourcing services. Clusters are primarily used to define how end users access the E-Sourcing application. For example, you might configure one cluster for purchasers and another for suppliers. These two groups normally use different hosts and authentication methods.

Load Balancing Options:

Option 1: Multiple Java SID with multiple E-Sourcing instances (as per sizing guide)

  • Disadvantage/Risk
    • Have to install/manage multiple Java and E-sourcing servers.
    • Possibility of E-sourcing application data mismatch.
    • After Go-live support will be tough job.
  • Advantages
    • High availability of E-sourcing server (if one Java SID goes down other one can take charge)
    • 50+ concurrent user can login

Option 2:  One Java SID, multiple Java server node and single E-Sourcing instance (as per sizing guide)

  • Disadvantage/Risk
    • Use same java memory for every server node so load will be on single hardware. Over all memory will remain same on hardware.
    • Hardware bottleneck
  • Advantages
    • 50+ concurrent user can login

Option 3: One Java SID, multiple Java dialog Instances (every instance will have at least one server node) and single E-Sourcing instance.

  • Disadvantage
    • No High Availability of E-Sourcing server
  • Advantages
    • 50+ concurrent user can login
    • Load will be distributed to various dialog instances

Option 4: Two E-Sourcing, 2 Java SID with multiple dialog instances

  • Disadvantage/Risk
    • Have to install/manage at least 2 E-Sourcing and two Java central instances.
  • Advantages
    • 50+ concurrent user can login
    • Load will be distributed to various instances
    • High availability of E-sourcing server

Note: Please share if anyone has used any other method for load balancing in E-Sourcing.

Happy Reading…. 🙂

~Ankush Mittal


To report this post you need to login first.


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

  1. S T
    Hello Ankush,

    Thanks for summarizing the options. I have following queries

    Option 1 – If we use this option, we will need to install multiple e-Sourcing Servers. How does database consistency can be achieved?

    Option 3 – In this option how can we achieve single sourcing instance? Since we will be installing sourcing on every PAS and AAS?

    Option 4 – In this option if we install how can database be in sync?

    If you can let me know your thoughts on the same that will be of great help.

    S Tripathi

  2. Uday Reddy
    Hi Ankush

    Regarding Option 2, i don’t think its true. For Esourcing application with optimizer multiple server nodes are not supported.

    Please let me know if you have implemented esourcing solution with multiple server nodes (with connecting to optimizer)




Leave a Reply