SAP’s presence in the IT world is justified by a central premise: It turns a company’s many individual systems into one, big supersystem. More than a linking together of applications, SAP’s implementation causes a redirection of the flow of information through a company and its partner companies that enhances the potential of its business functions.
This flow of information is enabled by a core element in SAP technology: the Intermediate Document, or IDoc. Technically, the IDoc is an example of Electronic Data Interchange (EDI). Unlike conventional EDI, IDocs are not based on a descriptive language.
The IDoc concept borrows the best features of EDI and combines them with the best features of conventional transaction file formats. The result is a lean data transport mechanism that is the engine of SAP data flow, tying together applications, databases, companies, and networks. Here is a look at the makeup of IDocs within the application architecture.
Form and content: IDoc terminology
As is often the case with proprietary technologies, SAP assigns specific, object-oriented meanings to familiar terms. When referring to IDocs, the term document refers to a set of data comprising a functional group of records with a business identity. (For example, all the data in a purchase order, or all the profile information of a supplier in a supplier master record.)
A message refers to the contents of a specific implementation of an IDoc; it’s a logical reference. This differs from a reference to the IDoc itself, which specifies the message’s physical representation. Think of it this way: If you’re watching a parade pass by, the mayor waving to the crowd from his limousine is the message, and the mayor’s limousine (which is specific to the mayor) is the IDoc. You’re building a logical object, and the IDoc is both its container and the vehicle that moves it.
The IDoc control record
Each IDoc has a single control record, always the first record in the set. The structure of this record describes the content of the data records that will follow and provides administrative information, such as the IDoc’s functional category (Message Type/IDoc Type), as well as its origin (Sender) and destination (Receiver) as in conventional EDI (see Figure A).
This “cover slip” format informs the receiving system of the IDoc’s purpose, and the receiving system uses it to determine the correct processing algorithm for handling the arriving IDoc.
The data records following the control record are structured alike, including two sections: a segment information section and a data section.
In the first part of a data record, the segment information section describes the structure of the data that follows, for the benefit of the IDoc processor. There is a segment name (like an EDI segment identifier) that corresponds to a data dictionary structure to which the IDoc processor has access. The remaining information is useful for foreign systems, such as a partner company’s Oracle system, which has no such data dictionary.
The second part of the record is the data itself, a storage area of 1,000 characters.
If you’ve ever ordered a package from a faraway location and tracked its progress using the Internet-based tracking utilities now provided by most major parcel carriers, you’re familiar with the list of stops and transfer points through which a package passes on its way to you.
This collection of records is exactly what you’ll see in an IDoc that has begun its work. Following the data records in an IDoc, status records accumulate as an IDoc makes its way from one point in a process to another.
Typically, an IDoc will acquire several of these records as its does its job. They are simple records, consisting of a status code (there are more than 70 codes, covering a broad range of conditions and errors), a date/time stamp, and some additional status information fields for system audit purposes. In addition, as errors occur in the processing of an IDoc, status records (see Figure B) are used to record these errors and the date/time of their occurrence.
IDocs, as data formatting tools, enable the easy sharing of data between databases and applications within a company as well as being an efficient data courier between companies. Typically in SAP, a database of IDoc definitions exists, to which any application may have access.
This “IDoc Base” gives all the applications and processes in your company domain the capacity to send, receive, and process a document in a contextually appropriate way, without doing anything to the data. For example, a purchase order IDoc can filter through every process it touches, passing from system to system, accumulating status records to track its progress.
Every department using the data can use it appropriately without any cumbersome intermediate processes, because each department draws its key to interpreting the IDoc from the same source.
One cumbersome feature of conventional EDI is the embedding of more than one functional record type in a document. The unwieldy X-12 888 Item Maintenance transaction set is an example: It purports to handle so many different configurations of product master data that it is horrifically difficult to integrate into an existing system.
IDocs, on the other hand, handle multiple messages with ease. Given the centralized IDoc interpretation that SAP provides to all its parts, it’s no problem to define an IDoc that will contain more than one message, that is, more than one data record type.
A customer master IDoc, for example, may contain customer profile information records for a customer with many locations. But it may also contain location-specific pricing information records for that customer in the same document. This is an incredibly efficient way of bundling related records, particularly when passing large amounts of complex information from system to system (see Figure C).
There is no mastering SAP without mastering its workhorse, the IDoc. ERP environments utilizing SAP and similar platforms are made necessary in the first place by the increasing demands of ever more integrated business relationships. IDoc technology addresses this trend with a simple but powerful design philosophy: Data is no longer something to be stored; it’s something to be moved.
Scott Robinson is a 20-year IT veteran with extensive experience in business intelligence and systems integration. An enterprise architect with a background in social psychology, he frequently consults and lectures on analytics, business intelligence and social informatics, primarily in the health care and HR industries.