IDoc

he structure of IDocs is – how can we put this? – extremely complex. As a result, we don’t want to go into too much detail here. Instead, let’s simply take a look at the structure for the ORDERS05 format – i.e. an order. You can find it displayed on the following page.

The left-hand screenshot shows the general structure of the IDoc. The right-hand screenshot shows the E2EDP01006 node on its own, opened out. This node alone is more complex than everything else around it. The P stands for “Position” (German for “line item”), and each of its sub-nodes contains data for a particular line item.

We are talking about nodes here, but of course, this is only how they are represented in this particular specialist software. IDoc simply contains segments – i.e. with a record type identifier at the front followed by lots of data.

We will spare you a detailed account of this, however. Instead, we just want to make a few points:

• In principle, every IDoc will begin with a record of type EDI_DC40. The EDI in this identifier tells you that it is intended for electronic data interchange. The structure of this EDI_DC40 is always the same, regardless of what kind of IDoc you are looking at (though things can change between the different versions…). It contains basic information such as:
  • The type and version of the IDoc (e.g. ORDERS05).
  • The client of the SAP system to which it belongs.
  • The document number.
  • The message type (more on this later).
  • Information about the sender and the recipient.
  • The date/time stamp.
  • And so on.
• An IDoc type (such as ORDERS) can contain multiple message types. For example, an IDoc of the type ORDERS might contain not just an order, but also the order confirmation. This would then appear in the message type field.
• Each segment type is represented in SAP by a structure data type that defines the number, sizes, types and names of the fields in order. These structure types all have names beginning with E1, such as E1EDP01. In the record type identifier of a fixed record IDoc, the name of the record type begins with E2, giving E2EDP01 (don’t ask why…). The record type identifiers explain why the nodes in the structures above are named the way they are (with E2 at the beginning). In XML IDocs, however, the tag names once again begin with E1 because they represent a type name.
• Both IDoc types (such as ORDERS) and individual record types (e.g. EDP01) have their own versions. ORDERS05 is version 5 of the ORDERS IDoc, while EDP01007 is version 7 of the EDP01 record type. As you can see, however, there is no version number for EDK14 (the fourth node from above in the left-hand image). The basic form has been used here, rather than a modified version.
• The following rules apply to fixed record IDocs: Each segment begins with half a dozen fields containing information such as the client and the document number. Every segment of an IDoc has to have the same values here. Parent-child relationships are also established between segments. However, the hierarchical structure of the XML IDoc means that it doesn’t require these fields.
• In XML IDocs, the name of the root element is identical to the message type; after that comes one or more IDoc elements, which are in turn followed by the actual IDoc beginning with the EDI_DC40 control record.
• SAP systems are often highly customised to the needs of individual operators. When that is the case, the document types will also deviate from the standards offered by an unmodified SAP system. These are known as CIM types. In other words, IDocs of the same type and the same version can vary from SAP installation to SAP installation.

Overall, the IDoc format is more or less a table dump presented in fixed record format. Because the IDoc was originally only intended for direct communication between two SAP systems, and not for sending data in this format across the world (or to other software packages), this is perfectly fair. However, it isn’t much use to us in our day-to-day work…

Within the standard, the XML files created by an SAP XI or PI are structured in a very similar way to the fixed record IDoc (apart from the XML packaging). Record types and fields are virtually identical, aside from the header fields named above. Of course, the output format can be tweaked, in deviation from the standard IDoc. Fortunately, every SAP system is capable of outputting the format description for its own IDocs. For fixed record IDocs, these are called IDoc parser files, while XML IDocs are assigned an XML schema. You can obtain both of these through transaction WE60.

If you own an SAP system yourself, or you have partners who are threatening to send you IDocs or expect to receive them from you, you should make sure to comprehensively integrate this document type, or enable SAP communication as a whole. Ideally, your software should be able to talk directly to SAP and independently request the structures that are applicable to this particular installation (i.e. the CIM types). As we have already mentioned, SAP also offers the option to export descriptions of its structures. Your software should be able to directly import those descriptions (IDoc parser files or XML IDoc schemas). Lobster_data allows you to directly create structures from those description, in which you then can effortlessly read in the IDocs sent by your partner.