Skip to Content

SAP Sourcing 7.0 – Part 01 – Hardware Sizing

Recently I lead a SAP Sourcing 7.0 On Premise Implementation. We started our implementation while the product was still under Ramp-up. Due to this there was lack of product documentation especially on Infrastructure side both on SDN/SMP and SAP help. This made our implementation journey really tough as we were on our own with NO SUPPORT whatsoever. But as they say “Everything happens for good” and it indeed turned out good for us as now I have some insights into the product and know what works well and what not.

So in this blog series I will try and share our experiences in the multiple areas including – Installation and Post Installation, Multi-Tenant Setup, Apache Load Balancer Configuration and few Sourcing Functions.

Lets me start and explain first things first. To start any installation you need to first decide on App Server and DB. We chose:

  • SAP CE 7.1 as our application server primarily because we do not want to use any Non SAP App Server
  • Oracle 11g as our DB since we wanted to use Global Search without configuring TREX reason being that we wanted to save on hardware cost for TREX


Once we decided this we come to a Million $ question. What should be the Size of our Server? This becomes even more crucial in an SAAS environment like ours because you do not want to Oversize the server as your cost increases and do not want to undersize as you have certain performance SLAs to be met. So we looked into SAP Quicksizer only to be disappointed that there is no template for SAP Sourcing yet. So we checked the Sourcing Installation Guide and read that SAP only classifies installation based on number of users.

Below 50 concurrent users – Small Installation, Above 50 concurrent users – Large Installation

For small installation SAP’s recommendation is to have ONE separate server for each of the following – App Server, DB Server, Optimizer and Contract Generation with following config: 

  • Quad-core processor (for example, AMD Opteron 852 / 2.6GHz or equivalent)
  • 16GB RAM, 70GB disk
  • 64-bit server


So if you are using all modules, for 50 concurrent users you will need – 4 x Quad Core and 4 x 16GB. And since for PRD you will look at HA, you will need double this size. To me, this by any means and calculation appears VERY HIGH.

Since we were using SAP CE Server, I did some brainstorming and concluded that I can use the SAP CE Sizing recommendations to start with. I checked through the SAP NW CE Sizing Guide. As per the guide for a customer service scenario the initial sizing guidelines are as follows

CE Sizing Guidelines

This sizing is for SAP Customer Service Care scenario where SAP assumes minimal database utilization. Since SAP Sourcing DB requirements will be high due to the fact that it will be used both by Sourcing Application and CE Server we decided to have a separate DB Server in line with SAP’s recommendation.

As per my experience and discussions with many sizing experts in the past, for system category XS we need Dual Core processor. For RAM we should add 4GB to the values proposed by Quicksizer/guidelines since OS and other processes do consume some memory.

We also had discussion with our Infra Team and were advised that we should take advantage of Virtualization to ensure we can easily Scale Up if required. Our Infra team has done some interesting research (I will try and cover that in separate blog) and concluded that DB should not be virtualized but app server can be virtualized and has many advantages. Although I personally believe that virtualized DB should NOT have any impact on performance, but due to lack of time for conducting more research in this area, I gave into the argument and opted for Physical Server

So based on all this information and after multiple discussions we concluded that for 50 concurrent users we will start with the following:






























App Server






Dual Core






DB Server






Dual Core






Optimizer and Contract Gen Server






Dual Core





It has been 3 months since we went live and we have not faced any resource challenges till now on any of the servers which even strengthens our belief about our sizing approach. Sizing is anyways a progressive exercise, so I will definately update this blog in future if there are any issues we face.

I hope you will find this blog helpful in sizing hardware for your SAP Sourcing Deployment. However since this blog is based on my experience, I would end this blog with following disclaimer:


In this blog I have shared my experience and technique for sizing. You are free NOT to use this at all. However in that case I would really feel obliged if you can share your sizing technique so that all of us can benefit and learn more on this topic


SAP CE Sizing Guidelines

SAP Sourcing Installation Guide

CE Sizing Guidelines
1 Comment
You must be Logged on to comment or reply to a post.
  • Hi,

    Thanks for sharing your experience. My company is going through the RFP process for SAP Sourcing 9.0 implementation. Most of the responses we have received have lacked this rigour you have shown. Companies just pick up install guides and throw numbers at you without thinking whether it makes sense or not.

    The general guidelines, especially found in BuinsessObjects sizing documents, are about differentiating between total users, active users (roughly 10% of total users), and concurrent active users (10% of active users). This criteria helps to size for the actual load on the system.

    The install guide provides sizing for 50 concurrent users (Quad Core, 16GB RAM). From experience, you can deduct (as you have) that this recommendations should be for approx 500 active users, and 5000 total users on a SAP Java system. Of course we need to factor in the variance but the suggested configuration, along with necessary optimization, should be more than enough to cater for thousands of users.

    If we just use the SAP suggested sizing for Sourcing x 4 for all servers x 2 for high availability, you end up having a super-sized system sized equivalent to the full SAP landscape including several applications (ERP, SRM, PI, BW, etc). On top of that, we are looking to configure a dual track landscape. So it is quite important to take a step back and rethink the sizing approach, something you have done.

    Any updates on how your infrastructure is faring under the load for the last year or so?