What is an Idoc?

IDoc (for intermediate document) is a standard data structure for electronic data interchange (EDI) between application
programs written for the popular SAP business system or between an SAP application and an external program. IDocs
serve as the vehicle for data transfer in SAP's Application Link Enabling (ALE) system. IDocs are used
for asynchronous transactions: each IDoc generated exists as a self-contained text file that can then be transmitted to the
requesting workstation without connecting to the central database. Another SAP mechanism, the Business Application
Programming Interface (BAPI) is used for synchronous transactions.
A large enterprise's networked computing environment is likely to connect many geographically distributed computers to
the main database. These computers are likely to use different hardware and/or operating system platforms. An IDoc
encapsulates data so that it can be exchanged between different systems without conversion from one format to another.
IDoc types define different categories of data, such as purchase orders or invoices, which may then be broken down into
more specific categories calledmessage types. Greater specificity means that an IDoc type is capable of storing only the
data required for a particular transaction, which increases efficiency and decreases resource demands.
An IDoc can be generated at any point in a transaction process. For example, during a shipping transaction process, an
IDoc may be generated that includes the data fields required to print a shipping manifest. After a user performs an SAP
transaction, one or more IDocs are generated in the sending database and passed to the ALE communication layer. The
communication layer performs aRemote Function Call (RFC), using the port definition and RFC destination specified by
the customer model. The IDoc is transmitted to the receiver, which may be an R/3, R/2, or some external system.

IDOC Programming
There are two processes in IDOC processing one is INBOUND PROCESS( IDOC coming to the
system and its handling at various stages) and the other is OUTBOUND PROCESS( IDOC is
send to other system . Separate ABAP programs are written for these 2 processes and different
configuration settings are required for each one .Depending upon the trigeering mechanism
different programming approaches are used.OUTBOUND PROGRAMS handle the IDOC creation
and INBOUND PROGRAMS handle the inbound IDOC and the data trasfer from the IDOC to the
database tables.

NEED FOR ABAP PROGRAMMING arises if

1)New IDOC was created
Depending upon the triggering mechanism i.e change pointer,message control
etc the programming technique changes and the type of process.
2)Existing IDOC was extended
User Exits are used to populate data in new segments added and to read them
back.
3)To enhance an exsiting process.
User Exits are used .
Basic structure of an OUTBOUND PROGRAM
The basic structure of all outbound programs is same. The CONTROL
record which is of TYPE EDIDC has to be filled. It contains important fields like
IDOCTP IDOC type
MESTYP Message Type
RCVPRN Recieving Partner (Destination)
RCVPRT Partner Type (it is LS i.e Logical System)

The DATA RECORD internal table which is of TYPE EDIDD has to be filled
in the same order as there are segments in the IDOC definition.
It has 2 important fields which are to be filled ,these are
SEGNAM Name of the segment
SEGDATA Data in the segment and can be upto 1000 bytes.This field
is corresponds to each data segment in the IDOC.
e.g.
DATA INT_EDIDD LIKE EDIDD OCCURS 0 WITH HEADER LINE.
DATA W_SEGDATA LIKE zsegment "custom segment zsegment

INT_EDIDD-SEGNAM = 'ZSEGMENT'
W_SEGDATA-field1 = value "taken from some table
 W_SEGDATA-field2 = value "taken from some table
INT_EDIDD-SEGDATA = W_SEGDATA
APPEND INT_EDIDD
This will fill the data record corresponding to the segment ZSEGMENT . For all
segments the sam steps will be repeated until all the data corresponding to all the
segments in the idoc is filled in the internal table of type EDIDD.
There is only one control record and can be multile data records in the idoc
structure.

Which data is to be extracted from the tables to be filled in EDIDD type internal table is
determined in standalone programs from the objects which are specified in the selection screen
and from the object key passed to the function module in case of message control and is taken
from BDCP table in case of change pointers using function modules
"CHANGE_POINTERS_READ"
In case of stand alone programs and function modules based on change pointers method the
function module "MASTER_IDOC_DISTRIBUTE" is used to send the IDOC to ALE layer for
distribution ,in case of message control it is handled automatically by the RSNASTED program
invoked by the message control.
OUTBOUND PROCESS AND OUTBOUND PROGRAM
Outbound programs are used in outbound process to genearte IDOCs . There
purpose is to extract the data from the tables and to fill the IDOC data records
and the control record in the IDOC and pass ito the ALE layer for distribution to the recieving
system .
Depending upon the triggering mechanism (how and when the outbound program will be started
different techniques and interface is used for outbound program.

1)Message control
Application like PO(purchase order) creation use this technique , where the output type is linked
to the application(Message control is a configurable cross application component which can be
set in IMG .Such programs are created in the form of function modules and linked to the output
type which is linked to the apllication.These have predefined interfaces.
In outbound programs(function module) that use message control the key of the
application document is passed to the function module whcig will read the data from the table
depending upon the key passed(NAST structure) and fill the IDOC segemnts with the application
data.The control record is also passed to the function module but is not fully filled, the rmaining
fields are filled and the control is passed back to the calling program which is RSNASTED and is
invoked by the
message control to process ALE and EDI output types and this program on recieving the IDOC
data will create the physical IDOC in the system.
The parameteers passed to the function module are
IMPORTING PARAMETERS
OBJECT LIKE NAST
It contains documents key.
CONTROL_RECORD_IN LIKE EDIDC
It contains the partailly filled control record
EXPORETING PARAMETER
OBJECT_TYPE
CONTROL_RECORD_OUT LIKE EDIDC
TABLES
INT_EDID LIKE EDIDD
The internal table used to fill the data records in the same order as they exists in
the IDOC.

The important parameters that should be filled in the custom function module are
CONTROL_RECORD_OUT and INT_EDIDD .The OBJK field of the structue NAST contains the
key of the apllication document.
2)Stand alone programs
Generally used for Master Data transfer and as such depending upon the requirement can have
different interfaces.The programs have a selection screen which has select options to select the
objects, and parameters for specifying the recipient Logical System and the Message Type.
Data is selected based on the specified objects from the tables . and control record of type
EDIDC is created and filled with important values like DIRECTION ,IDOCTP,RCVPRT,RCVPRN
and MESTYP .
Data is filled in an internal table of TYPE EDIDD according to segment definitions
and in same order and the function module MASTER_IDOC_DISTRIBUTE is called passing the
control record and the internal table containg IDOC data and importing an internal table
consisting of control records for each communication IDOCS created.

3)Change pointer
Change Pointer table is read and checked if changes were made to important fields , if so the
outbound program will be triggered automatically , these have predefined interfaces