Application Development and Automation Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 
Read only

Multiple RFC calls

Former Member
2,794

Hello all,

A program is designed to call a BAPI from R/3 system to the other in a loop. We expect about 20000 records getting processed in this loop. We are weighing two options: one is to create a wrapper FM with the BAPI in the target system so that we pass all the 20000 records in one shot and the other is to let it as it is.

Based on the RFC documenation, SAP says that the first time we connect to a target system a RFC channel is established and the same is used for subsequent calls and also that the function group would be loaded in the target system. This will stay until the calling program terminates or the RFC connection is explicitlty closed. This leads us to believe that calling in a loop or calling it in onshot would not make much difference.

When i ran STAD in the target system i saw that the parameters "total memory used" and "extended memory usage" stay constant for the individual RFC calls. But when i group by the business transaction totals, i saw that the extended memory usage was infact getting accumulated for each RFC call. We tested with 20 records, for each call it used about 4mb in the extened memory and it showed about 80mb when we group it by business transactions. For 20000 records this would take as much as 80gb.

We also tried explicitly closing the connection using RFC_CONNECTION_CLOSE after every RFC call. Even then when grouped by business transactions, STAD shows 80 mb being used.

So I would like to know if my analysis on extended memory makes sense. Please share your inputs and correct me if i was wrong anywhere.

Thanks,

Sayee

1 ACCEPTED SOLUTION
Read only

HermannGahm
Product and Topic Expert
Product and Topic Expert
1,595

Hi Sayee,

Regarding memory in STAD: check "Max. ext. mem. in TA (kB)" and /or "Max. ext. mem. in step (kB)" that should give you the peak memory usage for one transaction and / or one step. The "extended memory usage" is the EM consumption after the TA or step. So the peak in TA or step is much more interesting. The sum in the business transaction totals for your sequential (in case of synchronous?) RFC calls in "extended memory usage" is a display error it should be a max as well... .

Regarding performance: Even with opened RFC channel between your calls you will have some overhead for each single call. (e.g. serializing data, transfering data, deserializing data, ... ). The faster your BAPI the more significant this overhead. I would suggest to use the wrapper but not with all data in one shot but with customizable package sizes. That would allows you to play around with different settings (e.g. 20 packages a 1000 items or 200 packages with 100 items and so on... ) and find out the fastest version.

Hope this helps a little bit.

Kind regards,

Hermann

4 REPLIES 4
Read only

HermannGahm
Product and Topic Expert
Product and Topic Expert
1,596

Hi Sayee,

Regarding memory in STAD: check "Max. ext. mem. in TA (kB)" and /or "Max. ext. mem. in step (kB)" that should give you the peak memory usage for one transaction and / or one step. The "extended memory usage" is the EM consumption after the TA or step. So the peak in TA or step is much more interesting. The sum in the business transaction totals for your sequential (in case of synchronous?) RFC calls in "extended memory usage" is a display error it should be a max as well... .

Regarding performance: Even with opened RFC channel between your calls you will have some overhead for each single call. (e.g. serializing data, transfering data, deserializing data, ... ). The faster your BAPI the more significant this overhead. I would suggest to use the wrapper but not with all data in one shot but with customizable package sizes. That would allows you to play around with different settings (e.g. 20 packages a 1000 items or 200 packages with 100 items and so on... ) and find out the fastest version.

Hope this helps a little bit.

Kind regards,

Hermann

Read only

0 Likes
1,595

Thanks for your inputs. So, Calling a wrapper in packets seems to be better.

I'm trying to understand why explicitly closing the connection using RFC_CONNECTION_CLOSE did not have any effect in the extended memory usage.

Anyways I have decided to use a wrapper FM.

Thanks again.

Sayee

Read only

HermannGahm
Product and Topic Expert
Product and Topic Expert
0 Likes
1,595

Hi Sayee,

well, with opened RFC connection your calls are processes in one session:

E.g.

1.) open session 1

2.) 1st RFC call

3.) 2nd RFC call

4.) 3rd RFC call

5.) ...

6.) close session 1

If you close the connection after each call with RFC_CONNECTION_CLOSE it looks like:

1.) open session 1

2.) 1st RFC call

3.) close session 1

4.) open session 2

5.) 2nd RFC call

6.) close session 2

7.) open session 3

8.) 3rd RFC call

9.) close session 3

...

This approach should be slower... depending on the execution time of the RFC call itself (your BAPI) maybe not significantly.

Nevertheless each RFC, regaredless in which scenario is a own ta/step in the target system. Note: If the RFC itself is faster then 500 millisecs. it will be accumulated into one STAD record.

The "extended memory usage" reports the em usage AFTER a ta / step. The "Max. ext. mem. in TA (kB)" and /or "Max. ext. mem. in step (kB)" reports the maximum usage of em IN a transaction or step.

Hope this helps.

Kind regards,

Hermann

Read only

Former Member
0 Likes
1,595

I can't tell you about memory, but I can share a similar experience I had:

I was doing multiple calls to a remote enabled RFC in our SRM system. Each call returned results for a single shopping cart.It took forever. I converted it to do a single call to return all the data. It now runs much more quickly.

Rob