SAP IDOC'S IN ABAP INTRODUCTION

IDocs are SAP’s file format to exchange data with a foreign system.

IDocs are an ASCII file format to exchange data between computers; the format is chosen arbitrarily .

IDocs are similar to segmented files; they are not a description language like ANSI X.12, EDIFACT or XML.

The IDoc contents are processed by function modules, which can be assigned in customizing.

IDocs are structured ASCII files (or a virtual equivalent). They are the file format used by SAP R/3 to exchange data with foreign systems.

IDocs are 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.

The typical structured file has records, each record starting with a leading string that identifies the record type. Their specification is stored in the data dictionary.

IDocs is the acronym for Interchange Document. This indicates a set of (electronic)
information which builds a logical entity. An IDoc is e.g. all the data of a single
customer in your customer master data file, or the IDoc is all the data of a single
invoice.

IDoc data is usually exchanged between systems and partners that are completely
independent. Therefore, the data should be transmitted in a format that can easily be
corrected by the computer operators. It is therefore mandatory to post the data in a
human readable form.

Nowadays, this means that data is coded in ASCII format, including numbers which
are sent as a string of figures 0 to 9. Such data can easily be read with any text editor on any computer, be it a PC, Macintosh, UNIX System, S/390 or any internet
browser.

The information which is exchanged by IDocs is called a message and the IDoc is
the physical representation of such a message. The name “messages” for the
information sent via IDocs is used in the same ways as other EDI standards. .

Everybody who has ever dealt with interface programming, will find IDocs very
much like the hierarchical data files used in traditional data exchange.
International standards like the ODETTE or VDA formats are designed in the same
way as IDocs are.

Other EDI standards like XML, ANSI X.12 or EDIFACT/UN are based on a data
description language. They differ principally from the IDocs concept, because they
use a programming language syntax (e.g. like Postscript or HTML) to embed the DATA.

The IDoc process is a straight forward communication scenario. A communication is
requested, then data is retrieved, wrapped and sent to the destination in a predefined format and envelope.



An R/3 application creates data and updates the database appropriately. An
application can be a transaction, a stand-alone ABAP Report or any tool that can
update a database within R/3.

If the application thinks that data needs to be distributed to a foreign system, it
triggers the IDoc mechanism, usually by leaving a descriptive message record in the
message table NAST.

The application then either directly calls the IDoc engine or a collector job
eventually picks up all due IDoc messages and determines what to do with them.
If the engine believes that data is ready to be sent to a partner system, then it
determines the function module which can collect and wrap the required IDoc data
into an IDoc.

In IDoc customising, you specify the name of the function module to use. This can
either be one which is predefined by R/3 standard or a user-written one.
When the IDoc is created it is stored in an R/3 table and from there it is sent to the foreign system.

If the foreign system requires a special conversion, e.g. to XML, EDIFACT or X.12
then this job needs to be done by an external converter, like the Seeburger ELKE™
system. These converters are not part of R/3.

If you have to decide on a converter solution, we strongly recommend using a plain
PC based solution. Conversion usually requires a lot of fine tuning which stands
and falls with the quality of the provided tools.


Summary

The first record in an IDoc is a control record describing the content of the data
All but the first record are data records with the same formal record structure
Every record is tagged with the segment type and followed by the segment data.

The interpretation of the segment is done by the IDoc application
Both sent and received IDocs are logged in R/3 tables for further reference and archiving purposes.