RFC vs BAPI
1. BAPI stands for Business Application Programming Interface. It is a library of functions that are released to the public as an interface into an existing SAP system from an external system.RFC is the protocol used to call functions in an R/3 system by a caller external to R/3 or to call programs external to R/3 from an R/3 system.
2. Functions can only be called via RFC if they are tagged as RFC functions in the SAP development workbench. They are then called RFC function modules. BAPIs are complete sets of (BAPI) function modules that model a business application. When you are familiar with web developments: RFC can be compared to HTTP and BAPIs are CGI applications. In other words: A BAPI function is a function module that can be called remotely using the RFC technology.
3. An RFC (Remote Function Call), describes an external interface to a system function module available in SAP. For example, getting the system parameters is a system function available via RFC.
A BAPI (Business Application Programming Interface), is an RFC-enabled function module that provides external access to an SAP business application such as creating a sales order.
In effect, all BAPIs are RFCs, but there is a superset of RFCs that are not considered BAPIs. Two sides of the same coin.
4. 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, you only specify the business object and its method from the external system in BAPI there is no direct system call. While RFC are immediate system call, Some BAPIs provide essential functions and can be used for most SAP business object types. These BAPIs should be implemented the same for all business object types. Standardised BAPIs are easier to use and prevent users from having to deal with several different BAPIs. Whenever possible, a standardised BAPI must be used in preference to an individual BAPI.
The following standardised BAPIs are provided:
Reading instances of SAP business objects
GetList ( ) With the BAPI GetList you can select a range of fundamental object 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 examples of a business object type.
The following BAPIs of the same object type has to be programmed so that they can be called several times within one transaction. For example, if, after-sales order one has been created, a second sales order two 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.
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 withdrawn. The Cancel() BAPI is an instance method.
Add ( ) and Remove ( ) The BAPI Add, adds a subobject to an existing object inst! Ance and the BAPI and Remove removes a subobject from an object instance. These BAPIs are instance methods.
5. It is not possible to connect SAP to Non-SAP systems to retrieve data using RFC alone. RFC can access the SAP from outside only through BAPI, and same is for vice versa access.
6. Each BAPI Object has Interface, Key Fields, Attributes, Methods and Events.
Bapi Function Modules can be attached to these BAPI Objects. Function module has a single bound functionality while a BAPI object can contain many features.
There are many differences between IDOCs and BAPIs.
BAPIs in 3.1 are synchronous; in 4.+ they can be asynchronous (and I believe they then drive certain ALE/IDOCs).
BAPIs are called from the outside-in. That is, an external program invokes a BAPI that gets data from SAP to display or updates data in SAP.
The BAPI concept does not include an event concept -- you cannot tell SAP that when certain events happen to a "business object", to fire a message or a file to an external system.
BAPIs are invokable from Java or C/C++ or Visual Basic (and I think some people are using Delphi).
In 3.1x there are very few BAPIs to use. In 4.+ SAP has added a large number. BAPIs are not totally immune to upgrades but if they are to be retired you supposedly will have them supported for two releases.
Whether those are point or letter releases, I don't know. I believe that IDOCs may be more changable from release to release. BAPIs are reasonably well documented and there is a common place to look to see what is available. IDOCs -- I have heard -- are poorly documented in terms of finding them, and IDOCs were done differently by different groups in SAP. BTW, you can also use Java, C/C++, Visual Basic, ... to invoke RFCs in SAP and get or update data. That's how the BAPIs work since they utimately are sets of RFC calls (written to a design spec for BAPIs).
Hope I haven't misstated any of the details.