Basic Concepts of ALE Technology

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.

Loose Coupling

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.

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 .

Narrow Coupling

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.

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.

Filtering

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.

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, see the ALE Programming Guide under Determining Receivers for 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 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  Basis  Application Link Enabling (ALE)  Model and Implement Business Processes  Maintain Distribution Model .

To create the required filter object types, first select path  Tools  ALE  ALE Development  BAPI . You can then create filter object types for data filtering with path  Data Filtering  Maintain Filter Object Type  or filter object types for receiver filtering with path  Receiver Determination  Maintain 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. Defining the Communication Parameters

3. Generating Partner Profiles in the Sending System

4. Distribute the customer model to the receiving systems

5. Generate the partner agreement in the receiving systems