topic The performance about making an RFC call in LOOP? in Application Development and Automation Discussions

The performance about making an RFC call in LOOP?

Former Member — Mon, 11 Mar 2013 17:28:34 GMT

Hi Abapers,

I have here two SAP systems, X and Y. In X, I need to get the data of system Y. In that case, I have created an RFC function "ZRFC_xxxx" in system Y. The parameters which I would like to import and export are both tables, however, since the TABLE parameter is obsolete, I finally decided to declare a parameter named "a" in IMPORT and a parameter named "b" in EXPORT.

When I called "ZRFC_xxxx" in system X, I am thinking of this :

Questions:

I want to know if this works, the performance of the program would be very bad? Because the RCF has to be called up several times.
Is there any better solutions? Perhaps I could import and export itab without using the declaration "TABLE"?

Regards.

Re: The performance about making an RFC call in LOOP?

edgar_nagasaki — Mon, 11 Mar 2013 20:53:17 GMT

Hi Yi,

I'm affraid EXPORT/IMPORT wouldn't work in your scenario once you have 2 systems involved and therefore it won't share ABAP memory. You could try to use SET/GET PARAMETER instead.

Regarding TABLE parameters to be obsolete, you're right, but it still working fine and I personally still using that.

Regards,

Edgar

Re: The performance about making an RFC call in LOOP?

Former Member — Mon, 11 Mar 2013 21:28:42 GMT

Hello Yi QIU,

To pass tables through your RFC function module import and export parameters,

just use a table type data defintion from the data dictionary.

You can create your own table type definitions.

Also, make sure you select the option 'Pass Value' on the IMPORT/EXPORT tabs, as reference variables are not allowed in RFCs.

For example:

FUNCTION Y_TABLE_TYPES.
*"--------------------------------------------------------------------
*"*"Local Interface:
*" IMPORTING
*"     VALUE(IT_IMPORT) TYPE MARC_TAB
*" EXPORTING
*"     VALUE(ET_EXPORT) TYPE MARC_TT
*"--------------------------------------------------------------------

FIELD-SYMBOLS: <import> LIKE LINE OF it_import,
                                 <export> LIKE LINE OF et_export.

LOOP AT it_import ASSIGNING <import>.
    APPEND INITIAL LINE TO et_export ASSIGNING <export>.
    <export>-matnr = <import>-matnr.
ENDLOOP.
ENDFUNCTION.

Regards,

Kim

Re: The performance about making an RFC call in LOOP?

alex_cook — Tue, 12 Mar 2013 03:02:04 GMT

Howdy,

You can do as suggested and continue to use the TABLES parameter despite being obselete, or you can declare a table type in the data dictionary and use that type in your importing parameter (assuming ECC6).

If you use the table type you will get a warning message about performance - and its worth reading the long text to see if your environment meets the conditions for using basXML.

Cheers

Alex

Re: The performance about making an RFC call in LOOP?

kakshat — Tue, 12 Mar 2013 03:37:13 GMT

Hi Yi,

Doesn't matter if the TABLES parameter is obsolete. You can still use tables in EXPORT and IMPORT parameters of an RFC. So, do away with the loop and pass the tables directly.

Re: The performance about making an RFC call in LOOP?

Former Member — Tue, 12 Mar 2013 03:40:43 GMT

Hi,

Calling the RFC in a loop would result in some serious performance issues depending on the responce time and other related aspects.. Though using TABLES parameter is obsolete, it still works for many RFCs with tables parameter.

Hope this helps.

~Athreya

Re: The performance about making an RFC call in LOOP?

Nawanandana — Tue, 12 Mar 2013 04:17:03 GMT

Hai,

Without doing RFC cant you do the web service, using SOAMANAGER.

Regard,

Nawa

Re: The performance about making an RFC call in LOOP?

Former Member — Tue, 12 Mar 2013 04:49:56 GMT

Hi,

I think you can achieve this requirement by using a table type parameter in the IMPORT/EXPORT parameters.

Regards,

Vijaymadhur.

Re: The performance about making an RFC call in LOOP?

Kartik2 — Tue, 12 Mar 2013 05:15:49 GMT

Dear Yi,

There is one possible thing you can do without using tables interface of function module, that is to use table type and define an importing paramter in your function module. If you do so, system will show a warning message:

Message class : FL

Message Number : 397

