SAP Network Blog: ABAP on Steroids: practical use of parallel processing

http://weblogs.sdn.sap.com/pub/wlg/26775?utm_source=feedburner&ut...

Blogs

ABAP on Steroids: practical use of parallel processing

Trond Stroemme Business Card Company: Statoil/Bouvet Posted on Oct. 07, 2011 04:16 AM in ABAP

Subscribe Print Permalink Share

Intro
Parallel processing is not a new concept, but one that is regularly overlooked when it comes to increasing ABAP performance. Why? Your SAP system will (normally) have more than one process available at any given time. Still, most of us insist on using just one of them. This is a bit like a manufacturer relying on only one truck to bring the products from his plant to the shopping malls, when there's a whole fleet of trucks just standing by! Not only that, but most SAP systems spans more than one application server, each with a range of (hopefully) available processes. So, what are we waiting for?

OK, so my program takes forever to execute. How can I put it on steroids?

In this blog, I'll show a practical example for dealing with one of the dreaded father-and-son relations in the wonderful world of SAP FI: Accounting documents, tables BKPF-BSEG. Prowling your way through these tables can really take its toll, both on the system itself and your patience. Not to mention that of the customer breathing down your neck. There are numerous other blogs and papers about parallel processing using RFC's on SDN, and one of the best (if not the best) is Thorsten Franz' blog Calling Function Modules in Parallel Universes. I actually suggest you start there for some very interesting background info on the merits (and pitfalls) of using RFC's. There's also a link to Horst Keller's blog series and the official SAP documentation. In addition, the excellent book "ABAP Cookbook" from SAP Press (by James Wood) outlines the principles of using asynchronous RFCs for parallel processing (as well as providing loads of other cool stuff for enhancing your ABAP skill set!) A highly recommended read. Using asynchronous RFC's without caution is not recommended, and you risk bogging down the system as well as running into errors that can be difficult to resolve. However, if you do decide to use parallel processing, the following might be a good starting point. I'll try to keep things simple and explain every step along the way.

The sample program

We'll create a program to display info from BKPF/BSEG. The program will read all entries from BKPF (feel free to introduce your own selection criteria here, such as company code and/or fiscal year), and then retrieve all related entries from BSEG. This second step will be done by calling a function module via RFC, repeatedly, in parallel. We will try to balance the workload based on the number of documents in the tables, and the available processes on our SAP application servers. Finally, we will examine the runtime analysis of the program and compare to a standard single process execution. The test program basically consists of the following steps: Read relevant entries from BKPF - accounting document headers Call function module SPBT_INITIALIZE to find out how many available processes we can use Split the number of documents into handy packages and call an RFC a number of times in parallel Wait for the results from the called RFC's and merge them all back into the final report The program is fairly straightforward. It reads BKPF, tries to split the retrieved BKPF entries into nice "packages" based on the key fields BUKRS and GJAHR. These are the two main parameters for our RFC-enabled function module - we're building range tables for them in order to facilitate our work. The idea is to pass these two as ranges to the RFC-enabled function reading BSEG, so that the number of documents passed to each call of the function is more or less consistent. Since the number of financial documents will vary with company codes and fiscal years, we cannot ensure a 100% even workload, but this is just an example. Based on the available resources (number of processes for all application servers, which we find using function SPBT_INITIALIZE), we then start to kick off calls to the RFC-enabled function module. This is done a number of times in parallel, using the CALL FUNCTION STARTING NEW TASK... PERFORMING ... ON END OF TASK. By using this feature, we ensure that the calling program executes a specific form whenever the control is passed back from the RFC "bubble" to the calling program (common sense states you should use object orientation, and thus specify a method, but for our example I find the classical procedural program better for illustration purposes).

1 of 6

07/10/2011 17.56

SAP Network Blog: ABAP on Steroids: practical use of parallel processing

http://weblogs.sdn.sap.com/pub/wlg/26775?utm_source=feedburner&ut...

What happens when the aRFC finishes, is the following: Control is passed back to the calling program The form (or method) specified in the CALL TRANSACTION statement (addition PERFORMING ... ON END OF TASK) is called. This form enables you to retrieve any returning or exporting parameters from the called RFC, and use them in the main processing.

By splitting the workload into sizeable chunks, we can execute a multitude of workloads simultaneously, thereby reducing the total execution time to a fraction of the time traditionally used. In my example, I was able to run this report in less than 5% of the time it took running it in one single process. The program and function module are presented below. I've done my best to insert comments in order to explain what's going on, and hope you can use this as a template. The function module has been created as an RFC function (check the Remote-Enabled Module box on the Attributes tab). Besides this, there's nothing special about it.

The function module interface and it's structures

