Anthony Cecchini is the President of Information Technology Partners (ITP), an SAP consulting company headquartered in Pennsylvania. ITP offers comprehensive planning, resource allocation, implementation, upgrade, and training assistance to companies. Anthony has over 17 years of experience in SAP R/3 business process analysis and SAP systems integration. His areas of expertise include SAP NetWeaver integration; ALE development; RFC, BAPI, IDoc, Dialog, and Web Dynpro development; and customized Workflow development. You can reach him at firstname.lastname@example.org.
The SAP IDoc Technology
In this month we will continue our look at SAP IDocs and the IDoc Technology by exploring the architecture of an IDoc. The architecture can be best explained by looking at an IDoc’s definition and run−time components.
IDoc Definition Components
Each of the following sections begins with a formal definition of the component.
Basic IDoc Type
Basic IDoc type defines the structure and format of the business document that is to be exchanged between two systems. Lets look at an example below for Basic IDoc Type ZOIPRO01.
A basic IDoc type has the following attributes – (You can display a Basic IDoc Type in transaction WE30).
The first attribute we will look at is NAME. This can be up to a thirty−character name. Custom IDoc types always start with a Z. The last two characters are the version number. After a basic IDoc type is released and you move to a newer version of the SAP system, any changes to the structure of the basic IDoc type will create a new basic IDoc type. In general, the version number is incremented by one. So in the example above we have a custom IDoc type named ZOIPRO01. If we changed this after it was released, it would be named ZOIPRO02…etc..etc. You can see SAP doing the same thing if you look at the delivered Basic IDoc Types ORDERS01, ORDERS02, ORDERS03, …. ORDERS06…etc
Next you will see a list of SEGMENTS. These segments make up the IDoc structure. We have Z1HEAD, Z1OPER, Z1TEXT, Z1SALE, Z1SERIAL and Z1BILLH. These segments may have a defined HIERARCHY. The hierarchy of segments specifies the physical sequence and any parent−child relationship in the segments. A parent−child relationship signifies that the child segment cannot exist without the parent. In our example above the segment Z1OPER is a child of the parent segment Z1HEAD. Therefore an instance of the CHILD cannot occur unless it follows a related PARENT segment.
A segment defines the format and structure of a data record. Segments are reusable components, which means they can be used in more than one IDoc type. A segment consists of various fields that represent data in a data record. Data elements can be of two types: positional or based on qualifiers.
A positional data field occupies a fixed position in an IDoc. These fields always occur in the same position shown in the segment.
A field can also be based on a qualifier, in which case the value represented in a field is tied to the qualifier.
For example, assume a segment has a date field for three dates: the delivery date, the goods issue date, and the order creation date. Instead of creating three separate fields and assigning a fixed position to each one, the three fields can be represented using two fields a qualifier field and a date field. The qualifier field identifies the type of date, and the date field contains the date. You will usually see this when an IDoc represents an EDI Message. This is so we can match the IDoc fields to the EDI Message Implementation Guide from the partner we are trading with.
OK, lets look at the attributes of an IDoc Segment. If you “double-click” on a segment ; a popup will be displayed showing you specific attributes about that segment. Lets “double-click” on Z1HEAD first.
I’d like you to notice is each segment has an attribute that defines whether the segment is OPTIONAL or MANDATORY. In the example, Z1HEAD is NOT a mandatory segment. If the CHECK-BOX was checked, the of course it would be. Each segment also 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.
A data field represents a single data item that is used in a segment. All data field values must be alphanumeric values. The valid data types for a field are CHAR, CLNT, CUKY, DATS, LANG, and NUMC. If you press the button, which is transaction WE31, you will see a list of the data fields defined for a segment.
IDoc RUN Time Components
An IDoc is an instance of an IDoc type. What does this mean? Well, above we created or viewed an existing DEFINITION of a Basic IDoc Type. When and IDoc is actually created in the system, it is assigned an IDoc Number from a Number Range Object and viola it is instantiated or externalized as an object we can work with in ECC.
An IDoc has a record−oriented structure, which is very much like the record structure in a file . At run time the following events occur.
– A unique IDoc number is allocated. (via a Number Range Object)
– One control record is attached to the IDoc.
– Status records are attached.
– Syntax rules are checked.
Lest look at the graphic below. It represents the 3 types of records that make up an IDoc. We will go into each one individually in a moment.
Technical Description of the IDoc Format
An IDoc consists of a header record, any number of lines of application data (application records), and any number of status records per IDoc.
IDoc CONTROL RECORD
The header contains general information about which data is supposed to be transferred, who is the sender, and who is the receiver. This
information basically includes the IDoc number, sender and receiver information, and information such as the message type it represents and the IDoc type. The control record data is stored in the EDIDC table. The key to this table is the IDoc number.
IDoc DATA RECORDS
The data records contain business-related information. To make sure the technical format is independent of the business object and can also be understood by non-SAP systems, the content of each data record is stored as a string of 1000 characters. This character string is preceded by a control area containing information about how to interpret the 1000 characters. Data records for IDocs from version 4.0 on are stored in the EDID4 table.
IDoc STATUS RECORDS
Status records contain information about the previous statuses of the IDoc, such as “successfully created” or “successfully posted.” Status records aren’t transferred between partner systems; that is, both the sender and receiver keep their own status records in their respective systems. The format of the status record is supplied by SAP, and the formats are stored in the EDIDS table. The key for this table is the IDoc number, date and time a message was logged, and a status counter.
Finally lets close this month’s Blog by looking at what the IDoc SYNTAX Check does.
Syntax Rules for an IDoc
When any IDoc is created, it goes through a syntax check to ensure its integrity. The syntax of an IDoc is governed by the definition of its IDoc type. Remember we can define or view this in WE30 as we did at the beginning of this writing. The syntax rules checked for an IDoc are as follows.
– Only valid segments as defined in the IDoc type are allowed.
– Segments specified as mandatory must exist.
– A data record cannot exceed the maximum number of repetitions defined for the segment type.
– Segments must occur in the same physical sequence defined in the IDoc structure. For example, a child segment cannot exist without its parent segment. A parent segment, however, can exist without a child segment.
So in summary, an IDoc type represents the definition component of an IDoc. An IDoc type is a version−controlled object that defines a list of permitted segments for an IDoc and the hierarchical arrangement of those segments. The IDoc type effectively defines the syntax of an IDoc.
An IDoc is the run−time instance of an IDoc type. An IDoc consists of a control record, several data records,and a list of status records. The control record defines control information such as sender and receiver information. The data records contain the application data that is to be transferred via IDocs. The status records contain status information (success or failure) recorded at each point in the process.
To read the first part of the Blog click HERE
In the next part of this blog series we will discuss how to Customize and enhance IDocs.