What the difference between an RFC function module and a normal function module?

[Former Member]

Hello,

  could you please tell me what are the differences between an RFC enabled function module and a normal function module?

I know that RFC enabled ones can be called outside SAP, is this the only difference? I mean, is the RFC flag only for hiding some internal function modules from outside world?

thanks and best regards.

Jun

[Former Member]

RFC Function Modules are used for Remote calling of a function module ie from one server to another  were as the normal function modules are used only within the server,

[dirk_feeken]

Yes, but I would desribe it the other way around. The intention of the RFC flag is not to hide internal functions but to enable external calls for public ones.

Dirk

[Former Member]

to the point!

thanks

Jun

[Former Member]

to the point!

thanks

Jun

[Former Member]

the RFC-function-modules have some restrictions, i.e. the IMPORT/EXPORT-parameters must be values - no references are allowes. t hink there are some more restrictions which i cannot remind now.

regards, torsten.

[Former Member]

Another major difference is that RFC FM's cannot pass back exceptions; you need to send back any errors in a structure - typically BAPIRET2.

Regards,

D.

[WolfgangJanzen]

RFC functions can raise exceptions, of course.

You are referring to BAPIs which do not need to be based on remote function calls and therefore should not make use of exceptions.

[Former Member]

Wolfgang's post is correct, however I would like to add some more info.

Function modules are routines with a defined interface, supporting optional parameters and labelled exceptions, intended to perform specific tasks encouraging re-use.

Functions that are remotely callable via SAP's proprietary remote function call (RFC) protocol, have additional technical restrictions, primarily that the parameters cannot be changing and/or passed by reference, as previously mentioned.  When a function module is marked as RFC-enabled, SAP checks that the function's interface meets the restrictions and also generates an internal stub routine to allow the RFC communication to take place (but we don't really need to know anything about that stub).

When a function module raises an exception, control is passed back to the calling program.  When the calling program is an external RFC client, the caller receives only a return code indicating that an application exception was raised and the name of the exception as an upper-case text string. The caller is then responsible for inspecting the exception text to see what kind of error occurred.

BAPI stands for Business API and are implemented as function modules that follow SAP-specified standards.  They do not need to be RFC-enabled, but since the purpose of BAPI's is to expose business functionality internally and externally, then you will find that most are RFC-enabled.

The main standards that BAPI's must implement are:

1) The interface remains static between releases, or at least backwards-compatible.

2) Exceptions are not used, instead outcome information is returned to caller via a special parameter called a RETURN parameter (the structure of which is somewhat standardised, there are a couple of alternatives).  The RETURN parameter provides more information, particularly the SAP message details and text.

3) Database updates are not to be performed directly by a BAPI.  Instead the BAPI is to perform the necessary validations and then queue the updates to be processed by the next COMMIT WORK (usually done by calling a subroutine via syntax PERFORM ... ON COMMIT).

In cases where a single BAPI call processes multiple transactions, it is common for the RETURN information to be passed as a table parameter.

Calling application must remember to invoke the ABAP COMMIT WORK statement.  This can be done externally by calling RFC function module BAPI_TRANSACTION_COMMIT.

This brings me to me biggest pet peave about BAPI's and the RFC protocol.  For some reason that is beyond my understanding of the RFC protocol (upon which many other things such as ABAP to Java and .NET integration are based), is that the end of each function call performs an implicit database commit. This is the reason why BAPI transactions are not allowed to perform database updates directly, because doing so would otherwise prevent chaining multiple BAPI calls into a single unit of work.

However this is really a catch 22 situation, because the problem with the BAPI approach of queueing updates is that chances are the subsequent BAPI call, which I'd like to be part of the same unit of work, will fail because the database updates of the first BAPI call have not been made yet.

Take for example the following scenario (please note that I'm not an SD person):

- Create a customer

- Create a sales order for that customer

This can't be done in a single unit of work, because the call to the "Create Customer" BAPI (whatever that is) will not create the customer in the database (it will just queue it for update) and so the second BAPI call to "Create Sales Order" will fail because the customer number does not exist yet.

To my knowledge, there is no way around this shortcoming.  I'd be interested to know if SAP plan to address this issue in order to achieve better integration between the Java / ABAP personalities of the NetWeaver stack.

Regards,

Scott Barden