ALE and IDOC's

ALE (Application Link and Enabling) &  IDOC(Intermediate Documents)

 What is ALE?

ALE (Application Link and Enabling) is SAP proprietary technology that enables data communications between two or more SAP R/3 systems and/or R/3 and external systems.

ALE is the set of tools, programs, and data definitions that Provides the mechanism for distributing SAP functionality and data across multiple systems.  ALE enables the construction and operation of distributed applications.

 ALE Overview

From a System Infrastructure view, an SAP system consists of three layers:
 

• The Database Layer stores and retrieves all data. The database contains all of the data related to the SAP system, including the ABAP programs, the Configuration data, the master data, and the transaction data.

 

• Application layer: This layer provides ALE with an interface to R/3 to originate or receive messages containing data to or from external (or other R/3) systems and executes the SAP programs and processes requests from users.

• The Presentation Layer contains the SAP Graphical User Interface (GUI), and handles all user input and output.

Together, the three layers make up the three-tiered client-server architecture of SAP.

We can distribute the three layers over any number of physical computers. However, there may only be one database server.
 

 From a Database or Configuration view, the SAP system consists of:
 

• Client-Independent data, such as ABAP programs, client-independent tables, etc.
• One or more Clients. Each client contains its own client-dependent configuration

            (Company hierarchy, process configurations, etc.), master data (customer,

             Material, vendor, etc.), and transaction data.

The Basic Ideas of ALE

 

 

ALE is a technology introduced by SAP with its 3.0 release. Its purpose was to overcome the limitations of a single SAP system. A single SAP system that runs on top of one database often does not fulfill the needs of larger corporations, either from a business or a technical perspective.
 

 ALE allows the implementation of loosely coupled SAP systems; each of the SAP systems has its own database and is essentially independent from the other systems. ALE allows us to distribute data between different systems and different business processes.
 

The distribution of data happens at the application server level (Hence, Application Link Enabling).
 

 SAP supports a number of distribution scenarios, which define how different SAP systems can interact. The scenarios define what messages are sent back and forth between the systems (for example, Contract information needs to be exchanged between systems that run central purchasing and systems that run decentral purchasing).
 

 The “data container” that carries the message is the Intermediate Document, or IDoc. SAP delivers over 100 IDoc types to support its distribution scenarios; along with the IDocs come the associated programs to generate (on the outbound side) or to process (on the inbound side) IDocs.
 

 Part of ALE is a communication infrastructure; specifically ALE uses the “transactional RFC” technology to ensure the transaction consistency across system boundaries. ALE also ties into SAP workflow to handle errors in the data transfer process.

 

 

 ALE scenarios fall into three categories: master data, transactional data, and control data distribution. Although the underlying principles are the same for the different categories, there are differences in their functions and configurations. SAP delivers over 200 ALE scenarios; and by extension there are approximately 200 application areas that can leverage ALE technology for data distribution or communication. A subset of these scenarios is supported by R/3 for Electronic Data Interchange (EDI). There are several advantages to using ALE technology:
 

 ALE Building Blocks and Concepts

 The following building blocks are fundamental to ALE functionality:

 Logical System: A Logical System (LS) is the representation of an R/3 or external system in SAP R/3 for the distribution of data to and from the R/3 System. Every R/3 client used for ALE or EDI has to have a base LS associated with the client. This LS becomes the “sender” for outbound messages and a “receiver” for inbound messages. In addition to the base LS, a second LS should be created within that R/3 system for each R/3 or external system used for ALE interfaces. In an inbound ALE interface, this second LS represents 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).
 

 Message type: A message type represents the application message exchanged between R/3 systems and R/3 and an external system. A message type characterizes the data sent across systems and relates to the structure of the data called an IDOC type (see below). For example, MATMAS is a message type for Material Master, and INVOIC is a message type for an Invoice (Billing Document). ALE supports over 200 message types in R/3 and about 200 application areas.
 

 IDOC type and IDOC: An Intermediate Document (IDOC) type represents the structure of the data associated with a message type (DEBMAS02 for message type DEBMAS — Customer Master, and WMMBID02 for message type WMMBXY— Goods Movements), while an IDOC is an object containing the data of a particular message type. IDOCs are data containers with intelligence built in. Each IDOC contains one and only one business object. For example, an IDOC of type SHPMNT01, message type SHPMNT, will contain data only of one Shipment Document. Generally, the architecture of an IDOC is independent of the message type by virtue of ALE’s ability to redefine it for any message type.

 

 

 Customer Distribution Model: In an R/3 system, the Customer Distribution Model is a tool that stores information about the flow of messages across various systems. The Customer Distribution Model uses an SAP-delivered Distribution Reference Model as its basis (the Customer Distribution Model can have distribution scenarios other than ones stored in the Distribution Reference Model.) The Customer Distribution Model stores data that dictates which messages (message types) flow to which Logical Systems. Many messages can flow to one Logical System, and one message can flow to several systems. With the use of filter objects and listings (which I’ll describe shortly), it is also possible to specify in a model the criteria for filtering information for a specific system. A Customer Distribution Model can be created in an R/3 system with that client’s base Logical System as the “sender” Logical System.

 

 

 ALE provides powerful capabilities to capture changes occurring to master data and to distribute them via the IDOC interface. This feature can be used to keep two or more systems synchronized with respect to master data.

 

 

 Ports: A port is a logical representation of a communication channel in SAP, with the data communicated being IDOCs. There are four types of ports that can be defined in R/3: tRFC, File, R/2, and Internet. ALE can use all port types to distribute IDOCs, while EDI typically uses a file-based port. tRFC and File ports can link to RFC destinations connected to R/3-to-R/3 or TCP/IP. By linking ports to RFC destinations, the port can also trigger scripts to invoke EDI subsystems, IDOC mapping software, and FTP.

 

 

