Skip to Content


Over the last few months we went live with a Global Available-To-Promise (ATP) project, moving application logic for back order processing from our SAP R/3 transaction system to a new Supply Chain Management (SCM) system. In my capacity planning role, I helped size the SCM landscape, and have also consulted on performance tuning in the R/3 system over the last few years, and recently in the SCM system.

We have seen that sales order management is a significant portion of the total R/3 workload, and expected that moving the processing from R/3 to SCM would free up resources on the R/3 side. Adding SCM hardware and software is a significant investment, so measuring the workload impact is an important task for infrastructure management.

While we’ve only been live for a couple months, more projects are in the pipeline, as well as possible version upgrades (both R/3 and SCM), so we needed to do a delta sizing exercise. I got advice from Bill Adams of SAP, and spoke to our hardware partner, at Tech Ed in Las Vegas. I also spoke to Frank Lukens from SAP about scalability and performance of Live Cache.

While Quick Sizer should generate capacity requirement for SCM, no one had a good method to measure what load SCM is causing in R/3.

Detailed Analytic Process

I spend a lot of time poring over ST03, the Workload report, or Workload Monitor.  Here are screen shots showing how I got to the base data for this analysis.

When ST03 is first started, it shows the Administrator view:




Switching modes from Administrator to Expert gives this view, now titled Workload Monitor: 




Drilling down by time shows Days, Weeks and Months. I’ll look at the month of October here:




The top section will show the period on the left, and start/end times on the right (cropped off here).

Switching the view from ALV grid to Excel spreadsheet is an easy way to move the useful data into the analysis tool. 


This gives us the “total” workload in the system, although it is reported by category such as Background, Dialog and RFC.

Now, on to the external system portion.


Switch to a different Analysis View by clicking on Load From External System. The period should remain the same as before unless you navigate elsewhere in the meantime.




Once again, switch the display view to Excel in order to copy the relevant data. 



We now have total workload and external workload.

I’ll gloss over spreadsheet mechanics to show the final product.


Task Type Number of Steps T RESP – CALC Ø Response Time (ms) T CPU – CALC Ø CPU Time T DB – CALC Ø DB Time (ms)
ALE 148 142 956.1 5 36.2 69 468.6
AutoABAP 13,769 15,005 1,089.80 7,897 573.5 1,655 120.2
Background 230,936 192,139 832 44,247 191.6 75,170 325.5
Batch Input 1,629 579 355.2 175 107.5 244 149.7
Buffer synchr. 44,348 284 6.4 9 0.2 200 4.5
Dialog 360,830 165,116 457.6 47,305 131.1 47,305 131.1
HTTP 37 143 3,878.10 3 88.6 71 1,922.20
Others 141,122 1,496 10.6 268 1.9 635 4.5
RFC 111,788 76,418 683.6 13,582 121.5 29,613 264.9
Spool 267 936 3,504.50 11 41.1 45 169.3
Update 152,500 8,632 56.6 3,096 20.3 3,416 22.4
Update2 25,053 3,104 123.9 466 18.6 624 24.9
* TOTALS * 1,082,427 463,993   117,064   159,046  

System ID Number of Steps T Response Time (s) Ø Response Time (ms) T CPU Time (s) Ø CPU Time (ms) T Database Time (s) Ø DB Time (ms)
SCD 59,987 25,864 431.2 3,688 61.5 6,724 112.1
Calculations 5.5% 5.6%   3.2%   4.2%  




External RFC load > 5% of total time (development)

External RFC load about 1/3 of all RFCs.

In production, we’ve seen SCM load up to 10% of the total CPU in R/3.


Next steps

Compare R/3 total load before and after ATP go live.

To report this post you need to login first.

Be the first to leave a comment

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

Leave a Reply