You are on page 1of 13

Overview of ALE / IDOCs

ALE is a set of


programs and

data definitions

that provides the mechanism for distributing functionality and data across
multiple system.
What Data can be Exchanged ?
Transaction Data
– SD, MM etc.
Master Data
– Material, Customer, Vendor, etc.
Control Data
– Organizational Reference Information
• Plants, Sales Orgs, etc.
Data required to enable tightly coupled, distributed applications
- Separate HR, Separate Treasury, etc.
IDOC is the acronym for Intermediate Document. It is simply a data
container used to exchange information between any two processes that
can understand the syntax and semantics of the data. IDocs are relatively
simple to understand. But, like most simple things they are difficult to
IDocs are basically simple ASCII data streams. When they are stored to a
disk file, the IDocs are simple flat files with lines of text, where the lines
are structured into data fields.

like Postscript or HTML) to embed the data. Everybody who has ever dealt with interface programming will find IDocs very much like the hierarchical data files used in traditional data exchange. The information which is exchanged by IDocs is called a message and the IDoc is the physical representation of such a message. message is buffered . International standards like the ODETTE or VDA formats are designed in the same way as IDocs are. EDIFACT ) • IDocs can be viewed in a text editor and do not contain any binary data. Other EDI standards like XML.12. R/3 and External system  If network problem.g.12 or EDIFACT/UN are based on a data description language. because they use a programming language syntax (e.The typical structured file has records. The name “messages” for the information sent via IDocs is used in the same ways as other EDI standards. They differ principally from the IDocs concept. ANSI X. Characteristics:• An IDoc is not a process • In SAP system IDocs are stored in the database • Every IDoc has a unique number (within a client) • IDocs are independent of the sending and receiving system ( SAP to SAP as well as Non-SAP) • IDocs are based on EDI standards (like ANSI X. Features –ALE / IDocs  Distributed System yet integrated with SAP R/3  Based on ‘Application-to-Application integration using ‘Message Architecture’  Reliable communication  Data is exchanged using “IDocs”  Support both R/2. each record starting with a leading string that identifies the record type. Their specification is stored in the SAP data dictionary. Data is stored in character format.

As an example. A parentchild relationship signifies that the child segment can not exist without the parent. ALE support backward compatibility IDoc Type IDoc type is a document structure that describes the order in which fields and records occur. The IDOC type is the most important component in the EDI process. if an EDI transaction of 850. In the standard list of IDOCs for example ORDERS01. each segment has an attribute that defines whether the segment is optional or mandatory. The message type is based on an IDOC structure. ORDERS03. Hierarchy of segments: The hierarchy of segments specifies the physical sequence and any parent-child relationship in the segments. which is a purchase order. This message is based on an IDOC type such as ORDERS05. ORDERS04. the message type ORDERS is assigned to it. The last two characters represent the version. The EDI document to be generated has an equivalent message type defined in the SAP system. A basic IDOC type has the following characteristics: Name: A basic IDOC type can be assigned up to a 30 character name in release 4. An IDOC has a record oriented structure. is to be generated. Maximum/Minimum range for each segment: When used in an IDOC type each segment has an attribute that defines the minimum and the maximum number of times a data record corresponding to a segment can exist in an IDOC. An IDOC type is also referred to as basic IDOC type. ORDERS02. they are still classified as one of the three record types: • Control Record . List of permitted segments: Only the segments defined in the IDOC type can be used in an IDOC. Segments of a previous version of an IDOC type are never deleted. Although there are several records in an IDOC. ORDERS05 types are available. IDOC Record Types & Structures An IDOC is an instance of an IDOC type. Mandatory versus optional segment: When used in an IDOC type.0 and later. as well as the data type of these fields. This approach is necessary to maintain backward compatibility.

this information basically includes the IDOC number. This is very much like the . 4. 2.One control record defined by the SAP Data Dictionary structure EDI_DC40. 3. its destination and a categorical description of the contents and context of the attached IDoc data.There is only one control record per IDOC. such as its origin. and information such as the message type it represents and the IDOC type.• Data Record • Status Record Control Record The control record contains all of the control information about an IDOC. Features of IDoc control record:1.The structure of the control record is the same for all the IDocs and is defined by SAP. The control record carries all the administrative information of the IDoc.The structure of the control record is defined by the data dictionary structure EDI_DC40 in release 4. The control record is stored in the EDIDC table.0 onwards. sender and receiver information. with a record length of 524 bytes.

are data records. regardless of their actual content. filling the rest of the line. Data records contain the actual application data.0-3.0 on and EDI_DD for version 3. as shown in the figure below.envelope or cover sheet that would accompany any paper document sent via postal mail. the control record is used by the standard IDoc processing mechanism to determine the method for processing the IDoc. The structure of the administrative section differs somewhat in the two versions.x.0 and on. This method is usually a function module but may be a business object as well. which is followed by the segment data. The data section is mapped to a segment type.000 bytes where the actual data resides. The data record is defined by the data dictionary structure EDI_DD40 for IDocs from version 4. . Characteristics of Data Record: A data record has two parts: an administrative section and a data section.  The data section of a data record is a stream of 1. All records of an IDoc are structured the same way. Both release formats are slightly different with respect to the lengths of some fields. Regardless of the used IDoc type.1 IDocs.x and EDID3 for release and 3. to interpret the meaning of various data values in a record. Data Record All records in the IDocs. with a segment information part and a data part which is 1000 characters in length. which are always 1000 characters long. For R/3 inbound processing. The processing method can be fully customized. A data record size can have maximum size of 1063 bytes in release 4. They are records with a fixed length segment info part to the left. which come after the control record. as defined in the administrative section. all IDocs are stored in the same database tables EDID4 for release 4. They are all structured alike.

and 50 and above for inbound processes. Status Records The status record conforms to the data dictionary structure EDI_DS40 for IDocs from version 4. Data records for IDocs from version 4. while version 3. which are stored in table EDIDS. • The status record also includes date and timestamps for when that particular state was reached.0 on are stored in the EDID4 table. and are not externalized. It contains information on the state of the IDOC as it passes through the various stages of processing. The status records maintain a history of the IDOC states. The latest status code is also maintained in the control record.1 IDoc data records are in EDID2.0 on and EDI_DS for previous versions. with a range of values: status codes of 01 to 49 are reserved for outbound processes. So we could not see status records in an IDoc flat file outside the SAP system. These records can be accessed or created only by SAP function modules (APIs).0-3. Fields in the Status Record Table (EDIDS): Field Name Description MANDT Client DOCNUM IDoc number LOGDAT Date of status information LOGTIM Time of status information COUNTR EDI status counter CREDAT Date status record was created . • An IDOC may have one or more status records (multiple status records). • The STATUS field has a length of two bytes (data type CHAR). Status records are stored in the EDIDS table.

function module) STACOD Status code STATXT Text for status code SEGNUM Number of SAP segment SEGFLD Field name in SAP segment STAPA1 Parameter 1 STAPA2 Parameter 2 STAPA3 Parameter 3 STAPA4 Parameter 4 STATYP EDI: Type of system error message STAMQU Status message qualifier .CRETIM Time status record was created STATUS Status of IDoc UNAME User Name REPID Program Name ROUTID Name of the sub-routine (routine.

1. The syntax rules checked for an IDoc are as follows:• Only valid segments as defined in the IDoc type are allowed. The syntax of an IDoc is governed by the definition of its IDoc type. and internal programs.STAMID Status message ID STAMNO Status message number TID Transaction ID APPL_LOG Application log Syntax Rules for an IDoc When an IDoc is created. customer or bank). • A data record cannot exceed the maximum number of repetitions as defined for the segment type. • Segments must occur in the same physical order defined the IDoc structure. A parent segment. The data in the application document format suitable for the application modules. The first step in the outbound process involves creating an application document. however. The outbound process consists of six steps. . it goes through a syntax check to ensure its integrity. such as a purchase order or sales order. The IDoc is generated. and saving it in the database tables. The application document just created id now formatted to an IDoc format. 2. • A child segment cannot exist without its parent segment. EDI Process Flow of an Outbound IDoc The outbound process sends documents from the SAP system to a business partner (vendor. • Segments specified as mandatory must exist. screens. can exist without a child segment. The application document is created. A document in an IDoc format is suitable for processing by EDI components.

EDI documents are received from a business partner via the VAN. This IDoc document must be passed down to the operating system layer for processing by the EDI Subsystem. After the document is converted to an EDI standard format. The IDoc is converted to EDI standard. the EDI subsystem can optionally report the state of processing at various milestones back to the SAP system.When an IDoc is under the control of EDI subsystem. IDoc is an SAP proprietary format. The EDI transmission is received. A type of third-party software called a translator carries out the transformation process. it is transmitted to a trading partner based on the partner’s EDI settings. The status records are generated by the subsystem and passed back to SAP. The inbound process receives an EDI document (such as a purchase order response. These documents are in one of the EDI standard formats and deposited in the EDI subsystem’s repository. SAP takes no responsibility for translation. 2. and has certified several subsystems for connectivity to SAP. For EDI purposes.Subsystem’s translator converts the EDI format document into an IDoc format suitable for SAP applications. EDI Process Flow of an Inbound IDoc The inbound process simply reverses the steps of the outbound process. 4. The IDoc is transferred from SAP to the operating system layer: The IDoc created in the step 2 resides in the SAP database repository. This mechanism provides complete visibility of the translation and the transmission process from within SAP. 5. a customer or a bank) and creates SAP documents from it. The inbound process consists of four steps: 1.3. . SAP refers to these translators as EDI subsystem. the document in IDoc format is converted into an EDI standard format. 6. The EDI subsystem reports status back to SAP. Here in step 3 the IDoc is transferred to the OS as a text file. The EDI document is transmitted to the business partner. The EDI document is converted into an IDoc. sales order or payment information) from a business partner (such as a vendor.

SAP looses control over the IDoc for EDI translation and EDI transmission. Status codes passed to SAP by the Subsystem Status Code Description . This program creates an application document such as a sales order. Then a SAP application reads the IDoc file and stores an IDoc in the SAP database repository for further processing. the EDI subsystem triggers the startrfc program in the SAP system to start RFC enabled functional module EDI_STATUS_INCOMING for processing the status file created by the EDI subsystem. 4. date-stamp. The SAP system then retrieves the status logs from that file and stores in the EDIDS table for the respective IDoc number.3. the EDI subsystem is often responsible for triggering the inbound process. status codes etc. In outbound process when an IDoc leaves SAP system for processing by the EDI subsystem. invoice etc. The EDI subsystem triggers an inbound program in the SAP layer. The document can be viewed using standard application transaction. In outbound process the EDI subsystem is responsible for reporting to SAP any errors including:• Translation errors • Syntax errors • Transmission errors • Connectivity errors After the successful or un-successful processing.SAP provides a program named startrfc to start RFC enabled functional module EDI_DATA_INCOMING to process the IDoc file. The application document is created. The IDoc is transferred to the SAP layer. Triggering the Inbound-Outbound Process After receiving an inbound EDI transmission and creating an IDoc file. But the EDI subsystem creates a status file and maintains the log of processing stages with time-stamp. The IDoc text file is stored at the SAP’s operating system layer. The IDoc is then passed to a posting program. purchase order acknowledgment. The latest status code is also maintained in the IDOC’s control record.

acknowledgement still due 23 Error during retransmission .04 Error within control information of EDI subsystem 05 Error during translation 06 Translation OK 07 Error during syntax check 08 Syntax check OK 09 Error during interchange handling 10 Interchange handling OK 11 Error during dispatch 12 Dispatch OK 13 Retransmission OK 15 Interchange Acknowledgment negative 16 Functional Acknowledgment positive 17 Functional Acknowledgment negative 22 Dispatch OK.

UNT E2EDK01 .24 Control information of EDI subsystem OK 36 Electronic signature not performed (timeout) Commonly used IDoc segments in EDIFACT mapping : Following is a list of commonly used IDoc segments and theirs correspondingmapping segments in EDIFACT. ALC E2EDK04 .Reference Data <-> BGM. MAPPING EDIFACT SEGMENT EDI_DC40 .PAT E2EDK05 .Header general Data <-> BGM E2EDKA1 .Partner Information <-> NAD E2EDK02 . RFF E2EDK03 .Terms of payment <-> PCD E2EDKT1 .Control Record <-> UNH.Date segment <-> DTM.Tax segment <-> TAX.Conditions <-> MOA.Text Identification <-> FTX IDOC SEGMENT . there can be one or more mapping fields which might be used for client’s requirement. MOA E2EDK18 . This list is just for example purpose only.

Header text <-> FTX E2EDP01 .Item Date segment <-> DTM E2EDP19 . MOA E2EDS01 .Item object Identification <-> E2EDP05 . LIN. QTY E2EDP03 .E2EDKT2 . IMD .Item condition <-> MOA.Summary segment <-> CNT PIA.Item Tax <-> TAX. PRI E2EDP04 .Item general Data <-> LIN.