Introduction to IDOC interface

Introduction to IDOC interface.

The main objective of an implementation of SAP R/3 ERP is to group all the functions of a company together in a single system. But it is almost impossible to hold all data related to an organization in a single system due to load balancing, task segmentation and risk distribution. So the data stored in different landscapes and mostly in different heterogeneous systems. To communicate through all these distributed heterogeneous systems SAP has designed its own communication tool.

Application Linking and Enabling (ALE) is a technology to create and run distributed applications. ALE is proprietary of SAP. Through ALE controlled exchange of data messages occurs, it also ensures data consistency across loosely coupled applications. ALE communication occurs from SAP side and EDI (Electronic data interchange) from the non-SAP side. ALE supports fail safe delivery which means the sender system does not worry about message not reaching the source due to unavoidable situations. The message is exchanged in the form of IDOC (Intermediate document which contains application data).

An IDOC is created as a result of execution of outbound ALE (Going to other system) whereas in inbound ALE (Coming in from other System) an IDOC serves as an input to create application data.

An IDOC can be generated at any point of transaction. After a user performs a transaction one or more IDOC can be generated in the sending database and passed to the ALE layer. The ALE communication layer performs RFC check through port definition and RFC destination specified in customer model and then IDOC is transmitted to the receiver.

Every IDOC has exactly one control record along with a number of data records and status records.

Prerequisite before IDOC data processing.

1.  Create Segments (WE31) and release them – Adding fields from a table or structure

2.       Create Basic IDOC type by assigning several segments (WE30).

3.       Create message type (WE81) and assign basic type to message type (WE82).

4.       Define Logical System (SALE).

5.       Maintain RFC destination (SM59) and test remote login using target system details.

6.       Define Ports (WE21).

7.       Maintain distribution model (BD64).

8.       Generate client profile (BD82/WE20) and assign RFC system, Target System and message type.

9.       Distribute model view (BD64).

Sender System /Outbound Programming.

1.       Fetch Data from data base table in to internal table.

2.       Fill the control record of EDIDC type. (Control record contains message type, basic type, RFC port, Partner type, Partner number)

3.       Fill data record of EDIDD. (Fill segments and pass segment to data record)

4.       Call function module MASTER_IDOC_DISTRIBUTE and pass control record structure and data record table.

5.       Commit work.

Receiver System /Inbound Programming.

1.       Create a FM and include MBDCONWF which has predefined ALE constants.

2.       The FM has import the EDIDD type data table and updates DDIC table.

3.       Fill and export status record of type BDIDCOSTAT.

4.       The function module is assigned to logical message (WE57).

5.       Input method for Inbound FM is set in BD51 and process code in WE42.

Message type gives the meaning of the IDOC. IDOC type indicates the SAP format that is to interpret the data of a business transaction. There are certain standard message types which we normally use. They are:

1.       MATMAS – Material Master

2.       CRMAS – Vendor Master

3.       COND_A - Condition Record

4.       INFREC - Info Record

5.       SRCLST – Source List

Interface Programming Steps:

1.       Application Document created when a transaction is saved

2.       Message control is invoked

3.       Message processed by system

4.       ALE/EDI Output is checked

5.       Validated against message control record from partner profile.

6.       Application document is saved

7.       NAST table entry created

8.       Processing program is determined

9.       Read partner profile and get process code

10.   Invoke FM of process code

11.   IDOC generated and saved in database

12.   In the receiving system EDI system creates IDOC from Edi message

13.   FM EDI_DATA_INCOMING is called

14.   Control record validated

15.   IDOC generated and through process code Application document posted

What shall I do when I get an IDOC error?

1.       Go to transaction WE02 and enter IDOC number (Remove date if date is not known)

2.       Go to the third section of the IDOC i.e. status record.

Some popular status message numbers are:

53- Success

51- Error

12- Dispatch OK

68- Unnecessary IDOC

03- Passed to port

3.    Copy the message number and paste it in SE91 to know the error details.

4.  Check partner profile in WE20, double click message type and go to process code, Search error message and put a break point.

5.     Go to BD87, enter IDOC number, execute, select error message, process.

Inbound IDOC can be selected and executed through WE19. There are few programs through which outbound IDOCs can be processed. They are:

Ø  RBDAGAIN – Process outbound IDOC with error

Ø  RBDAGAIE  - Reprocess edited IDOC

Ø  RBDAGAI2 – Reprocess after ALE input error

To trace IDOC of the receiving system from sending system, execute BD87 and note start & end time for  IDOC execution  and for the respective message type trace it. To trace IDOC based on data, go to WE09 and use message type, segment name, field name. Use search value in value field and execute.

Miscellaneous:

IDOC information gets stored in

1.       EDIDC – Control Record

2.       EDID4 – Data record

3.       EDIDD – Data Segment

4.       EDIDS – Status Record

 Message type gives the meaning of the IDOC whereas IDOC type indicates the SAP format that is to be interpreting the data of a business transaction.

Process code refers to the workflow or the function module which helps in reading or writing data from/to IDOC. Outbound process code read application data and places the same in IDOC. Inbound process code read IDOC and create application data.

Scenario:  Consider a scenario where you want to send material master from one system (SYS A) to another system (SYS B). The standard IDOC for material master is MATMAS.

1.   Outbound processing-

You need to send the material master (MATMAS) from SYS A to SYS B. For sending this IDOC there is a standard program RBDSEMAT (Tcode: BD10). If we need to send some data for which there is no standard IDOC available we need to create a new IDOC and do coding for sending it. Here we use WE82 for outbound message type & WE41 for outbound process code. We can use program RBDMIDOC to generate master IDOCs & communication IDOCs. We can also use program RSEOUT00, to trigger IDOC manually after collecting IDOCs. We can use RBDAPP01 to trigger IDOC in background.

2.    Inbound processing –

When the MATMAS IDOC comes in the receiving system (SYS B), that master data needs to be created (posted) in the receiving system. For that a function module will be there. For custom IDOC we need to create the function module to post. When we receive IDOC from our customer, & we need to convert IDOC into application document. Suppose think that we received ORDERS05 which is a standard IDOC, this will be posted as purchase order in ME22N.Here we use WE81 for inbound message type & WE42 for inbound process code.

3.    Change pointers –

In some scenarios we need send to the IDOC only if the master data changes. For sending when the master data changes we use program RBDMIDOC. This is known as triggering through change pointers.

4.    Distribution model –

Suppose we want to send changes in material master to different clients, that we will do by defining a customer distribution model (BD64) & define all clients here. We use t/codes

BD61 (Activate change pointers globally)

BD50(Activate  change pointers for a message type)

BD52(Activate  change pointers for fields)

& at-last run program RBDMIDOC to distribute IDOCs to these clients.