Skip to Content
author's profile photo Former Member
Former Member

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


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.


Add a comment
10|10000 characters needed characters exceeded

Related questions

2 Answers

  • Posted on Oct 28, 2003 at 12:19 PM

    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.


    Add a comment
    10|10000 characters needed characters exceeded

    • Former Member Wolfgang Janzen

      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.


      Scott Barden

  • author's profile photo Former Member
    Former Member
    Posted on May 25, 2013 at 05:54 AM

    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,

    Add a comment
    10|10000 characters needed characters exceeded

Before answering

You should only submit an answer when you are proposing a solution to the poster's problem. If you want the poster to clarify the question or provide more information, please leave a comment instead, requesting additional details. When answering, please include specifics, such as step-by-step instructions, context for the solution, and links to useful resources. Also, please make sure that you answer complies with our Rules of Engagement.
You must be Logged in to submit an answer.

Up to 10 attachments (including images) can be used with a maximum of 1.0 MB each and 10.5 MB total.