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.
The application integration is not achieved through a centralized database. Instead, the applications access a local database. Data retention is redundant. ALE ensures the distribution and synchronization of master, control, and transaction data through asynchronous communications. ALE uses synchronous connections to read data.
The use of ALE offers a number of advantages:
· Distribution of application data between SAP Systems with different releases
· After an upgrade, data exchange can continue without any further adjustment
· Customer-specific enhancements
· The integration of non-SAP systems through communication interfaces
ALE supplies various services and tools for the communication between distributed application systems:
· Options for maintaining a distribution model
· Consistency checks
· Monitoring data transmission
· Error Handling
· Synchronization tools
· Tools for defining new ALE business processes
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. One example in which a loose coupling is essential is inventory management: When an inventory management component is combined with an accounting component, it must be possible to post goods movements even when the accounting component is unavailable.
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 IDocs.
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. The tRFC guarantees that the data is only transmitted once.
· 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.
Please 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, please refer to Implementing Loose Coupling with 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, please refer to Implementing Narrow Coupling with BAPIs.
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 are conditions that message types and BAPIs have to meet in order to 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:
1. Receiver Filtering
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, please refer to the ALE Programming Guide under Determining the Receiver of a BAPI.
2. Data Filtering
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 when this condition is met.
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.
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 Basis ® Application Link Enabling (ALE) ® Model and Implement Business Processes ® Maintain Distribution Model.
To create the necessary filter object types, choose the path Tools -> ALE -> ALE-Development -> BAPI from the SAP menu. Finally you can create filter object types for filtering data by choosing the path Data filtering -> Maintain filter object type or filter object types for filtering receivers, by selecting Receiver determinations -> Define filter object type.
If you want to test the connection between two systems, you will have to make the following settings while maintaining the distribution model:
1. Determine the unique client ID and the logical system
2. Determine the technical communication parameter
3. Generate the partner agreements in the sending system
4. Distribute the customer model to the receiving systems
5. Generate the partner agreement in the receiving systems
R/3 Release 99A will include an ALE customizing tool that will help customers to maintain the ALE distribution model. For this, the customers will be provided with so-called templates, which can be found in the SAP menu under the path Tools -> ALE -> ALE-Development -> Business processes -> Maintain templates. A template contains a description of an ALE standard scenario based on message types/BAPIs and filter objects. Customers can use the templates, which are designed by the developer of the respective ALE standard scenario, to generate basic entries in the ALE distribution model based on their customer-specific data.
For more information on maintaining the distribution model and the filter objects, refer to document “ALE Introduction and Administration” under Modeling Distribution.