The performance about making an RFC call in LOOP?

[Former Member]

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:

1. 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.
2. Is there any better solutions? Perhaps I could import and export itab without using the declaration "TABLE"?

Regards.

Yi

[edgar_nagasaki]

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

[edgar_nagasaki]

You're welcome too.

[Former Member]

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

[Former Member]

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?

[RaymondGiuseppi]

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

[Former Member]

thx!!!!!

Yi

[alex_cook]

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

[Former Member]

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"?

[Former Member]

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

[Former Member]

Thank you Kim. really helpful!!!

Regards.

Yi

[kakshat]

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.

[Former Member]

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

[Nawanandana]

Hai,

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

Regard,

Nawa

[Former Member]

Hi,

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

Regards,

Vijaymadhur.

[Kartik2]

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

[SandySingh]

Hi Yi,

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

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

regards

Sandy

[HermannGahm]

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

[yuri_ziryukin]

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