‎2010 Mar 24 4:10 PM
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
‎2010 Mar 24 4:32 PM
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
‎2010 Mar 24 4:22 PM
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
‎2010 Mar 24 4:32 PM
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
‎2010 Mar 24 4:43 PM
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
‎2010 Mar 25 6:17 AM
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 - <b>b</b>inary <b>A</b>BAP <b>s</b>erialization XML (see also [here|http://help.sap.com/saphelp_nwmobile71/helpdata/en/45/06bffa57240484e10000000a155369/frameset.htm] and the ABAP documentation link above).
Cheers, harald
‎2010 Mar 25 9:20 AM
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
‎2010 Mar 24 5:36 PM
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