What is SAP-ALE-BAPI-IDOC?

ALE
ALE is SAP proprietary technology that enables data communications between two or more SAP R/3
systems and/or R/3 and external systems. When a new enterprise resource planning (ERP) solution such
as R/3 is implemented, companies have to interface the ERP system with legacy systems or other ERP
systems.
ALE provides intelligent mechanisms where by clients can achieve integration as well as distribution of
applications and data.
ALE technology facilitates rapid application prototyping and application interface development, thus
reducing implementation time.
The ALE components are inherently integrated with SAP applications and are robust, leading to a highly
reliable system.
ALE comes with application distribution/integration scenarios as well as a set of tools, programs, data
definitions, and methodologies that you can easily configure to get an interface up and running.
BAPI
BAPIs provide a stable, standardized method for third-party applications and components to integrate into
the Business Framework. These interfaces are being specified as part of SAP's initiative with customers,
partners and leading standards organizations. Also, SAP has implemented the emerging Object
Application Group (OAG) specifications with BAPIs.
Pros and Cons for both BAPI and Call Transaction
BAPI
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 protocols 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, DE and ALE are typical use cases for
IDocs. R/3 uses IDocs for both DE 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 DE and ALE can be pinned as follows: If we send data to an
external partner, we generally speak of DE, 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.