What is an IDoc?

An IDoc(for intermediate document) Type is SAP's format for data being moved between like electronically. This includes how elds are grouped together (segments), the order and hierarchy of these groupings, and the format of each individual eld. If you're familiar with EDI at all, then an IDoc will look very familiar to you. Nearly everything you're used to is there: from segment name to allowable codes to min/max occurs. It is important to note that an IDoc Type is really just a structure dened on the system and given a name (i.e., ORDERS04). An actual IDoc, however, consists of data, which ts within the dened structure of the IDoc Type. This IDo

IDoc Structure
The "only once" rule
It is valuable to note that SAP only allows one occurence of each segment type within the IDoc structure. For instance, the E1EDKA1 segment may only exist once within the IDoc type. Now, does that mean you can only have one E1EDKA1 segment in an actual IDoc? Of course not. 04 IDoc.

Generic Structure
Data within an IDoc is divided 1. Control Record, which contains (Table EDIDC) 1. Key Fields (for inbound) 1. Receiving Partner Type/ID (RCVPRT, RCVPRN) 2. Logical Message Type 3. Test Flag 2. Other Fields 1. IDoc Number (DOCNUM) 2. 3. Sending Partner Type/ID (SNDPRT, SNDPRN) 4. Status 5. Receiver/Sender Port 6. Created Timestamp 7. Changed Timestamp 3. etc. 2. Data Records (Table EDID4 in 4.6C) 1. Admin Data (39 bytes)

1. IDoc Number (DOCNUM) 2. Segment Number 3. Segment Name (SEGNAM) (e.g., E1EDK01, E1EDK03, etc) 4. etc 2. Actual Data (SDATA 1,000 bytes) 3. Status Records (Table: EDIDS) 1. IDoc Number (DOCNUM) 2. Counter (COUNTR) 3. Status (STATUS) 4. etc

1. Data record table is version-specic. EDID4 is valid for the current release of SAP R/3 and may change in future versions. 2. for inbound processing. 3. Each IDoc may have several data records, which are arranged hierarchically. The data 4. Each IDoc may have several status records, which are arranged in sequence. 5. Segment Types begin with E1. This is the internal SAP format. 6. -specic format which denes how the outside world sees the segment. 7. 8. Outbound IDocs are created dir control. Most outbound documents within OTC are created by message control. 9.

Status Codes
Outbound Codes 00 Not used, only R/2 01 IDoc created 02 Error passing data to port 03 Data passed to port OK 04 of EDI subsystem Inbound Codes 50 IDoc added 51 52 53 54 Error during formal not posted fully posted

05 06 07 Error during syntax check 08 Syntax check OK 09 Error during interchange handling

55 56 IDoc with errors added 57 58 Test IDoc: Error during IDoc-Copy from an R/2

59 Not used 60 61 62 63 64 Error passing IDoc to IDoc ready to be transferred Error during syntax check of IDoc (inbound) Processing despite syntax error (inbound)

10 Interchange handling OK 11 Error during dispatch 12 Dispatch OK 13 Retransmission OK 14 15 Interchange Acknowledgement Interchange Acknowledgement

65 Error in ALE service

16

66 predecessor IDoc

17 18 Triggering EDI subsystem OK 19 Data transfer for test OK 20 Error triggering EDI subsystem 21 Error passing data for test 22 Dispatch OK, acknowledgement

67 Not used 68 Error - no further processing 69 IDoc was edited 70 Original of an IDoc which was edited

71 IDoc reloaded from archive 72 Not used, only R/2 73 IDoc archived

23 Error during retransmission

24

subsystem OK

74

IDoc was created by test

25 Processing despite syntax error (outbound) 26 Error during syntax check of IDoc (outbound) 27 Error in dispatch level (ALE service) 28 Not used 29 Error in ALE service 30 IDoc ready for dispatch (ALE service) 31 Error - no further processing 32 IDoc was edited 33 Original of an IDoc which was edited 34 Error in control record of IDoc 35 IDoc reloaded from archive 36 37 IDoc added incorrectly 38 IDoc archived 39 IDoc is in the receiving system (ALE service) 40 41 42