(The below import parameters IM_BUKRS and IM_GJAHR are range tables, thst's to say they contain the fields SIGN, OPTION, LOW and HIGH. See ABAP help for RANGE in order to get info on range tables)

2 of 6

07/10/2011 17.56

SAP Network Blog: ABAP on Steroids: practical use of parallel processing

http://weblogs.sdn.sap.com/pub/wlg/26775?utm_source=feedburner&ut...

Checking the system load

During program run, you can check your RFC's with transaction SM66, which shows all processes across the application servers of your system.

Final word: run time analysis

Try using the run time analysis on the program, both when selecting parallel mode and when un-checking P_PARA (which causes a normal select within the main program). The runtime analysis won't show the additional load of the RFC modules running in parallel, but the total program execution time is far lower - and this, after all, is the main point of splitting a workload into separate parallel tasks. Running in sequential mode (no parallel RFC's):

3 of 6

07/10/2011 17.56

SAP Network Blog: ABAP on Steroids: practical use of parallel processing

http://weblogs.sdn.sap.com/pub/wlg/26775?utm_source=feedburner&ut...

Running in parallel mode:

As you can see, the run time is dramatically reduced. Total system load may amount to the same (and should actually be slightly higher, with the overhead of the separate RFC's), but it's the total execution time that counts. Here, the execution time is roughly 10% when using asynchronous RFC's as compared to a classical "one-in-all" process. The above tests were run in a system with approximately 35.000 entries in BKPF, and 100.000 in BSEG.

Words of warning (again)

A few words on transactional RFC's: There are situations when you cannot use this technique. Commits cannot be performed inside an RFC this would conflict with the session in which the main program is running. You can find more info on these topics by checking SAp help for RFC programming. However, for the larger part of processor-intensive developments, it is a technique that is sadly overlooked. I recommend everyone to give it a try, provided they follow the guidelines provided by SAP on the topic.

Additional reading:
In addition to the blogs and resources mentioned at the start, the following is worth checking out: Horst Keller: Application Server, what Application Server?

Trond Stroemme

is a seasoned ABAP development consultant with more than 15 years experience

Did you try it? What's your experiences? Do you have additional insights? Anything unclear? Let me know! Comment on this weblog Showing messages 1 through 3 of 3. Titles Only Main Topics Oldest First

Nice reminder and I love examples with pictures!

4 of 6

07/10/2011 17.56

SAP Network Blog: ABAP on Steroids: practical use of parallel processing

http://weblogs.sdn.sap.com/pub/wlg/26775?utm_source=feedburner&ut...

2011-10-07 05:15:23 Michelle Crapo Business Card [Reply] <Sigh> Our basis people tend to frown on using all their App Servers on one program. Although it might be fun to bug them a little, we rely on them too much. That's why I haven't tried this. Do you have any ideas on that? Maybe it's OK to do this, when the program is a fast one. But that's the purpose right? Your program is long running.

Thanks for the answers to my questions - they may be found in the other blogs that I will get to shortly!

Michelle Nice reminder and I love examples with pictures! 2011-10-07 05:31:35 Trond Stroemme Business Card [Reply] Hi, I believe a decent approach would be to maximize the number of sessions to 3-5, based on the available number of sessions in the system. If you look at the program code, it investigates the number of free sessions by calling function SPBT_INITIALIZE, which provides max number of sessions and free sessions.

I would advice - as a general principle - to limit your development to using 25% of the free sessions, but this is dependent on other factors as well, such as whether the development is run during high system loads (daytime, lots of users logged in, and so on...) Obviously, running during low-load periods would allow you to eat more free processes!

By using SPBT_INITIALIZE and setting the limit well below the number of free/max sessions, I think you should end up being on the safe side. And, of course, this technique should be limited to the (hopefully very few) developments that really are both demanding on resources and mission-critical in terms of run time.

Discussing and establishing a framework for these kinds of developments with Basis beforehand is anyway a good idea!

Cheers, Trond Nice reminder and I love examples with pictures! 2011-10-07 05:40:50 Michelle Crapo Business Card [Reply] Excellent! I'll have to try it. I WILL talk with BASIS first. They are my friends. Especially when I break something in the system. What I say? It happens sometimes. They weren't real happy we did Web Dynpro before letting them know. And you'd have to talk with a BASIS person to know exactly why that was. I sort of remembered the answer I got. Thank you for the nice blog! (And comment)

Michelle

Showing messages 1 through 3 of 3.

5 of 6

07/10/2011 17.56

SAP Network Blog: ABAP on Steroids: practical use of parallel processing

http://weblogs.sdn.sap.com/pub/wlg/26775?utm_source=feedburner&ut...

6 of 6

07/10/2011 17.56