Advantage BAPI over RFC

[former_member194669]

Hi,

I like know the difference between BAPI over RFC. I know this question answered several times thru this forum. But still i have not clear about the advantage BAPI over RFc.

All RFC-enabled function modules can be accessed from the outside, irrespective of whether it is a standard BAPI, a user-defined BAPI or a "normal" RFC function module.

I like to know what will be the real advantage to create custom BAPI instead of RFC function module. I know the BAPI will create a BOR. in that case what will be the advantage of an BOR over RFC call. I neither see a technical nor a business advantage having a user-defined BAPI instead of a normal RFC function module.

Anybody please give some info over BAPI over RFC.

Thanks for your replies.

aRs

[former_member194669]

Hi,

I like know the difference between BAPI over RFC. I know this question answered several times thru this forum. But still i have not clear about the advantage BAPI over RFc.

All RFC-enabled function modules can be accessed from the outside, irrespective of whether it is a standard BAPI, a user-defined BAPI or a "normal" RFC function module.

I like to know what will be the real advantage to create custom BAPI instead of RFC function module. I know the BAPI will create a BOR. in that case what will be the advantage of an BOR over RFC call. I neither see a technical nor a business advantage having a user-defined BAPI instead of a normal RFC function module.

Anybody please give some info over BAPI over RFC.

Thanks for your replies.

aRs

[Former Member]

Hi,

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. in BAPI there is no direct system call. While RFC are direct system call 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 advantage of using BAPIs over using RFCs is that using BAPIs requires no ABAP programming knowledge. You use BAPIs from standard programming languages such as C++ and Java. *

Check these links too..

http://help.sap.com/saphelp_46c/helpdata/de/cf/8ccab761ea11d2804a00c04fada2a1/content.htm

Hope it is useful.

Regards,

Kumar

Message was edited by:

kumar kk

[uwe_schieferstein]

Hello aRs

<u><b>SAP standard</b></u> BAPIs have the advantage that their interface is supposed to be quite <b>stable</b> (downward compatibility for several releases). Furthermore, they are more scrupulous in <b>validating</b> the incoming data than normal RFC function modules.

Is there any reason why one should favour customer BAPIs over normal RFC function modules? Having about 8 years of ABAP development experience I have not encountered any good reason why a customer should bother to create customer BAPIs instead of simple RFC function modules.

From an economical point of view it takes about 2-3 times longer to create a BAPI compared to a simple RFC function module yet the customer get the very same functionality but has to pay twice the price.

My (personal) conclusion: forget about customer BAPIs.

Regards

Uwe

[former_member194669]

Hi Uwe,

I preferred to go along with your suggestion. not to go for BAPI.

From Kumar's reply i have not understand the following point.

<i>*The advantage of using BAPIs over using RFCs is that using BAPIs requires no ABAP programming knowledge. You use BAPIs from standard programming languages such as C++ and Java. *

</i>

Points given

Thanks

aRs

[uwe_schieferstein]

Hello aRs

If using BAPIs does not need any ABAP knowledge then using RFC function modules does not need either.

Well, I do not really agree with this statement. In both cases you need to know how to call a BAPI=RFC-function module from other languages such as Java, VB etc.

There is one important point that I have forgotten to mention:

- Standard BAPI usually do not execute <b>COMMIT WORK</b>. Thus, if a BAPI call was successful it must be followed by calling BAPI_TRANSACTION_COMMIT (in case of failure use BAPI_TRANSACTION_ROLLBACK)

- a normal RFC function module may or may not execute COMMIT WORK

Regards

Uwe

[uwe_schieferstein]

Hello aRs

Final comment: if I can choose between a <b>SAP standard</b> BAPI and a normal (RFC) function module for the same functionality I will (almost) always prefer the BAPI over the normal function module for the reasons mentioned above.

Regards

Uwe

[Former Member]

HI,

Yes, BAPIs are more stricter in rules while developing them, and hence take twice the time compared to developing RFC FM.

for example, all the BAPI interface paramters should be well defined in data dictionary, otherwise you cannot register it as an API method to a Business Object, unike in RFC Function modules you can use native data types like C, String etc ...

Thanks,

Venkat.