Types of RFC connections
The first version of RFC is synchronous RFC (sRFC). This type of RFC executes the function call based on synchronous communication, which means that the systems involved must both be available at the time the call is made.Transactional RFC (tRFC)
Transactional RFC (tRFC, also originally known as asynchronous RFC) is an asynchronous communication method that executes the called function module in the RFC server only once. 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).Queued RFC (qRFC)
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 (in reference to 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.
When is RFC connection closed ?
How call-back mechanism used in RFC calls?
If u are using RFC and passing values to a remote system how does it work ?
Where system logs the remote call request in DB tables?
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, or 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, or 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 are a superset of RFCs that are not considered BAPIs. Really, 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 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 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.
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 ( ) 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 acces 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 functionalities
What is the main difference between BAPI and RFC and difference between BAPI and BDC?
BAPI is used only when it is available for the particular transaction like Delivery Sales order. but BDC can be used for any
transaction which have screen and fields.
BAPI is directly updated the database instead BDC run through the screen flow.
So BAPI can’t handle all the flow logic checking and enhancement put by programmer to faciliate the user requirement.
Difference between BAPI and BDC:
BAPI is a higher end usage for tranfering the data from SAP to non-SAP and vice-versa. for ex: if we are using VB application,where in that we want to connect to SAP and retireve the data,and then change and update the data in SAP for that purpose we can use that.
Apart from that, we can also use it for Uploading/Downloading the data from SAP to Non-SAP like BDC, provided we have an existing BAPI for that.
BAPI function modules will also do all the checks required for data integrity like Transactions for BDC.
There is one more advantage using BAPI instead of BDC. When we go for upgradation, there might be pozzibility to change the screen elements for transactions depending on the requirement. In that case,our BDC pgm may or may not work (depending on the screen changes they have made). Unless and until we prepare new BDC we cant use the old BDC pgm. But in BAPI, SAP promises that they are going to keep the old BAPI and for new functionality they will provide an upgraded BAPI. Until we write a new BAPI pgm, we can use the exisitng BAPI pgm.
What is the difference between the normal function module and BAPI function
A BAPI is remotely enabled function module ie it can be invoked from remote programs like standalone JAVA programs, web interface etc..
You can make your function module remotely enabled in attributes of Function module but
A BAPI are standard SAP function modules provided by SAP for remote access. Also they are part of Businees Objest Repository(BOR).
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.
Pros and Cons for both BAPI and Call Transaction
One of the big plusses for BAPIs is that the interface and function are not supposed to change. This is a big plus when you do upgrades or hot packs because the transaction can change (format, required inputs etc) which means you then need to update the call transaction.
Some of the BAPIs are better documented and easier to use than others.
You usually need to perform the BAPI that actually does the COMMIT after you call your BAPI.
The Program coding for calling a BAPI is usually cleaner than setting up the screen flow etc for the Call Transaction.
You don’t need to worry about special data circumstances interrupting the normal data flow of the screens and causing errors because of that.
BAPIs probably have better performance since they don’t do the screen flow processing.
In general if the BAPI exists for the transaction you want to perform and you can figure out how to use it the BAPI is probably the best way to go.
This is just from my experience working with both BAPI and Call Transaction. I have had some very good successes with BAPIs, but very occasionally found that I could not get the BAPI to perform the update I needed.
The interface concept of the classic R/3 is based on two different strategies: Remote Function Calls (RFC) and data exchange through IDoc message documents. RFC makes direct and synchronous calls of a program in the remote system. If the caller is an external program it will call an RFC-enabled function in R/3 and if the calling program is the R/3 system it will call an
RFC-function in another R/3-system or it will call a non-R/3 program through a gateway-proxy (usually rfcexec.exe). BAPIs are a subset of the RFC-enabled function modules, especially designed as Application Programming Interface (API) to the SAP business object, or in other words: are function modules officially released by SAP to be called from external programs.
IDocs are text encoded documents with a rigid structure that are used to exchange data between R/3 and a foreign system. Instead of calling a program in the destination system directly, the data is first packed into an IDoc and then sent to the receiving system, where it is analyzed and properly processed. Therefore an IDoc data exchange is always an
asynchronous process. The significant difference between simple RFC-calls and IDoc data exchange is the fact, that every action performed on IDocs are protocolled by R/3 and IDocs can be reprocessed if an error occurred in one of the message steps.
While IDocs have to be understood as a data exchange protocol, EDI and ALE are typical use cases for IDocs. R/3 uses IDocs for both EDI and ALE to deliver data to the receiving system. ALE is basically the scheduling mechanism that defines when and between which partners and what kind of data will be exchanged on a regular or event triggered basis. Such a set-up is called an ALE-scenario.
The philosophical difference between EDI and ALE can be pinned as follows: If we send data to an external partner, we generally speak of EDI, while ALE is a mechanism to reliable replicate data between trusting systems to store a redundant copy of the IDoc data. The difference is made clear, when we think of a purchase order that is sent as an IDoc. If we send the purchase order to a supplier then the supplier will store the purchase order as a sales order. However, if we send the purchase order via ALE to another R/3 system, then the receiving system will store the purchase order also as a purchase order.
Commiting a BAPI
You should explicitly commit a BAPI using function module
CALL FUNCTION ‘BAPI_TRANSACTION_COMMIT’
wait = ‘X’.
* RETURN = RET2.
What’s the difference between COMMIT WORK and BAPI_ TRANSACTION _COMMIT
Commit work is used when you code directly in ABAP and make changes in the database and want to commit the database.
BAPI_TRANSACTION_COMMIT is used when you make changes to the SAP database by calling a BAPI from outside SAP and want to commit the database. When you use a BAPI, you can not directly use commit work, instead you are allowed to use only BAPI_TRANSACTION_COMMIT.
I would sasy the difference lies more in the way u want to call Commit Work.
With BAPI_TRANSACTION_COMMIT ..the external systems have a way of deciding on whether to Commit or to Roll back Changes.
But with Commit Work u have to code it inside ure BAPI and the outside systems then have no chance or have any hold over the commit…
so i guess the diff lies more in the way how u want to call commit ,either from outside or from within ure BAPI. You can use both…
SAP though recommends using BAPI_Transaction_Commit and not using Commit_work in the BAPI…
But its upto u and your middleware guy to decide how u want to do it..