IDOC design and Processing

IDocs are usually created in a four step process: retrieving the data, converting it to IDoc format, adding a control record, and delivering the IDoc to a port.

Collect data from R/3 database :

This is the single most important task in outbound processing. You have to identify
the database tables and data dependencies which are needed in the IDoc to be sent.
The smartest way is usually to select the data from the database into an internal table using SELECT * FROM dbtable INTO itab ... WHERE ...

Wrap data in IDoc format :

The collected data must be transformed into ASCII data and filled into the predefined IDoc segment structures. The segment definitions are done with transaction WE31 and the segments allowed in an IDoc type are set up in transaction WE30. Segments defined with WE31 are automatically created as SAP DDIC structures. They can be viewed with SE11, however, they cannot be edited.

Create the IDoc control record :

Every IDoc must be accompanied by a control record which must contain at least the Idoc type to identify the syntactical structure of the data and the name and role of the sender and the receiver. This header information is checked against the partner definitions for outbound. Only if a matching partner definition exists, can the IDoc be sent. Partner definitions are set up with transaction WE20.

Send data to port :

When the partner profile check matches, the IDoc is forwarded to a logical port, which is also assigned in the partner profile. This port is set up with transaction
WE21 and defines the medium to transport the IDoc, e.g. file or RFC.
The RFC destinations are set up with transaction SM57 and must also be entered in table TBDLS with an SM31 view. Directories for outbound locations of files are set up
with transaction FILE and directly in WE21. It also allows the use of a function
module which generates file names. Standard functions for that purpose begin like
EDI_FILE*.

How SAP Standard Processes Inbound IDocs :

When you receive an IDoc the standard way, the data is stored in the IDoc base and a function module is called, which decides how to process the received information.

EDID4 - Data :

Data is stored in table EDID4 (EDID3 up to release 3.xx, EDIDD up to release 2.xx)

EDIDC - Control Record :

An accompanying control record with important context and administrative
information is stored in table EDIDC.

Event signals readiness :

After the data is stored in the IDoc base tables, an event is fired to signal that there is an IDoc waiting for processing. This event is consumed by the IDoc handler, which decides, whether to process the IDoc immediately, postpone processing, or decline activity for whatever reason.

EDIFCT - Processing function :

When the IDoc processor thinks it is time to process the IDoc it will search the table EDIFCT , where it should find the name of a function module which will be called to process the IDoc data.

This function module is the heart of all inbound processing. The IDoc processor will
call this routine and pass the IDoc data from EDID4 and the control record from
EDIDC for the respective IDoc.

Function has a fixed interface :

Because this routine is called dynamically, it must adhere to a strict convention All
function interface parameters must exactly match the calling convention.

EDIDS - Status log :

The processing steps and their respective status results are stored in table EDIDS.

Status must be logged properly :

In addition, the routine has to properly determine the next status of the IDoc in table EDIDS; usually it will be EDIDS-STATU = 53 for OK or 51 for error.

(74)

RELATED POSTS