Function Module Vs RFC Function Module

[Former Member]

Hi All!!

I want to know what is the differences between the Function Module and RFC Function Module, apart from the RFC could be called in a Remote way.

Somebody knows if SAP has a compromise of not modifying RFCs on future versions?

I hope the question will be clear enough.

Helpful answers will be rewarded.

Thanks and regards,

Manuel.

[Former Member]

Hi

RFC (Remote Function Call) is similar to the general SAP fun module: except that in the attributes you click the radio button: RFC enabled;

and you will be passing an Import parameter DESTINATION to it.

Other code and usage will be similar to any fun module;

Have a look at any fun module in SE37 to understand better about the different components of Fun modules;

Refer this link:

http://help.sap.com/saphelp_nw04/helpdata/en/22/042518488911d189490000e829fbbd/frameset.htm

check out the following link it might help you

http://help.sap.com/printdocu/core/Print46c/de/data/pdf/BCFESDE2/BCFESDE2.pdf

<b>Reward points for useful Answers</b>

Regards

Anji

[Former Member]

Hi Manuel,

Function modules can be called within SAP.

Using RFC Function modules (BAPI) - External applications can call this function module

Regards

Arun

[Former Member]

Hi

<b>Each BAPI has an equivalent internally named function module so bapi or function module both are same</b>

Here are the differences between RFC and BAPI

1)BAPI are RFC enabled function modules. the difference between RFC and BAPI are business objects. You create business objects and those are then registered in your BOR (Business Object Repository) which can be accessed outside the SAP system by using some other applications (Non-SAP) such as VB or JAVA. in this case u only specify the business object and its method from external system is BAPI there is no direct system call. while RFC's are direct system calls. Some BAPIs provide basic functions and can be used for most SAP business object types. These BAPIs should be implemented the same for all business object types. Standardized BAPIs are easier to use and prevent users having to deal with a number of different BAPIs. Whenever possible, a standardized BAPI must be used in preference to an individual BAPI.

The following standardized BAPIs are provided:

Reading instances of SAP business objects

GetList ( ) With the BAPI GetList you can select a range of object key values, for example, company codes and material numbers.

The BAPI GetList() is a class method.

GetDetail() With the BAPI GetDetail() the details of an instance of a business object type are retrieved and returned to the calling program. The instance is identified via its key. The BAPI GetDetail() is an instance method. BAPIs that can create, change or delete instances of a business object type

The following BAPIs of the same object type have to be programmed so that they can be called several times within one transaction. For example, if, after sales order 1 has been created, a second sales order 2 is created in the same transaction, the second BAPI call must not affect the consistency of the sales order 2. After completing the transaction with a COMMIT WORK, both the orders are saved consistently in the database.

Create( ) and CreateFromData! ( )

The BAPIs Create() and CreateFromData() create an instance of an SAP business object type, for example, a purchase order. These BAPIs are class methods.

Change( )

The BAPI Change() changes an existing instance of an SAP business object type, for example, a purchase order. The BAPI Change () is an instance method.

Delete( ) and Undelete( ) The BAPI Delete() deletes an instance of an SAP business object type from the database or sets a deletion flag.

The BAPI Undelete() removes a deletion flag. These BAPIs are instance methods.

Cancel ( ) Unlike the BAPI Delete(), the BAPI Cancel() cancels an instance of a business object type. The instance to be cancelled remains in the database and an additional instance is created and this is the one that is actually canceled. The Cancel() BAPI is an instance method.

Add<subobject> ( ) and Remove<subobject> ( ) The BAPI Add<subobject> adds a subobject to an existing object inst! ance and the BAPI and Remove<subobject> removes a subobject from an object instance. These BAPIs are instance methods.

2) It is not possible to connect SAP to Non-SAP systems to retrieve data using RFC alone. RFC can acces the SAP from outside only through BAPI and same is for vice versa access.

For more info.

Check this URL

http://www.sap-img.com/abap/interview-question-on-bapi-rfc-abap-objects-tables.htm

Reward all helpfull answers

Regards

Pavan

[Former Member]

The future stability and availability of SAP function modules between releases does not differ between RFC and non-RFC function modules, but on whether the module is marked as released or not. Go to the attributes tab and the status is at the bottom of the general data section. Released function modules should be upward compatible.

For the differences between RFC and non-RFC function modules there are additional limitations applied to the definition of IMPORT/EXPORT parameters on RFC modules.

Regards,

Nick

[Former Member]

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.

Regards