topic Re: RFC function TABLES parameter vs. IMPORTING table type parameters in Application Development and Automation Discussions

RFC function TABLES parameter vs. IMPORTING table type parameters

Clemenss — Wed, 24 Mar 2010 16:10:18 GMT

HI,

I hope you can shed light on this:

RFC-enabled Function modules allow VALUE parameters only because you can not pass references to memory areas between separate systems. OK, thats what we know.

If I create an IMPORT (export or changing) parameter of type table (using a table type), I get a warning that this may reduce the performance.

The detailed explanation recommends to make this a TABLES parameter. TABLES parameters do not have the option to be reference or value parameters. I think this means they are always passed by reference - which is not possible using RFC.

Implicitly, RFC must use value transfer.

But why should this be more performant if I pass the values as a TABLES parameter?

TIA and regards,

Clemens

Re: RFC function TABLES parameter vs. IMPORTING table type parameters

Former Member — Wed, 24 Mar 2010 16:22:30 GMT

Hi Clemens Li

For import table from an rfc FM , use the TABLE parameter...il will not give problem..

I always used in that way

Best rgards

Marco

Re: RFC function TABLES parameter vs. IMPORTING table type parameters

kesavadas_thekkillath — Wed, 24 Mar 2010 16:32:01 GMT

yeah ,

you are right ?

Tables are obsolete too.

Even i got the same information message related to performance, but i skipped it and continued.

Even im waiting for a good answer

Re: RFC function TABLES parameter vs. IMPORTING table type parameters

Clemenss — Wed, 24 Mar 2010 16:43:12 GMT

seriously spoken, I did not expect anything except the given answers that do not match my question.

But I still have a small amount of hope that will get more information. Just as an add-on to the question: Deep tables are strictly not allowed as TABLES parameters for RFC functions, making them importing, changin or exporting will cause the warning (warning not information message as falsely stated).

I think there is some kind of a technical reason for this. Any technical RFC knowledge around?

Regards,

Clemens

Re: RFC function TABLES parameter vs. IMPORTING table type parameters

ThomasZloch — Wed, 24 Mar 2010 17:36:59 GMT

I moving this to "ABAP performance" as we have some matter experts there that don't look into the other ABAP forums much, I believe.

Thomas

Re: RFC function TABLES parameter vs. IMPORTING table type parameters

Former Member — Thu, 25 Mar 2010 06:17:21 GMT

Hi Clemens,

This check was introduced via suport package SAPKB64004 (see OSS note [736660 - RFC: Implementing performance checks in transaction SE37|https://service.sap.com/sap/support/notes/736660]).

The problem is that a different encoding has to be used for deep structures, the so-called xRFC. See the ABAP documentation on the [RFC protocol|http://help.sap.com/abapdocu_70/en/ABENRFC_PROTOCOL.htm]:


<ul STYLE="list-style-type: circle">
<li>An internal binary format is used for flat parameters and when TABLES parameters are used.</li>
<li>An XML format described as xRFC is used for deep parameters.</li>
</ul>

So the XML encoding used for xRFC is not as efficient as the binary format. Long term though, the used encoding will probably be basXML - binary ABAP serialization XML (see also [here|http://help.sap.com/saphelp_nwmobile71/helpdata/en/45/06bffa57240484e10000000a155369/frameset.htm] and the ABAP documentation link above).

Cheers, harald

Re: RFC function TABLES parameter vs. IMPORTING table type parameters

HermannGahm — Thu, 25 Mar 2010 09:20:07 GMT

Hi Clemens,

as Harald already mentioned there are differences in the used protocol.

In <= 7.01 we have xrfc (used for deep structures) or a binary protocoll (used for TABLES).

The xrfc needs serialization and is slower as the binary protocoll.

In >=7.02 (EhP2) we have additonally the basxml which is faster as the xrfc but not as fast as the binary protocoll yet.

Another difference is that the TABLES parameter can use "delta handling" where only changed lines will

be sent back. Not sure if this is or will be available in basxml...

Generally speaking: if basxml is available it should be used.

Kind regards,

Hermann