1.0 Introduction
Enterprises are increasingly looking to deliver real business benefits by integrating their systems and processes both within their organizations and between organizations. ng processes in this way, which requires tight integration, frequent communication and data exchange.
Highly integrated and inter-dependent SAP and non-SAP systems require frequent communication, tight integration and (usually) high levels of data exchange. In order to achieve this interoperability, SAP has come up with the concept of ALE (Application Linking and Enabling).
The idea behind ALE is to provide a more rigid integration service while allowing a high degree of independence to the individual SAP com
ge of business information across SAP and non-SAP systems. Applications are integrated by using synchronous and asynchronous communication without implementing a central database.
We will cover subjects such as:
Data Distribution Model
ALE process
IDOCS
Converters
Configuring ALE
Other concepts
2.0 ALE Data Distribution Model
One of the challenges in designing distributed applications is the data distribution model, which consists of all participating systems and the messages to be exchanged by the system. Data distribution in R/3 to R/3 environment is easily achieved but there are several bottlenecks in R/3 to non-R/3 scenarios – for example data mapping - as non-R/3 systems seldom have as rich an organizational representation as R/3 has. The following figure illustrates the concept of data distribution using ALE.
Image Source: http://help.sap.com
Enterprise business objects of a SAP system are distributed with the help of BAPIs (Business Application Programming Interfaces). ALE acts as a layer that incorporates the inter-linking of business objects at the application level. The ALE layer provides the following services:
- Applications services: this layer provides ALE with an interface (for instance: BAPI) to R/3 to facilitate data exchange to or from external R/3 systems.
- Distribution services: the onus of filtering and converting messages exchanged between SAP and non-SAP systems is on the distribution layer of ALE. This service is the core service and acts as a sandwich layer between application and communication layers.
- Communications services: ALE supports synchronous as well asynchronous communication. Synchronous messaging is used for the direct reading of control data, while asynchronous messaging is used for transmitting or receiving application data.
The implementation of ALE is achieved with the help of external converters (ALE converters), which connect SAP applications to non-SAP applications. In simple words, external converters are generic-format conversion programs, which contain specific converter functions. The capabilities of the external converter will be discussed later in this article.
ALE has three prime entities, which participate in the message exchange process:
- SAP R/3 system
- ALE converter (inclusive of its sub-components)
- External non SAP R/3 system
The following diagram describes how these three work together in an ALE scenario.
Figure 2: ALE FUNCTIONALITY
Image Source: http://help.sap.com
2.1 Concept of Logical Systems (LS):
Logical Systems represent R/3 or external systems in the SAP R/3 environment for the distribution of data. The existence of LS is mandatory for the corresponding R/3 client (which uses ALE or EDI). This LS acts as the "sender" for outbound messages and a "receiver" for inbound messages.
In addition to the base LS, another LS must be present within that R/3 system for each R/3 or external system used for ALE interfaces. In an inbound ALE interface, second LS represent the sender (another R/3 or external system) with respect to the base LS (receiver). In an outbound ALE interface, this second LS is the receiver on behalf of the R/3 or external system with respect to the base LS (sender).
2.2 Message Type:
Message types (required for sending the data across participating systems) relate to the structure of the data called an IDOC (Intermediate Document). Message types provide the format of the data, which can be exchanged between SAP and non-SAP systems. ALE supports over 200 message types in R/3.2.3 IDocs:
IDocs (Intermediate Documents) are the crux of ALE. These are the documents with the help of which data is exchanged between SAP R/3 and non-R/3 systems. As the name suggests, these documents act as intermediate storage of information, which can be sent bi-directionally. Message types are responsible for creation of Idocs.
IDocs Components
Data on Internet is exchanged using data formats like IPV6 – and SAP uses a similar approach. Idocs are a well-structured medium through which data transfer takes place. Figure 3 explains the structure of Idocs.
Figure 3: IDoc COMPONENTS
Image Source: http://help.sap.com
An IDoc is made up of the following parts:
- Control Record: This section contains control information regarding the Idoc. Its constituents are Sender’s name, Receiver name, Message type and Idoc type (illustrated in figure 3). The format of the control record is similar for all IDoc types.
- Data Segment: It consists of a header that contains the identity of the Idoc. Its constituents include, a sequential segment number, a segment type description and field containing the actual data of the segment.
- Status records: The status record shows the information regarding the already processed stages and remaining processing stages of the Idoc. It has an identical format for each IDoc type.
Idocs Structure:
Idocs support a hierarchical structure. Figure 4 shows an Idoc, starting with the header. The header has items, which in turn have sub-items. The lowest level in the hierarchy contains the text. The end of the Idoc is represented with the help of ACCUM (means accumulate) segment. Remember that an IDoc can only contain character fields.
Figure 4: IDoc STRUCTURE
Image Source: http://help.sap.com2.4 ALE Converters
ALE converters need to be compatible with SAP R/3 system and therefore chosen carefully. SAP offer a certification program for ALE converters – and there are a large number available.
The minimum requirements of the ALE converter are:
- Ability to accept and understand participating IDocs in message exchange.
- Capability of transaction id management and status tracking.
- Ability of mapping IDoc fields to and from external systems.
- Independency from R/3 application server.
3.0 Configuring ALE:
The essential entities involved in the ALE framework have been discussed above. We will now proceed with the configuration methodology for ALE implementation. The configuration is a multi-step approach. The steps can be categorized as follows (as depicted in figure 5):
Figure 5: MULTI-PHASE ALE CONFIGURATION
3.1 Understand and verify the need of business processes
The need of implementing ALE must be clear to you. For that you need to have all the details of the business requirements. These requirements will facilitate the implementation process and also ensuring its success.
3.2 Configure SAP user administration module (BASIS)
This step involves BASIS configuration of SAP system. The concept of the Logical System described above is applicable here. BASIS administration involves creation of logical systems (LS) for every prospective ALE-enabled client, followed by linking prospective clients to the Logical System using the respective servers.
Once the Logical Systems have been created, you create background users on the prospective clients – to be used by ALE. After this, choose Tools > Administration > Administration > Network > RFC destinations or enter transaction code SM59 to create RFC (Remote Function Call) destination for each client.
As a final step, create partner profiles for the sending system. A partner profile is an identifier for the sending system that is used for communicating messages. You will be using LS as it is used for ALE communications. Every partner profile used for ALE must be based on existing LS (created above).
3.3 ALE Functional Configuring in SAP
This configuration step allows the installation of core ALE features on which data transfer activity will be based. You need to create a Customer Distribution Model (CDM) first. The Customer Distribution Model acts as a repository of data that decides the flow of message types to Logical Systems (LS). There can be one to many messages flow to a Logical System and it can also happen vice-versa. You also need to enforce a selection criterion on the message (type) flowing to a Logical System. This is achieved by adding appropriate message types and filters to the CDM.
Now that the path of the message flows have been set, we can generate outbound partner profiles (similarly as we done for inbound profiles in step 2). Finally, you can distribute the CDM to the receiving systems followed by generating inbound partner profiles on each of the clients.
3.4 Testing and Implementing the ALE Configuration
After completing the setup of the ALE environment it needs to be thoroughly checked and tested with real time business processes and situations. The performance should be measured with varying degree of business transaction volumes. It is advisable to include negative and ‘unusual’ test scenarios as well.
Once testing is completed it can be implemented once it is signed off with the respective business owners.
4.0 Other Useful ALE Concepts and Conclusion:
Here are few additional concepts which are broadly applicable to ALE and will help readers understand SAP’s integration services.
Listings are special filter object types, which are used to specify a selection criterion for distributing master data. Listings are based on the SAP Classification system. Lists are allocated to an LS using transaction SALE (from the ALE customizing guide) or Distribution Scenarios > Master Data Distribution > Distribution via Listings
Note: Listings are applicable only to Material, Customer, and Vendor master data.
Ports are a logical representation of the communication channels in SAP. R/3 defines four types of ports viz. tRFC (transactional Remote Function Calls), File, R/2, and Internet. ALE can use all port types to distribute Idocs.
Process Codes are used in both ALE and EDI framework to identify the function module or API (Application Programming Interface) to be invoked for subsequent processing. Inbound as well as outbound interfaces use process code but for different purposes. Outbound process codes are stored in table TEDE1, while inbound process codes are stored in TEDE2.
Message control is a mechanism by which documents are output based on a selection criteria and requirements. This concept is applicable not only to EDI and ALE, but also to other output mediums (for example: print, fax). Message control determines the type of document, its timing, number, and the medium. NAST table stores output records.
The conditions (selection criteria and requirements) for creating an output message are stored in condition tables. Search mechanisms are used through access sequences, output processes, and requirements to determine whether an application document qualifies for output.
ALE provides powerful capabilities to capture changes occurring to master data using Change pointers. These R/3 objects mark changes to SAP master data. ALE configuration facilitates the relation between Change Document objects and change pointers. This feature can be used to keep two or more systems synchronized with respect to master data.
In conclusion, ALE is a simple add-on application that relies heavily on the customizable distribution scenario. Every time a data object (described in an ALE scenario) changes, an IDoc is triggered. Application Link and Enabling (ALE) is one of the most common and effective technologies available for distributed SAP systems.
