This document will define what an Idoc is and provide a brief overview on IDoc structures and component parts.
Here we will explain in very basic terms what an Idoc is used for, and outline the key component parts of an IDoc.
What is an IDoc?
The term IDoc stands for “Intermediate Document”.
Idocs are used as SAP’s standard document for exchanging data between different application servers.
The "IDoc interface" is made up of the IDoc data structures + the processing logic employed to process the Idoc. In simple terms what we mean by "processing logic" is the way we fill the Idoc with application data on the sending system and then extract this data from the Idoc and post it to the application tables on the receiving system.
With ALE we connect application servers using a “message based interface”. Electronic Data Interchange (EDI) and Application Link Enabling (ALE) are the main techniques using IDoc to exchange data between systems.
ALE also provides exception handling so errors can be resolved and Idocs posted in an efficient manner.
Segments are the basic building blocks for an IDoc and store the actual data. SAP supplies some IDocs by default. These are known as “basic types”. Users can then add additional data to the existing basic types using reference segments. If the default basic types supplied by SAP do not meet with requirements then users are free to define their own Idoc types (custom “Z” Idoc types) with the segment structures required.
Every Idoc is made up of 3 records:
- The “Control” Record (always 1 per Idoc)
- The "Data" records (multiple data records per Idoc containing the actual application data)
- The“Status” records (again typically multiple status records per Idoc which flag processing of the Idoc on both the outbound and inbound systems)
There is 1 control record per Idoc which contains general information such as sender identification, receiver identification and IDoc type.
Cotrol Records are stored in the data dictionary table EDIDC (you can use transaction SE11 to view table EDIDC).
The following are the most critical fields in the Control record of an IDoc:
- Mestyp: Logical message type
- Idoctp: Idoc type – this dictate the structure of the IDoc
- Cimtyp: Structure of customer extension
- Rcvprn: Partner number of the receiver
- Rcvpfc: Partner function of the receiver
- Rcvprt: Partner type of the receiver for example LI for vendor or KU for customer
You can see the control records of any Idoc using transaction WE02 – select the Idoc and then double click on the control record:
You will then see details of the control record under the following tabs -> Type, Partner, Technical, Address & Details.
The most important information is contained in the first 3 of these tabs:
The “Type” tab gives information about the structures / definitions of the Idoc in question including things like details of the basic type, extension, and message type. So for example you should see something like:
The “Partner” tab provides details about the receiver and sender partners involved in the transmission of this Idoc. So you will see something like:
The “Technical” tab will tell you about the Idoc version, the output type used (how it was transferred between sender and received) and whether it is serialized or not (whether this Idoc has to be processed in a specific order or not). In here you will also see when the Idoc was first created and when the last update too place. So again you should see something like this:
Data records contain the actual application data which is being sent by the application through the Idoc for processing. Data record information is stored in the data dictionary table EDIDD. For each segment type of the IDoc, there is a DDIC structure with the same name (the DDIC is the ABAP Dictionary used in SAP to centrally describe and manage all the data definitions used in the system). A field string with this structure is used for creating a data record. The application data is mapped to the field string. The segment type is written to the field SEGNAM, and the field string is written to the field SDATA. This data record is then included in the internal table with the structure edidd.
So each data record consists of 2 components -> the “segnam” (segment type) and “sdata” (the actual data with maximum 1000 byte-long character)
Again you can see the data records of an Idoc by simply displaying the Idoc in transaction WE02 and drilling into Data Records. For example:
These are used to document the status of the IDOC as it is processed through the ALE layer and eventually posted to the backend application. The status records are stored in the data dictionary table EDIDS.
The important fields in these records are
As with the control and data records you can see the status records of an IDoc in We02. For example the following shows the status records associated with Idoc number 36232 :