Plain call function versus destination 'none'

[former_member186741]

we have an RFC enabled function module which is being used as an rfc by external calls but is also used within the same sap system as a conventional function mdoule.

Currently the call in the same sap system uses a DESTINATION 'NONE' clause and I have noticed that in the SE30 Runtime analysis there is sometimes an expensive 'WAIT for RFC' against this function module call.

Can I simply remove the DESTINATION 'NONE' clause or is there a good reason for it being there?

Will a call without the clause always be more efficient than one with it or is there no difference?

[former_member156446]

For some RFC enables FM's its mandatory to pass the destination.... if the code executes if you remove the Destination then it should be OK, it would not impact any thing on the performance nor any data from the FM

[former_member186741]

Thanks for your reply but what I want to know is will the performance IMPROVE when I remove the DESTINATION 'NONE' clause.

[former_member156446]

I have never tested it, but it should improve the performance.. bcoz when the FM is called there is not need to make any extra check on the destination, when removed...

[Former Member]

Currently the call in the same sap system uses a DESTINATION 'NONE' clause and I have noticed that in the SE30 Runtime analysis there is sometimes an expensive 'WAIT for RFC' against this function module call.

I wish I had a running SAP system to quickly test this. Did you enable also profiling of RFC calls in SE30? Couldn't the trivial reason just be that the function module takes some time and since it's a synchronous calls the calling program has to wait for it to return?

Can I simply remove the DESTINATION 'NONE' clause or is there a good reason for it being there?

Well, I'd be really careful and first make sure that I understand why somebody put it there. Note that an RFC call is executed in it's own context (e.g. see comments in ABAP online documentation on [RFC destination|http://help.sap.com/abapdocu_70/en/ABENRFC_DESTINATION.htm]), so if that was the reason why the destination 'NONE' was introduced you probably shouldn't change it.

Also, a [synchronous RFC call|http://help.sap.com/abapdocu_70/en/ABAPCALL_FUNCTION_DESTINATION.htm] triggers an implicit database commit. In theory a program shouldn't rely on that, but I've seen my fair share of programs where developers were not aware of some side effects (and actually relied on them).

Or how about a funky setup where your RFC module actually has coding to call the original system back (i.e. usage of RFC destination 'BACK'); so removing the 'NONE' should cause trouble in this case as well...

There's probably lots of other possible traps once you start thinking about it. Most likely they are not relevant, but it definitely helps a lot if you can judge the skill set of the programmer who introduced this possibly unnecessary RFC call...

As far as performance is concerned I doubt that you'd gain much if it's a synchronous RFC (and the function module runs for some time and is not executed tons of times). Note though that RFC calls are limit to some stricter resource management (e.g. they can be controlled via quite a few profile parameters), so your RFC might timeout due to lack of resources, where your direct function call wouldn't do that. But if your RFC does some substantial work I doubt that the overhead for the RFC calls will be measurable.

Cheers, harald

[former_member194613]

You should not remove the DESTINATION 'NONE' !!! First comes functionality and then performance.

The RFC decouples the porcessing, but I think it is a synchronous RFC, so you will always have to wait for the result, either

for the decoupled RFC or for the direct pocessing of the FM. There is not problem with the wait for RFC, only if it is too large.

Check whether the RFC is by itself programmed well, called too often, transferred too large amount of data etc.

Siegfried

[former_member192616]

Hi Neil,

within STAD you can find the RFC sub records. In these you can see the "calling time" and the "remote execution time".

Is there a big difference? If not, proceed with analyzing the "remote execution time" by tracing the execution of the function module.

Kind regards,

Hermann

[former_member186741]

Thankyou Harald, Siegfried and Hermann,

your answers have made me realise that I am way out of my depth here and should leave this well alone!

I did actually remove the parameter and it worked well for my specific use of the fm but the portal began to give some odd results and it was traced back to my very clever 'improvement'. So it was hastily backed out and all is now well again. I would really like to have more time to check out thoroughly exactly why this is a requirement but I doubt that I will be able to. There is no documentation on it at this site and the developer is long gone so it's likely to remain a mystery. I still think it is costing more time than it needs to in my case but it's too difficult to isolate the usage and understand all the other usages.

Thanks.

Neil