ALE supports the configuration and operation of distributed applications. It allows the controlled exchange of business messages between distributed applications with consistent data retention. The coupling between the distributed systems can be either narrow or loose.
Applications are integrated using a local database rather than a central one. Instead, the applications access a local database. There is no data retention. ALE guarantees the distribution and synchronization of master data, Customizing data and transaction data through asynchronous communication. Synchronous communication is used in ALE to read data only.
ALE has many benefits:
Application data can be distributed between different releases of SAP systems
Data can continue to be exchanged after a release upgrade without requiring special maintenance
Customers can add their own enhancements
Communication interfaces enable connections to non-SAP systems.
ALE supplies various services and tools for the communication between distributed application systems:
Options for maintaining a distribution model
Monitoring data transmission
Tools for defining new ALE business processes
Types of Coupling
As mentioned above, the coupling between distributed application systems can be either loose or narrow. A loose coupling is implemented with asynchronous communications and is used for write accesses. A narrow coupling , in contrast, is implemented with synchronous calls, and should only be used for reading data.
Both types of coupling can be implemented by calling BAPIs.
In a distributed environment, it is especially important that the systems be loosely coupled and independent of one another. If the called system is down, or a communication error occurs, the calling system can continue working normally. An example of where a loose coupling is essential is inventory management: If an inventory management component is coupled with an accounting component, then goods movements must also be able to be posted if the accounting component is not available.
Loose coupling means that the individual systems for the most part communicate asynchronously with each other. In this type of communication, messages are exchanged between the systems. The data format used for these messages is called the Intermediate Document (IDoc). IDocs are structured data containers in which the data can be stored hierarchically. For more information on IDocs, refer to the document "ALE Introduction and Administration" under IDoc Interface/ALE .
Different communication technologies can be used to send the IDocs:
For asynchronous communication between two SAP Systems, the underlying communication technology is the transactional remote function call (tRFC). The transactional call is not executed immediately; instead, the data to send is first written to a database table. When a COMMIT WORK is triggered in the calling program, the remote call to the receiver system is executed. If the receiver system is currently unavailable, a periodically scheduled background process tries to send the data to the receiver system again later. tRFC guarantees that the data is transferred once only.
If you want to establish asynchronous communications between SAP Systems and non-SAP systems, you can also use CPI/C, MPSeries, or other communication techniques to transmit the IDocs.
If an error occurs while the IDoc is processed, the invalid IDoc is saved and a workflow is generated that enables the ALE administrator to correct the error. These ALE error-handling routines ensure that the data is updated consistently. As a result, data replication, updates, and inserts of data in other systems should always take place asynchronously. The disadvantage of asynchronous communications via ALE is that only a single return parameter from the called system is available.
Note that asynchronous communication does not always mean a large time delay between call and execution. If the target system is available, an asynchronous call can be performed immediately after the COMMIT WORK in the called system.
During asynchronous communication via BAPIs, the calling system (client) generates an IDoc with data from the BAPI call (instead of the BAPI call itself) and sends it to the called system (server). The BAPI is then called with the data from this IDoc in the called system. For more information, see Implementing Loose Coupling via BAPIs .
In contrast to loose coupling, narrow coupling requires the called system to be available. Narrow coupling is generally implemented using a synchronous call of a remote-capable function module. In contrast to asynchronous communications, the export parameters of the function module can be evaluated. Synchronous calls are suitable for verifying or reading data in other systems. ALE supports synchronous BAPI calls starting in Release 4.0. Synchronous dialog calls are supported starting in Release 4.5A. In this case, the caller of the BAPI function module is automatically logged on to the other system (remote login to the "destination"). The user sees the transaction in the same window, and can navigate through the called system using menus and so on. Synchronous dialog methods are visible in the BOR and are modeled in the ALE distribution model.
Usually, synchronous writing between two databases is not allowed, to ensure that any transmission errors that may occur do not result in database inconsistencies!
For more information, see Implementing Narrow Coupling via BAPIs .
Using the ALE Distribution Model
The ALE distribution model describes the message flow between logical systems. The distribution model defines which messages are exchanged between systems and which BAPIs (starting in Release 4.0) are called.
The transmission can be controlled data-specifically through filters . Filters represent the conditions that message types and BAPIs have to satisfy so that they can be distributed by ALE outbound processing.
A customer uses a centralized inventory management system and several accounting systems. If stocks change in company code 0001, accounting data is sent to accounting system 01; if they change in company code 0002, accounting data is sent to accounting system 02.
You can differentiate between the following types of filters for BAPIs:
You can use receiver filters to define dependencies that affect the permitted recipients between BAPIs or between a BAPI and a message type. For more information on receiver filtering, see the ALE Programming Guide under Determining Receivers for a BAPI .
Data filtering offers two filter services: interface reduction and parameter filtering :
Interface reduction allows field suppression by the BAPI interface, which means that these fields are ignored by the receiver. This can be used to prevent certain fields from being overwritten, for example.
Parameter filtering allows you to control the scope of the dataset for transmission in the BAPI, by filtering out BAPI table parameters that fail to meet the defined conditions. If hierarchical dependencies exist between two table parameters of the BAPI, then additional parameter hierarchies will have to be defined. For further information see the ALE Programming Guide under Defining Hierarchies between BAPI Parameters .
For more information on data filtering, see the ALE Programming Guide under Filtering Data .
To perform receiver determination and parameter filtering, you must create filter objects before you maintain the distribution model. Filter objects consist of a filter object type and an object value. Filter object types for BAPIs correspond to a parameter name during the BAPI call. They check whether a parameter is set to the required object value. The BAPI is only distributed if this is the case.
Interface reduction, in contrast, does not require any filter objects. However, it can only be used for certain types of BAPIs whose interface explicitly supports this type of filtering.
Maintaining the Distribution Model
The ALE distribution model is used to determine the target system for the remote call in both the synchronous and asynchronous cases. The ALE distribution model, which is a component of general IMG customizing, can be reached in the Implementation Guide through path.
To create the required filter object types, first select path. You can then create filter object types for data filtering with path or filter object types for receiver filtering with path .
If you want to test the connection between two systems, you will have to make the following settings while maintaining the distribution model:
Determine the unique client ID and the logical system
Defining the Communication Parameters
Generating Partner Profiles in the Sending System
Distribute the customer model to the receiving systems
Generate the partner agreement in the receiving systems