Please go through the long text for the mentioned message, certain alternatives ar suggested there. Documentation suggests that tables interface can be used in function modules, to improve performance.

Regards,

Kartik

Re: The performance about making an RFC call in LOOP?

SandySingh — Tue, 12 Mar 2013 07:14:50 GMT

Hi Yi,

Please refer to SDN thread for more information on this issue. Hope it helps.

http://scn.sap.com/thread/1642757

regards

Sandy

Re: The performance about making an RFC call in LOOP?

Former Member — Tue, 12 Mar 2013 13:12:25 GMT

Hi Kim

Thx a lot for your reply. it's very helpful.

so I tried to import a table type parameter, and I used the type T512T which is a transparent table of SAP.

When I debugged the function module, I could only put in one value. It seems to me TYPE_IND is a structure but not a table. Why?

Re: The performance about making an RFC call in LOOP?

Former Member — Tue, 12 Mar 2013 13:19:35 GMT

If the table type parameter that I want to import is just like one transparent table of SAP, could I put directly the transparent table into "Associated Type"?

Re: The performance about making an RFC call in LOOP?

RaymondGiuseppi — Tue, 12 Mar 2013 13:35:36 GMT

T512T is a "Database Table" and not a "Table Type", look for "Table Type" in SE11 under line "Data type" like T512Z_TAB or via SE80.

Regards,

Raymond

Re: The performance about making an RFC call in LOOP?

Former Member — Tue, 12 Mar 2013 13:48:19 GMT

thx!!!!!

Re: The performance about making an RFC call in LOOP?

Former Member — Tue, 12 Mar 2013 14:21:44 GMT

Hi Yi,

If the transparent table is not already defined as a table type (check using 'WHERE USED' function), then you can create a 'Z' table type in SE11 that uses the transparent table as a line type.

Regards,

Kim

Re: The performance about making an RFC call in LOOP?

Former Member — Tue, 12 Mar 2013 14:24:31 GMT

Thank you Kim. really helpful!!!

Regards.

Re: The performance about making an RFC call in LOOP?

edgar_nagasaki — Tue, 12 Mar 2013 16:37:29 GMT

You're welcome too.

Re: The performance about making an RFC call in LOOP?

HermannGahm — Tue, 12 Mar 2013 20:58:53 GMT

Hi,

regarding RFC the following is important:

- Destination

where is the system that you are going to call located and how is it connected to your local calling system? is that a local area network connection or a wide area network connection or something else?

It's all about latency. Run the FM RFC_PING several times to learn about how long a roundtrip (2 x latency is). That amount of time (for a roundtrip) mulitply with the number of calls (lines in loop). Then you have a minimum responsetime without data transfer or processing on the server... .

- Data Volume

how much data is sent and returned by the function module? Only transport what needs to be transport. Pay attention to the fact that TABLES parameter can compress and do deltatransfer which is not possible for EXPORT / IMPORT. However EXPORT / IMPORT is more flexible... For tables you need EXACTLY the same structures on client and server.

One more thing: Why would you close the RFC connection after each call? That would mean you have to do a logon for every call (which of course come on top of your respoonsetime and may add up easily).

Kind regards,

Hermann

Re: The performance about making an RFC call in LOOP?

yuri_ziryukin — Thu, 14 Mar 2013 09:33:13 GMT

Hermann Gahm wrote:
One more thing: Why would you close the RFC connection after each call? That would mean you have to do a logon for every call (which of course come on top of your respoonsetime and may add up easily).
Kind regards,
Hermann

This point from Hermann is VERY important!

Do not close the RFC connection in the loop. Do it AFTER the loop.

Then I can also give you one tip - try to play with the size of the package when you select data.

There are also different ways how gateway communicates with the work process. This may help you to optimize the load on system Y when you extract the data. If the data package is relatively small (I remember something like 70kb, but I am not really sure anymore), then the work process in system Y is not waiting after data extraction until the data is passed to the requester. It gives the data to gateway for passing back and finishes. Otherwise (if more data should be sent back) the work process passes smaller data package to gateway and puts himself into the status like "Wait for RFC" waiting until gateway says that this package is transferred. Then the next smaller package is passed to the gateway and so on.

So I would suggest to try different sizes of data package to see which one is showing better performance.

Next point, you might try to extract the data from the system Y in parallel. You can use aRFC technology and have multiple instances of function ZRFC_xxxx running in system Y in parallel.

Regards,

Yuri