SAP ABAP : RFC and BAPI

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

• BAPI are RFC enabled function modules. and BAPI are business object. you create a business object and then store this to your BOR (business object Repository).
• BAPIs are provided to outside world so they can interact with SAP from non SAP system like JAVA etc.
• in case of BAPI there is no direct system call from external system although in case of RFC it is a direct system call,
• RFC cannot get or store data from/to SAP alone, to do this we must use BAPI,
• RFC is a protocol used by SAP for remote communication.

========================================================================

Function module  

Difference between RFC and BAPI: 

=> BAPIs are RFC enabled function module. BAPI stands for business application programming interface. 

=> A BAPI is a function module which can be called remotely using RFC technology. 

=> BAPIs are function modules stored in a repository and released for public use. 

=> RFC is a methodology or protocol to used to call a function in R/3 system from a system external to R/3 and vice versa. 

=> RFC are the function modules which can be written by "programmers" for their particular requirement, these don't come as "package" as in case of BAPIs where they are already available readily. 

Types of RFC: 

=> Synchronous RFC: RFC call require both the systems to be available at time of the call. calling system wait for the called system to complete its execution before going further to the execution. 

=>Asynchronous RFC:  

The called function must be present during the call. 

Function control returns to the calling program directly after the call. 

The parameters of asynchronous RFCs are not logged to the database, but sent directly to the server. 

Asynchronous RFCs allow the user to carry on an interactive dialog with the remote system. 

When the caller starts an aRFC, the called server must be available to accept the request. 

The calling program can receive results from the asynchronous RFC. 

Using aRFC is always a good idea when real-time communication is established with a remote system, where processing in the calling program should not be interrupted until the results of the called function module have been obtained (the term asynchronous is used in this sense here). 

=> Transactional RFC:  

The remote system need not be available at the time when the RFC client program is executing a tRFC. The tRFC component stores the called RFC function, together with the corresponding data, in the SAP database under a unique transaction ID (TID ). 

If a call is sent, and the receiving system is down, the call remains in the local queue until a later time. The calling dialog program can proceed without waiting to see whether or not the remote call was successful. If the receiving system does not become active within a certain amount of time, the call is scheduled to run in batch. 

Disadvantage : tRFC uses LUW to process all the request if target system is not available. so we cannot guarantee that all the request should be executed in the same sequence as they are called from the calling system. Many LUW much heavy process. 

=> Queued RFC:  

To guarantee that multiple LUWs are processed in the order specified by the application, tRFC can be serialized using queues (inbound and outbound queues). This type of RFC is called queued RFC (qRFC). 

qRFC is therefore an extension of tRFC. It transfers an LUW (transaction) only if it has no predecessors (based on the sequence defined in different application programs) in the participating queues. 

Implementation of qRFC is recommended if you want to guarantee that several transactions are processed in a predefined order. 

=> Background RFC: 

bgRFC is the successor to tRFC and qRFC, with significant improvements in terms of performance and functionality. 

========================================================================