You can maintain ports by executing transaction WE21 or WEDI, or selecting IDOC -> Port Definition. RFC destinations can be maintained using transaction SM59.

 

 

 Partner profile: A partner profile is an identifier for a system used for communicating messages. There are four types of partner profiles: KU for Customer, LI for Vendor, B for Bank, and LS for Logical System. KU, LI, and B are used for EDI partners, while LS is used for ALE communications. Every partner profile used for ALE must be based on an existing LS.

 

 

 A partner profile brings together several ALE and EDI elements to define the parameters of communication between two or more systems. Other than general information, you have to maintain inbound parameters, outbound parameters, and message control. The main parameters are message types, IDOC types, process codes, partner functions, application identifiers, message functions, output types, and ports. Other parameters also determine the mode of processing and error handling.

 

 

A partner profile plays a major role and can be viewed as a gateway for ALE and EDI communications. It routes the specified messages through defined IDOC types to a given port after invoking the appropriate function modules for outbound processing. It receives IDOCs of a specific type, and it identifies modules to post data to the application databases in the case of inbound interfaces.

 

RFC Destination:Used to define the characteristics of communication links to a remote system on which a functions needs to be executed.


Process: The processes in the application layer and the ALE layer are completed on both the inbound and outbound processing sides. The communication layer transfers the data by transactional Remote Function Call (tRFC) or by EDI file interface.

 The process can be divided into the following sub-processes:

1. Outbound Processing

2. Inbound Processing

 

 

 Why use ALE?

 ALE provides for the integration of distributed applications, but why would we distribute

applications in the first place? There are several technical and business reasons:

 

 

• System Performance: The transaction load is too heavy for a single SAP system.
• High Availability Requirements: The company cannot afford downtime due to backups, maintenance, upgrades, etc.

 

• SAP Release Coordination: Different units of the organization may require different releases of the SAP software.

 

• Very Large Database: Companies with very large databases may need to distribute the data across multiple SAP systems.

• Business Structure: Business units may require independence and autonomy for day-to-day operations, and yet still need to share some data and functionality with other units in the enterprise.

• Interfacing with non-SAP systems: The company may wish to maintain certain        applications on non-SAP systems, while at the same time integrate these applications and their data with the SAP system.

• Keep development system data in sync with production data: An organization may wish to keep the data on a development system the same as on a production system.

• Maintain configuration and master data across clients: Organizations using multiple clients may wish to maintain certain data on a client-independent basis.

 

 

 What can we distribute with ALE?

 

 

 We can distribute all types of data with ALE:

 

 

• Control or Customizing Data: Control data includes all configuration objects that define how the SAP system is organized. This includes the enterprise structure configurations, global settings, etc.

 

• Master Data: Master data objects that can ALE can distribute include:

 

 

Ø  Material Master

Ø  Customer Master

Ø  Vendor Master

Ø  Cost Centers

Ø  Activity Types

Ø  G/L Accounts

Ø  Characteristics/Classes/Classifications and many others

 
 

• Transaction Data: Transaction data is data related to specific business transactions or processes (e.g. sales orders, credit memos, invoices).

SAP delivers several hundred predefined distribution scenarios. If a standard solution is not provided, then we can develop a custom scenario to distribute any data required by the business. The number of supported business scenarios increases with each SAP release.

 

 

 

Example distribution scenario: Sales and Distribution

 

 

