SAP System and ALE (AS-ABAP)


The Application Link Enabling (ALE) feature available from SAP Release 3.0 supports the construction and operation of distributed applications. ALE includes a business-controlled message exchange with data consistency supported across loosely coupled SAP applications, as shown in the example at the end of this section.

The basic concept of ALE is to guarantee distributed yet integrated SAP operation. The applications run independently with their own set of data in the distributed environments, as shown in the example. The applications are integrated by synchronous and asynchronous communications rather than by a central database.


The key issue for high availability in an ALE scenario is to make sure that the distributed SAP system applications can recover gracefully from a system failure.

Independent systems imply data redundancy. Therefore, data must be distributed and synchronized across the entire system. The basis for this data exchange is the “Intermediate Document” (IDoc) used in the EDI interface. The IDoc is the data container for the exchange between distributed systems, either between SAP systems or between SAP systems and other types of system. Data is passed on immediately after update by the application or by a batch job.

There are the following types of communication used in the ALE environment:

·        Asynchronous

The asynchronous communication used for data exchange means that the application does not have to wait for a response from the target system. If, for example, the connection fails just before an update, the update can be sent later, controlled independently by the communication layer.

The failed target system cannot receive any messages. Instead, messages destined for the failed target system are stored in queues on the sending system, until the target system is once more able to receive messages.

·        Synchronous

Synchronous communication is only used for information retrieval. In this case, there is no data distribution with update procedures. The synchronous request is performed using a direct function call to the target system. Such data is not exchanged using IDocs.

The graphic below shows two ALE-linked SAP systems. It illustrates how the ALE application programming interface (API) and the remote function call (RFC) software fits into the other components of the SAP system:

ALE: Hardware and Software Layers for High Availability

The upper software layers – application and ALE - API – are protected from disturbances at lower levels of the software hierarchy and also from failures in the hardware layers. For information about high availability at the network level, see Network High Availability.


The following table shows what happens when a failure occurs in either the source or target systems in the above diagram:

Handling of Failures in ALE-linked SAP Systems at the RFC Level



Connection between ALE source and target system

Transactional RFC layer recovers by starting a batch job.

ALE source system application host

Client can log on again and enter new transaction. Refer to “Logon Load Balancing” in Failure Recovery.

ALE target system application host

RFC logon load balancing

Gateway failure

Restarted by dispatcher. See Service Failure.

To find out how to make sure of high availability for other components of ALE-linked SAP systems, see the relevant section of this documentation.


ALE Scenario