Pros and Cons for both BAPI and Call Transaction

BAPI
One of the huge plusses for BAPIs is that the interface and function are not supposed to change. This is a huge 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 simpler to use than others.

You usually need to perform the BAPI that really 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 excellent 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 reckon of a buy order that is sent as an IDoc. If we send the buy order to a supplier then the supplier will store the buy order as a sales order. But, if we send the buy order via ALE to another R/3 system, then the receiving system will store the buy order also as a buy order

Posts Related to Pros and Cons for both BAPI and Call Transaction

IDOC Interview Questions
IDocs and BAPI are very different, so it should be simple to choose between them depending on your requirements. IDOCS Advantages System can work even ...
SAP ABAP BDC , LSMW, Conversions Questions
SAP ABAP BDC , LSMW, Conversions Questions What is BDC ? What is call transaction method ? what is the syntax/procedure? What is session method ...
SAP R-3 ALE implementation methodology
ALE allows the user to perform an SAP transaction in the sending system, after which the following steps occur: · 1 or more communication IDocs ...
How The Data is Stored in Live Cache
In APO how the data is stored in Live cache (ie) in any table structure? In APO transaction data is not stored in tables like ...
ALE Concepts Part 2
ALE Architecture ALE architecture consists of ……….. · Outbound process · Inbound process · Exception handling Outbound processing Step 1 : Identify the need for ...