Beginners Guide to ALE and IDocs a step-by-step approach

This article will help you understand the basics of ALE and IDocs via a simple do-it-yourself example. We will create a custom IDoc in one SAP system and then post some business data through it to another SAP system. Business data will be picked up from custom data dictionary tables. ALE Application Link Enabling is a mechanism by which SAP systems communicate with each other and with non-SAP EDI subsystems. Thus it helps integration of distributed systems. It supports fail-safe delivery which implies that sender system does not have to worry about message not reaching the source due to unavoidable situations. ALE can be used for migration and maintenance of master data as well as for exchanging transactional data. The messages that are exchanged are in the form of IDocs or Intermediate Documents. IDocs act like a container or envelope for the application data. An IDOC is created as a result of execution of an Outbound ALE. In an Inbound ALE an IDOC serves as an input to create application document. In the SAP system IDocs are stored in the database tables. They can be used for SAP to SAP and SAP to non-SAP process communication as long as the participating processes can understand the syntax and semantics of the data. Complete documentation on IDOC is obtained by using transaction WE60. Every IDoc has exactly one control record along with a number of data records and status records. Control record has the details of sender/receiver and other control information. Data records contain the actual business data to be exchanged while the status records are attached to IDoc throughout the process as the IDoc moves from one step to other. Now, let us understand the ALE Configuration by means of an example scenario below: The Scenario Data from custom tables (created in customer namespace) is to be formatted into an IDoc and sent from one SAP R/3 system to another using ALE service. We need to have two instances of SAP R/3 systems or we can simulate this on two clients of the same SAP R/3 system. Create three tables as shown below.

Creating Custom IDoc type and Message type All the objects created should be present on both source as well as target system(s). 1. Create segments Transaction WE31

Create a segment ZRZSEG1 Add all fields of table ZCUSTOMERS to it Save the segment and go back Release it using the menu path Edit -> Set Release Similarly create two more segments given below Seg. ZRZSEG2 to hold all fields of table ZSOHEADERS Seg. ZRZSEG3 to hold all fields of table ZSOITEMS

2. Create Basic IDoc type Transaction WE30

Create a Basic type ZRZORDER Add the created segments in the hierarchy shown Maintain attributes for each of the segments Save the object and go back Release the object using the menu path Edit -> Set Release

3. Create/Assign Message type Transactions WE81/WE82

Go to WE81 Create a new Message type ZRZSO_MT Save the object Go to WE82 and create new entry Assign the message type ZRZSO_MT to the basic type ZRZORDER Also specify the Release Version Save the object

Thus we have defined the IDoc structure which will hold the data to be transferred. In the next part of the article we will understand the outbound settings, i.e. the settings to be done in the source system.

Part II
In the previous part we created an IDoc structure which can carry our data from source system to target system(s). In this part we will understand how to setup the source system to be able to generate and send an outbound IDoc. Outbound Settings Define Logical Systems and Assign Client to Logical System Transaction SALE

Go to Define Logical System (See the figure) Define a new logical system to identify the local system and save it Now, go to Assign Client to Logical System (See the figure)

Add a new entry Specify the client, previously created logical system and other attributes Save the entry Define a new logical system to identify the partner system and save it

Maintain RFC Destinations Transaction SM59

Create a new RFC destination for R/3 type connection Specify the target host on Technical settings tab Provide the Logon credentials on the Logon/Security tab Save the settings To verify the settings, Click on Test connection or Remote logon

Define Ports Transaction WE21

We need to define a tRFC port for the partner system Click on Transactional RFC node Create a new port Provide a description Specify the name of the target RFC destination

Save the object

Maintain Distribution Model Transaction BD64

Click on Change Create a new model view Provide a Short text and Technical name to the model view Add message type Specify sender and receiver systems Also, specify the message type that we created previously Save the Distribution model

Generate/Create Partner Profile Transactions BD82/WE20

