Beginners Guide to ALE and IDOC Processing

ALE (Application Link Enabling) supports the construction and operation of distributed applications. ALE handles the exchange of business messages across loosely coupled SAP applications, ensuring that data is consistent. Applications are integrated by using synchronous and asynchronous communication, rather than through a central database.
What is ALE?
ALE is SAP proprietary technology that enables communication of data between two or more SAP R/3 and/or R/3 and external systems.
ALE provides intelligent mechanisms which clients can achieve integration and distribution of applications and data. ALE technology facilitates rapid application prototyping and application interface development, thus reducing delays in implementation.
ALE comes with application distribution and integration scenarios, and a set of tools, programs, data definitions, and methods that you can easily configure to get an interface up and running.
Advantages of ALE
ALE offers better performance interface entrants compared to traditional techniques such as data sets (BDC) or call transactions. ALE does not use input screen on the lot.
ALE is the strategy architecture of R / 3 “loose coupling” with the legacy and third-party applications and is a key element of the Business Framework. It provides an architecture based on asynchronous message to the integration of Business Framework, including Business Components, Business Objects and BAPIs.
Components of ALE
- Legacy System
- Message type
- IDOC type
- Customer Distribution Model
- Filter object type and filter objects
- Change pointers
- Ports
- Process codes
- Partner profile
- Message Control
The Main Steps in the Design of ALE
The Distribution Model is a distribution tool that stores information about the flow of messages between different systems.
A filter object type is used in the distribution model of the customer to impose a selection criterion on the message (type) arising from the logic of the system. A filter object type with a value associated with it is called a filter object
Change pointers SAP R/3 objects that mark changes in SAP data. Change pointers are managed by sharing mechanisms in a Master Data and changes are based on documents (CD) objects. CD objects record the changes to master data at a field level. These changes are recorded in Tables CDHDR (header table) and CDPOS (detail table).
Maintain Object Attributes
A port is a logical representation of a communication channel in SAP. There are four types of ports that can be defined in R / 3: tRFC, file R / 2, and the Internet.
Process codes are used in the ALE and EDI to identify the function module or the API. Code of each process is associated with a message type. Outbound process codes are stored in the table TEDE1 while entering codes are stored in process TEDE2.
Use transaction WE41 to display outgoing codes and process WE42 to display the codes.
Message control is a mechanism by which the documents are output based on certain selection criteria, requirements, and sequences. Message control determines the type of document, date, number and the medium (paper, fax, ALE or EDI).
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.
IDOC Definition
An intermediate document (IDOC) is a container for distributing R/3 application data among between R/3, R/2 and non-SAP systems.
ALE uses IDocs to exchange data between logical systems. Non-SAP systems can use these IDocs. In the standard interface for data transfer, IDocs are created by message types and Methods when data is to be distributed. The type of message is the format in which data for a business process is transmitted electronically.
More info about the IDOC
An IDoc represents a configuration of an Idoc Type that determines the IDoc structure. An IDoc consists of a header, several data segments and status records. The functions of the individual elements of an IDoc are as follows:
The contents, structure, sender, receiver and current status of the IDoc are defined in the IDoc header.
Each data segment contains a standard header consisting of a  sequential segment number, a description of the segment type and a 1000 character long string field containing the actual data of the segment.
The status records show the history of the processing steps applied to the IDoc.
How to check the status of IDOC?
In the sending System
Transaction Code for IDoc list is : WE05
A list of IDocs grouped by status is displayed:
Status
03, 12, 38Â – IDoc successfully transferred
02, 04, 05, 25,26, 29 – Processing error
30 -Â Waiting status
In the Receiving System
Transaction Code for IDoc list is : WE05
A list of IDocs grouped by status is displayed:
Status
53 -Â IDoc successfully updated
64 – Waiting status (still processing…)
63, 65 – Inbound error
Message Types
The flow of message across Distributed environment is done through Message Types.
CUSTOMER – DEBMAS
VENDOR – CREMAS
MATERIAL – MATMAS
SALES ORDER – ORDRSP
PURCHASE ORDER – ORDERS
Use the Transaction WE81 to view the message types.
Transaction Codes for ALE
SALE : To Define and Assign Logical Systems .
SM59 : To Establish RFC Connection.
BD64 : To Create Customer Distribution Model.
BD82 : To Generate Partner Profiles.
WE05/WE02: To View IDoc Lists.
BD10: To Send the Material Data.
BD11: To Receive the Material Data.
WE19: To Debug the IDoc.
Copyright: ERPDB : Do not Copy
Good post…