SAP ABAP IDOC PROCESSING

Creating and processing IDocs is primarily a mechanical task, which is certainly true for most interface programming. We will show a short example that packs SAP R/3 SAPscript standard text elements into IDocs and stores them.


Outbound IDocs from R/3 are usually created by a function module. This function
module is dynamically called by the IDoc engine. A sophisticated customising
defines the conditions and parameters to find the correct function module.

The interface parameters of the processing function need to be compatible with a
well-defined standard, because the function module will be called from within
another program.

IDoc inbound functions are function modules with a standard interface, which will
interpret the received IDoc data and prepare it for processing.

The received IDoc data is processed record by record and interpreted according to
the segment information provided with each record. The prepared data can then be
processed by an application, a function module, or a self-written program.

The example programs in the following chapters will show you how texts from the
text pool can be converted into an IDoc and processed by an inbound routine to be
stored into another system.
The following will give you the basics to understand the example:

SAP R/3 allows the creation of text elements, e.g. with transaction SO10. Each
standard text element has a control record which is stored in table STXH. The text
lines themselves are stored in a special cluster table. To retrieve the text from the
cluster, you will use the standard function module function READ_TEXT . We
will read such a text and pack it into an IDoc. That is what the following simple
function module does.

If there is no convenient routine to process data, the easiest way to hand over the
data to an application is to record a transaction with transaction SHDB and create a
simple processing function module from that recording.

Outbound routines are called by the triggering application, e.g. the RSNAST00
program.

Inbound processing is triggered by the central IDoc inbound handler, which is
usually the function module IDOC_INPUT . This function is usually activated by
the gatekeeper who receives the IDoc.


Outbound is triggered by the application.
Inbound is triggered by an external event.

The most difficult work when creating outbound IDocs is the retrieval of the application data which needs sending. Once the data is retrieved, it needs to be converted to IDoc format, only.

Each R/3 standard text element has a header record which is stored in table STXH.
The text lines themselves are stored in a special cluster table. To retrieve the text
from the cluster, you will use the standard function module function
READ_TEXT.

The program below will retrieve a text document from the text pool, convert the text
lines into IDoc format, and create the necessary control information.

The first step is reading the data from the application database by calling the
function module READ_TEXT.

Our next duty is to pack the data into the IDoc record. This means moving the
application data to the data part of the IDoc record structure EDIDD and filling the
corresponding segment information.

Finally, we have to provide a correctly filled control record for this IDoc. If the IDoc routine is used in a standard automated environment, it is usually sufficient to fill the field EDIDC-IDOCTP with the IDoc type, EDIDC-MESTYP with the context
message type and the receiver name. The remaining fields are automatically filled
by the standard processing routines if applicable.

Inbound processing is basically the reverse process of an outbound.. The received IDoc has to be unpacked, interpreted and transferred to an application for further processing.

The received IDoc data is processed record by record and data is sorted out according to the segment type.

When the IDoc is unpacked data is passed to the application.

Finally the processing routine needs to pass a status record to the IDoc processor.
This status indicates successful or unsuccessful processing and will be added as a
log entry to the table EDIDS.

The status value '51' indicates a general error during application processing and the
status '53' indicates everything is OK.