To generate Partner profiles automatically you may use BD82 or go to BD64 and use the menu path Environment -> Generate partner profiles o Otherwise, you may use transaction WE20 to create a partner profile On selection screen, specify the model view, target system and execute The result log will be displayed on the next screen To verify the partner profile go to WE20 Check the partner profile for the target system

Distribute Model View Transaction BD64

Select the Model View Go to menu path Edit -> Model View -> Distribute Result log will be displayed on the next screen

Outbound IDoc Generation Program Create an executable program ZRZ_ORDER_IDOC in SE38. Below, I have described the program logic:

Fetch the data from the DDic tables ZCUSTOMERS, ZSOHEADERS and ZSOITEMS as per the selection criteria Fill the control record structure of type EDIDC o Specify message type, Basic IDoc type, tRFC Port, Partner number and Partner type of the receiver Fill the data records o Define structures like the IDoc segments o Fill the structures with fetched data o Pass the segment name and the above structure to the appropriate fields of EDIDD type structure o Append the EDIDD structure to the EDIDD type internal table Now, call the function module MASTER_IDOC_DISTRIBUTE and pass the IDoc control record structure and data record table Commit work if return code is zero Function module returns a table of type EDIDC to provide the details about generated IDoc Display appropriate log

You can download sample code for the above program here. Thus we have completed sender side configuration required for ALE. In the next part we will see how to configure the receiving system to be able to receive and post the inbound IDoc.

Part III
In the previous parts we learned how to create a custom IDoc and set up the source system to send an outbound IDoc. In this part we will learn how to configure the receiving SAP R/3 system to be able to receive and post the inbound IDoc. Inbound IDoc Posting Function Module In the receiving system, create a function module Z_IDOC_INPUT_ZRZSO_MT using SE37. Below, I have described the logic for the same. Add Include MBDCONWF. This include contains predefined ALE constants. Loop at EDIDC table

Check if the message type is ZRZORDER. Otherwise raise WRONG_FUNCTION_CALLED exception Loop at EDIDD table o Append data from the segments to appropriate internal tables o For example: append data from ZRZSEG1 segment to the internal table of type ZCUSTOMERS

Update the DDic tables from internal tables Depending on the result of the update, fill the IDoc status record (type BDIDOCSTAT) and append it to the corresponding table. o Status 53 => Success o Status 51 => Error

You can download the sample ABAP code for the above function module here. Inbound Settings

Define Logical Systems Transaction SALE (Please refer to Outbound Settings discussed in previous part) Assign Client to Logical System Transaction SALE (Please refer to Outbound Settings discussed in previous part) Maintain RFC Destinations Transaction SM59 (Please refer to Outbound Settings discussed in previous part) Define Ports Transaction WE21 (Please refer to Outbound Settings discussed in previous part) Generate/Create Partner Profile Transactions BD82/WE20 (Please refer to Outbound Settings discussed in previous part) Assign Function Module to Logical message Transaction WE57 o Create a new entry o Specify name of the Function Module as Z_IDOC_INPUT_ZRZSO_MT o Also, specify Type as F, Basic IDoc type as ZRZORDER, Message type as ZRZSO_MT and Direction as 2 (Inbound) o Save the entry Define Input method for Inbound Function Module Transaction BD51 o Create a new entry o Provide Function Module name as Z_IDOC_INPUT_ZRZSO_MT o Specify the Input method as 2 o Save the entry Create a Process Code Transaction WE42 o Create a new Process Code ZPCRZ o Select Processing with ALE Service o Choose Processing type as Processing by function module o Save the entry o On the next screen, select your function module from the list o Save the changes o Now you will be taken to the next screen o Double-click on Logical message o In the Assignment to logical message, specify the message type ZRZSO_MT o Save the changes

Send and receive data On the sender system, execute the IDoc Generation Program. Check the status of IDoc using transaction WE02.

Check the status of the IDoc in the receiver system using transaction WE02. You can also check the contents of DDic tables to make sure that the records have been created in the receiver system.

Thus to summarize we have learned how to:

Create a custom IDoc Write an Outbound IDoc Generation Program Write Inbound Function Module to post Inbound IDoc Configure and test ALE scenario to transmit data between systems distributed across the network.