The sales system provides only the logistics data that the warehouse requires to fill an order. Summary information is reported into the central sales information system. All of the data sent references a single order document.
 

 The Intermediate Document (IDoc)

 

 

 The Intermediate Document, or IDoc, is the main component of all interface functionality in SAP. Each interface message type has an associated IDoc type. The IDoc, in turn, defines the structure and formatting of the data contained within the message type.
 

IDocs provide support for customized development: 
 

Ø  API for development

Ø  Easy to use and apply

Ø  Real-time or asynchronous interface connection

Ø  Independent of external system data requirements

Ø  Independent of type of external system 
 

The data interface standard is standardized according to the following

key rules: 
 

Ø  The documentation of the interface is published.

Ø  SAP takes responsibility for compatibility of the interface standard for its own             applications.

Ø  Field lengths and types are defined according to the data element definitions of the EDIFACT EDI standard and SAP’s data repository.

Ø  Codes for coded fields are taken from international standards where the standard

           applies.

 

 

 IDoc Structure

 

 

An IDoc consists of three record types: 

 

 

Ø  Control Record: Contains the data that uniquely identifies the IDoc.

 

 

Ø  Data Records: Contain the application data related to the message type. An IDoc  may have multiple data records, called segments. A data segment is made up of a key section and a data section. The key section uniquely identifies its respective data segment.

 

 

Ø  Status Records: Contain the information relative to the various statuses that the IDoc encounters, such as IDoc created, document posted, etc.The IDoc is data stored in a structured format. It is a medium for data transfer. An IDoc is not a process nor executable code.

 

 

 SAP originally developed IDocs for EDI, and then adopted the IDoc concept and structure for its ALE interface.
 

 The IDoc Control Record

 

 

The Control Record stores the characteristics of the IDoc. Some of the more important fields are:

 

 

• IDoc ID Number (DOCNUM)
• IDoc type (DOCTYP)
• Direction (In or Out) (DIRECT)
• Name of Sender (SNDPRN)
• Name of Receiver (RCVPRN)
• Processing Status (STATUS)
• EDI Message Type (if EDI) (STDMES)

 

 

Control Records are stored in the R/3 transparent table EDIDC, keyed by IDoc ID number. This ID number is assigned by SAP for all IDocs.

 

 

 The IDoc Data Records
 

 The Data Records contain the actual application data. Some of the more important fields are:

Ø  IDoc ID Number (DOCNUM)

Ø  Segment Name (SEGNAM)

Ø  IDoc Data (SDATA) (structure differs with each IDoc type)
 

The Data Records are stored in table EDID4 (EDID2 in prior versions), keyed by IDoc number and segment number. The table structure is 71 bytes of administration data (IDoc number, segment identifier, etc.) Followed by 1000 bytes of free-form application data.

Each segment type uses a different format for the 1000 bytes of application data.
 

 Data Record Hierarchy

 

 

Information that relates to the object as a whole is stored in the main segment.

Hierarchical information is stored in separate segments. Each segment typically

corresponds to a different database table.

 

 

Ø  Attributes of a segment:

Ø  The fields of the segment. Each field is assigned a length and a data element from

      the ABAP dictionary.

Ø  Whether the segment is required or optional in a valid IDoc.

Ø  The minimum and maximum number of instances of the segment.
 

 Example – Material Master

 

 

As an example, consider the Material Master IDoc Type (MATMAS01). Each material has information that is common throughout an SAP implementation. This data is stored in the main segment. Each material has some information that is different for each plant, which is stored in a separate plant segment. Within a plant, the material can be stored in multiple storage locations, each of which requires a storage location segment for its information. We can store several different descriptions of the material (for different languages, for example).

 

Distribution Models

 

 

The distribution model describes the flow of data between logical systems:

Ø  What systems are there?

Ø  What applications will run on which systems?

Ø  What systems will SEND data?

Ø  What systems will RECEIVE the data?

Ø  Other rules for data distribution?
 

ALE uses the model to control data distribution. The ALE system will not distribute any data unless you specify the data flow in a distribution model.
 

 Before building a distribution model, we must define the logical systems that we will be using. The Logical System Definition transaction will access the list of logical system names. Click on New entries to create new logical systems.
 

 Steps to create ALE and IDOC’s: 
 

Ø  Create the Logical System using SALE Tcode.

Ø  Assign Clients to logical System using SALE Tcode.

Ø  Create RFC Destinations using SM59 Tcode.

Ø  Create Ports using WE21 Tcode.

Ø  Create Distribution Model using BD64 Tcode.

Ø  Create Partner profile using BD64 Tcode.

Ø  Outbound Process using WE05 Tcode.

Ø  Inbound Process using WE05 Tcode.