What is an IDOC

IDOC is simply a data container used to exchange information

between any two processes that can understand the syntax and semantics
of the data.

In other words, an IDOC is like a data file with a specified format which
is exchanged between 2 systems which know how to interpret that data.

IDOC stands for "Intermediate Document"

When we execute an outbound ALE or EDI Process, an IDOC is

created.

In the SAP System, IDOCs are stored in database. Every IDOC has an
unique number (within a client).

Key Features

 IDOCs are independent of the sending and receiving

systems.(SAP-to-SAP as well as Non-SAP)

 IDOCs are based on EDI standards, ANSI ASC X12 and EDIFACT. In
case of any conflict in data size, it adopts one with greater length.
 IDOCs are independent of the direction of data exchange e.g.
ORDERS01 : Purchasing module : Inbound and Outbound

 IDOCs can be viewed in a text editor. Data is stored in character

format instead of binary format.

Structure of an IDOC
 The Idoc structure consists of 3 parts

1. The administration part (Control Record)- which has the type of

idoc, message type, the current status, the sender, receiver etc.
This is referred to as the Control record.

2. The application data (Data Record) - Which contains the data.

These are called the data records/segments.

3. The Status information (Status Record)- These give you

information about the various stages the idoc has passed through.

You can view an IDOC using transaction WE02 or WE05

As seen in screenshot above IDOC record has three parts Control , Data
and Status.

Lets look into them in detail - Control Record

 All control record data is stored in EDIDC table. The key to this
table is the IDOC Number
 It contains information like IDOC number, the
direction(inbound/outbound), sender, recipient information,
channel it is using, which port it is using etc.
 Direction '1' indicates outbound, '2' indicates inbound.

Data Record

 Data record contains application data like employee header info,

weekly details, client details etc
 All data record data is stored in EDID2 to EDID4 tables and EDIDD
is a structure where you can see its components.
  It contains data like the idoc number, name and number of the
segment in the idoc, the hierarchy and the data
 The actual data is stored as a string in a field called SDATA, which
is a 1000 char long field.

Status Record

 Status record is attached to an IDOC at every milestone or when it

encounter errors.
 All status record data is stored in EDIDS table.
 Statuses 1-42 are for outbound while 50-75 for inbound

IDOC Types
An IDOC Type (Basic) defines the structure and format of the business
document that is to be exchanged.

An IDOC is an instance of an IDOC Type , just like the concept of

variables and variables types in programming languages.

You can define IDOC types using WE30

What is a Segment?

Segment defines the format and structure of a data record in IDOC.

Segments are reusable components.

For each segment SAP creates

 Segment Type (version independent)

 Segment Definition (version dependent)
 Segment Documentation
The last 3 characters is the version of the segment

Definitions keep changing as per the version but the segment type
remains the same.

Transaction :WE31

What is Extension IDOC type?

An IDOC is of 2 types:-

1. Basic
2. Extension
SAP provides many a pre-defined Basic IDOC Types which cannot be
modified.

In case you want to add more data to these restricted basic type you may
use an extension type. Most of the times you will NOT use extension.

(01 TO 49) = OUTBOUND

(50 TO 99) = INBOUND.

Documentation

Each IDOC are thoroughly documented in transaction WE60

Message Type

A message represents a specific type of document that is transmitted

between two partners Ex. Orders,orders responses,invoices etc

An idoc type can be associated with many message types

Also a message type can be associated with different idoc types.

Transaction WE81

IDOC Views
An IDOC type can be used for more than one message type, which
results in IDOCs containing more fields than required for a particular
message type.

IDOC views are used to improve performance in generating IDOCs to

ensure only the relevant segments are filled with data. IDOC Views are
important only for Outbound Processing.

Partner Profiles
A partner is defined as a business partner with whom you conduct
business and exchange documents

In the partner profile of a partner that we exchange Idocs with, we

maintain the parameters that are necessary for exchanging the data. The
transaction used is WE20.
 Port
The port defines the technical characteristics of the connection between
your SAP system and the other system you want to transfer data with
(subsystem).

The port defines the medium in which data is exchanged between the 2
systems.

There are different types of ports. The 2 most commonly used are the
TRFC ports used in ALE and File ports which EDI uses.

For TRFC ports we have to give the name of the logical destination
created using SM59.

When using file port you can specify the directory where the IDOC file
should be placed. The other system or the middleware will pick up the
file from here. The Function module can be used to generate a file name
for the idoc. While testing you can use "Outbound file" to specify a
constant file name. The tab "outbound trigger" can be used to supply
information if we want to trigger some processing on the subsystem
when an idoc is created at this location. We have to specify the
command file name and the directory which has to be run.
 This is so CONFUSING!

Lets understand the process of creating an IDOC with an example -

 Whenever a Purchase Order (PO) is created we want to send the

IDOC to a vendor.

 The PO is sent in the form of an IDOC to the vendor (partner).

That partner has to be EDI enabled in that system. SAP should
realize that it could send Idoc to this vendor electronically.

 The PO sent as an outbound idoc by the customer and

will be inbound idoc for the vendor.

The SAP system on the vendors side can process this to create an
application document (a sales order) on their system.

 Quotation, RFQ, PO, SO, Invoice, delivery note etc are some of
the commonly exchanged documents through IDOC

The process of data transfer out of your SAP system is called the
Outbound process,

while that of data moving into you SAP system is called Inbound
process.

As a developer or a consultant who will be involved in setting up theses

process for your organization. Here are the steps how to set them up-
The Outbound Process

Steps Involved -

1. Create segments(WE31)
2. Create an idoc type(WE30)
3. Create a message type (WE81)
4. Associate a message type to idoc type(WE82)
5. Create a port(WE21)
6. If you are going to use the message control method to trigger idocs
then create the function module for creating the idoc and associate
the function module to an outbound process code
7. Otherwise create the function module or stand alone program
which will create the idoc
8. Create a partner profile(WE20) with the necessary information in
the outbound parameters for the partner you want to exchange the
idoc with.Trigger the idoc.

The Inbound Process

Steps Involved-

1. Creation of basic Idoc type (Transaction WE30)

2. Creating message type (Transaction WE81)
3. Associating the Message type to basic Idoc type (Transaction
WE82)
4. Create the function module for processing the idoc
5. Define the function module characteristics (BD51)
6. Allocate the inbound function module to the message type(WE57)
7. Defining process code (Transaction WE42)
8. Creation of partner profile (Transaction WE20)
==================================
IDOC Process
All About IDOC:Definition, Architecture, Implementation

What is an IDOC?

IDOC is simply a data container used to exchange information

between any two processes that can understand the syntax and semantics
of the data.

In other words ,an IDOC is like a data file with a specified format which
is exchanged between 2 systems which know how to interpret that data.

IDOC stands for " Intermediate Document"

When we execute an outbound ALE or EDI Process, an IDOC is

created.

In the SAP System, IDOCs are stored in database.Every IDOC has an

unique number(within a client).

Key Features

 IDOCs are independent of the sending and receiving

systems.(SAP-to-SAP as well as Non-SAP)
 IDOCs are based on EDI standards, ANSI ASC X12 and EDIFACT. In
case of any conflict in data size, it adopts one with greater length.
 IDOCs are independent of the direction of data exchange e.g.
ORDERS01 : Purchasing module : Inbound and Outbound
 IDOCs can be viewed in a text editor. Data is stored in character
format instead of binary format.
Structure of an IDOC

The Idoc structure consists of 3 parts -

4. The administration part(Control Record)- which has the type of

idoc,message type, the current status, the sender, receiver etc.
This is referred to as the Control record.

5. The application data (Data Record) - Which contains the data .

These are called the data records/segments.
 6. The Status information (Status Record)- These give you
information about the various stages the idoc has passed through.

You can view an IDOC using transaction WE02 or WE05

As seen in screenshot above IDOC record has three parts Control , Data
and Status. Lets look into them in detail - Control Record

 All control record data is stored in EDIDC table. The key to this
table is the IDOC Number
 It contains information like IDOC number, the
direction(inbound/outbound), sender, recipient information,
channel it is using, which port it is using etc.
 Direction '1' indicates outbound, '2' indicates inbound.

Data Record

 Data record contains application data like employee header info,

weekly details, client details etc
  All data record data is stored in EDID2 to EDID4 tables and EDIDD
is a structure where you can see its components.
 It contains data like the idoc number, name and number of the
segment in the idoc, the hierarchy and the data
 The actual data is stored as a string in a field called SDATA, which
is a 1000 char long field.

Status Record

 Status record are attached to an IDOC at every milestone or when

it encounter errors.
 All status record data is stored in EDIDS table.
 Statuses 1-42 are for outbound while 50-75 for inbound

IDOC Types

An IDOC Type (Basic) defines the structure and format of the business
document that is to be exchanged. An IDOC is an instance of an IDOC
Type , just like the concept of variables and variables types in
programming languages. You can define IDOC types using WE30

What is a Segment?

Segment defines the format and structure of a data record in IDOC.

Segments are reusable components.

For each segment SAP creates

 Segment Type (version independent)

 Segment Definition (version dependent)
 Segment Documentation

The last 3 characters is the version of the segment

Definitions keep changing as per the version but the segment type
remains the same.

Transaction :WE31

What is Extension IDOC type ?

An IDOC is of 2 types:-

3. Basic
4. Extension
SAP provides many a pre-defined Basic IDOC Types which can not be
modified. In case you want to add more data to these restricted basic
type you may use an extension type. Most of the times you will NOT
use extension.
Documentation

Each IDOC are thoroughly documented in transaction WE60

Message Type

A message represents a specific type of document that is transmitted

between two partners Ex. Orders,orders responses,invoices etc

An idoc type can be associated with many message types

Also a message type can be associated with different idoc types.

Transaction WE81
IDOC Views

An IDOC type can be used for more than one message type, which
results in IDOCs containing more fields than required for a particular
message type.
IDOC views are used to improve performance in generating IDOCs to
ensure only the relevant segments are filled with data. IDOC Views are
important only for Outbound Processing.
Partner Profiles

A partner is defined as a business partner with whom you conduct

business and exchange documents

In the partner profile of a partner that we exchange Idocs with, we

maintain the parameters that are necessary for exchanging the data. The
transaction used is WE20.
Port

The port defines the technical characteristics of the connection between

your SAP system and the other system you want to transfer data with
(subsystem). The port defines the medium in which data is exchanged
between the 2 systems.

There are different types of ports. The 2 most commonly used are the
TRFC ports used in ALE and File ports which EDI uses.

For TRFC ports we have to give the name of the logical destination
created using SM59.

When using file port you can specify the directory where the IDOC file
should be placed. The other system or the middleware will pick up the
file from here. The Function module can be used to generate a file name
for the idoc. While testing you can use "Outbound file" to specify a
constant file name. The tab "outbound trigger" can be used to supply
information if we want to trigger some processing on the subsystem
when an idoc is created at this location. We have to specify the
command file name and the directory which has to be run.

This is so CONFUSING!

Lets understand the process of creating an IDOC with an example -

 Whenever a Purchase Order (PO) is created we want to send the

IDOC to a vendor.
 The PO is sent in the form of an IDOC to the vendor (partner).
That partner has to be EDI enabled in that system. SAP should
realize that it could send idoc to this vendor electronically.
 The PO sent as an outbound idoc by the customer will be inbound
idoc for the vendor. The SAP system on the vendors side can
process this to create an application document (a sales order) on
their system.
 Quotation, RFQ, PO, SO, Invoice, delivery note etc are some of
the commonly exchanged documents through IDOC
The process of data transfer out of your SAP system is called the
Outbound process , while that of data moving into you SAP system is
called Inbound process. As a developer or a consultant who will be
involved in setting up theses process for your organization. Here are the
steps how to set them up-

The Outbound Process

Steps Involved -

9. Create segments(WE31)
10. Create an idoc type(WE30)
11. Create a message type (WE81)
12. Associate a message type to idoc type(WE82)
13. Create a port(WE21)
14. If you are going to use the message control method to trigger
idocs then create the function module for creating the idoc and
associate the function module to an outbound process code
15. Otherwise create the function module or stand alone program
which will create the idoc
16. Create a partner profile(WE20) with the necessary
information in the outbound parameters for the partner you want to
exchange the idoc with.Trigger the idoc.

The Inbound Process

Steps Involved-

9. Creation of basic Idoc type (Transaction WE30)

10. Creating message type (Transaction WE81)
11. Associating the Message type to basic Idoc type (Transaction
WE82)
12. Create the function module for processing the idoc
13. Define the function module characteristics (BD51)
14. Allocate the inbound function module to the message
type(WE57)
 15. Defining process code (Transaction WE42)
16. Creation of partner profile (Transaction WE20)

==================================
IDoc Basics For Functional Consultants
ABSTRACT

Today IDocs are used in most SAP applications for transfer of

message(information) from SAP system to other systems and
vice versa. Though lot of documentation is available on IDocs it is
difficult for a functional consultant to understand such documents
due to their technical nature. While a functional consultant is
not expected to know the IDoc concepts in its entirety, an effort
has been made to capture the minimum necessary information
that one needs to be aware of in order to handle project/support
issues on IDocs.

OVERVIEW

IDoc is an SAP object that carries data of a business transaction from one
system to another in the form of electronic message. IDoc is an acronym
for Intermediate Document. The purpose of an IDoc is to transfer data or
information from SAP to other systems and vice versa. The transfer from
SAP to non-SAP system is done via EDI (Electronic Data Interchange)
subsystems whereas for transfer between two SAP systems, ALE is used.

IDoc can be triggered in SAP system or in EDI subsystem. This depends

on the direction in which IDoc is sent and is called as Inbound IDoc and
Outbound IDoc accordingly.
In case of outbound flow, IDoc is triggered in SAP through document
message control which is then sent to EDI subsystem. EDI converts the
data from IDoc into XML or equivalent format and then sends the data to
partner system through Internet.

For inbound flow, EDI converts partner data and IDoc is created in SAP.
After successful processing of this IDoc, Application Document is posted in
SAP.

EDI STANDARDS AND IDOC

“EDI is electronic exchange of business document between the computer

systems of business partners, using a standard format over a
communication network”. EDI stands for Electronic Data Interchange.

For transmission of information electronically, two widely used standards

are ANSI ASC X12 and EDIFACT.

ANSI ASC X12 is a committee formed by representatives of major

organizations, government bodies and EDI software companies which
defines standards and guidelines for information interchange over EDI.

UN/EDIFACT stands for United Nations EDI for Administration, commerce

and Transport and was formed in 1985 using ANSI X12 and UNTDI (United
Nations Trade Data interchange) as base standards. ANSI X12 describes
business document as transactions and each transaction is represented by
three digit number e.g. 850 – Purchase Order, 855 - Purchase Order
Acknowledgement. EDIFACT describes business document as messages,
represented by standard names e.g. ORDERS for purchase order.
IDOC TERMINOLOGIES

IDOC (BASIC) TYPE

IDoc Types are based on the EDI standards and mostly on EDIFACT
standards.

Basic Types (or IDoc Type) defines the structure of an IDoc. Each basic
type describes standard IDoc segments, format of data fields and their size.
Basic Type also defines number of segments and fields in an IDoc. All the
fields that are necessary for transmission of message for a particular
business transaction are mapped in different segments. It also defines the
structure and relationship of IDoc segments along with mandatory and
optional segments.
IDOC EXTENSION

Basic type contains all the standard fields that are necessary for carrying
out a business transaction. However, if any additional values are to be sent
to the partner then we can make use of the IDoc Extension feature. IDoc
extension is extension of basic type and contains additional custom IDoc
segments and fields that are not available in standard basic type.

IDOC SEGMENTS

IDoc segments contain the actual data that is sent to or received from a
partner. These segments contain the actual values that are sent as part of
IDoc transmission.

PARENT AND CHILD SEGMENTS

IDoc segment is termed as Parent segment if it contains its own segments.

The dependent segments are called as child segments.
INBOUND/OUTBOUND IDOCS

IDocs sent outside the system are termed as Outbound IDocs and the ones
that are received into the system, are called as Inbound IDocs.

IDOC DIRECTION

This signifies the direction is which information is sent and is similar to

terminology used in mails. If information is sent outside the system then the
direction is outbox when it is received into the system then direction is
inbox. In SAP Outbox direction is represent by “1” i.e. outbox and Inbox
direction is represented by “2”.

PARTNER

Partner is the Business Partner with which the exchange of information is

to take place using IDoc. It can be a vendor or customer or any other
system. Depending on the direction of information in which the information
is sent it plays a role of either a “sending partner” or a “receiving partner”.

PARTNER TYPE

Partner type/role is used to identify partners within the sap systems.

Partner type is KU for customer, LI for vendor and LS for Logical System.

MESSAGE TYPE
IDoc processing involves transmission or receipt of document in the form of
a message, each of which represents a document in SAP. These
documents can be Order, Shipment Confirmation, Advance Shipping
Notification, Goods Receipt, or Invoice. Message type is associated with
Basic IDoc Type (Basic Type) and defines the kind of data or document
that is exchanged with the partner.

PROCESS CODE

The process code contains the details of the Function Module that are used
for IDoc processing. Message Type can be linked to the Process code.

PORT

IDoc Port contains the information about the way data is sent between the
source or target system. The type of port defines the information contained
within the port. For port type “Internet” Port will contain IP address of the
target system. For port type “file”, directory or file name information is
maintained. “tRFC” port contains information about the RFC destination of
the target system. For IDoc transmission using ALE “tRFC” ports are used.

PARTNER PROFILE MAINTENANCE

PARTNER PROFILE (WE20)

Partner profile must be maintained for all the business partners to whom
we want to send or receive the IDocs. The TCODE for maintaining the
partner profile is WE20.
Double clicking on the Partner will show the following screen:

Partner profile contains parameters for Inbound and Outbound processing

of IDocs. For each message type we can maintain, inbound/outbound
options, message control, post processing options and contact information
within Inbound and outbound parameters.

OUTBOUND OPTIONS (OUTBOUND PARAMETERS)

This involves sender/receiver port, Output mode and relation to IDoc type
i.e. Basic Type and extension.

MESSAGE CONTROL (OUTBOUND PARAMETERS)

This contains application for which IDoc will be created e.g. EF for
Purchase order, the message type of the application that will trigger the
IDoc and Process Code that will convert SAP document to an IDoc. For
example, if PO is to be sent to the Vendor AXXXXZ, then in the outbound
option of the partner AXXXXZ we need to maintain the message type ZXX1
and link it to the Process Code ME10. So when message type ZXX1 is
triggered in the PO then an IDoc will be created for the partner vendor
AXXXXZ.

Process Code is linked to the Function Module in SAP that converts

application data into an IDoc. Standard function modules are provided by
SAP for this conversion however these can also be customized as per
business needs.

Change Message Indicator indicates whether the IDoc is sent as a

notification of change. For example, Purchase Order change messages are
sent to vendor using EDI standard message type 860.
Separate message type should be triggered in the purchase order for PO
change. Additional line with change message type must be added in the
Message control tab with change message indicator on.

INBOUND OPTIONS (INBOUND PARAMETERS)

For inbound options process code is maintained in the Inbound screen

only. IDoc processing can be triggered by background program and
triggered immediately.
POST PROCESSING (INBOUND/OUTBOUND PARAMETERS)

In the post processing option we can maintain the workflow details of the
users or positions to which an error notification will be sent if an IDoc
processing fails.

TELEPHONY (INBOUND/OUTBOUND PARAMETERS)

We can also maintain the contact details in the telephony option.

EDI STANDARD (OUTBOUND PARAMETERS)

EDI standard screen contains the details of the Standard EDI terminology
used for the IDoc transmission.

For example, Message Type 850 is an EDI standard for Purchase Order
IDoc and is linked to IDoc Message Type Orders.

IDOC STRUCTURE AND RECORDS

STRUCTURE

IDoc structure is divided into Control Record, Data Records and Status
records.
These records are stored in the transparent tables in SAP. These are
EDIDC, EDID4 and EDIDS.

CONTROL RECORD (EDIDC)

It contains information such as IDoc number, direction, IDoc Status, Basic

Type, Message Type, Partner (Sender/Receiver), date and time of
creation/update, Interchange File or ISA number,etc.
DATA RECORD (EDID4)

It contains the details of the IDoc segments.

IDoc segment has fields that contain the data necessary for posting the
documents.
STATUS RECORDS (EDIDS)

IDoc Status defines the processing status of the IDoc. IDoc statuses are
used to track the IDoc and its various processing states. Status Numbers
represents IDoc status. Current status of the IDoc is present in Control
record.
Initial Status numbers are 64 for inbound and 03 for outbound. Successful
status is 53 for inbound and 16 for outbound IDocs.

SENDING AND RECEIVING IDOCS

TRIGGERING AN OUTBOUND IDOC

Outbound IDocs can be triggered from the output message types of

Purchase Orders, deliveries, Material Documents, invoices, etc. The
following figure shows that once the output ZXX1 of PO XXXXXXX1 is
processed an IDoc “000000XXXXXXXXX1” is added/created.

The relationship between the IDoc and the application document can be
found in two ways:
1. Relationship tab of IDoc

2. Relationship tab of Application Document, e.g. PO, SO, Material

Document, etc.
The initial status of this IDoc will be 30, which after successful processing
will convert into status 16.

A successful outbound IDoc will pass through all the above statuses in
reverse order (01-03-18-06-12-16). Each status represents an IDoc
validation step. If an IDoc passes all the validations it would reach status
16. These different validation steps for outbound IDocs are explained
below:

01: IDoc generation successful

30: IDoc is ready to be processed by IDoc Processing job

03: IDoc data is passed to the Port

18: IDoc successfully triggered EDI subsystem

06: IDoc data translated to EDI format

12: IDoc is dispatched successfully to the partner

16: Partner has received the IDoc successfully

IDoc can possibly fail at any of the above steps during validation.

RECEIVING AN INBOUND IDOC

The initial status of an inbound IDoc is 64 and successful status is 53.

Different validation steps for inbound IDocs are explained below:

50: IDoc received successfully in the system

64: IDoc is ready to be processed by IDoc processing job

53: Application document created and saved successfully. The document

number can be found by expanding the status node 53

An inbound IDoc goes through all the above statuses in reverse order (50-
64-53).

IDOC PROCESSING

AUTOMATIC/IMMEDIATE PROCESSING
In this case, IDoc are processed immediately as they generated or added
in the system. The check “Transfer IDoc immediately” is selected in
Outbound Options and “Trigger Immediately” is selected in Inbound Option.
These checks are generally used when the real time information exchange
is necessary between two systems.

MANUAL PROCESSING

IDocs can also be manually processed using the TCODE BD87 in SAP.

PROCESSING VIA BACKGROUND JOB

IDoc processing by background is the most preferred way of processing the

IDocs. Following Programs are used from processing the IDocs using
background job:

RBDAPP01 - Inbound IDocs

RSEOUT00 - Outbound IDocs

REPROCESSING IDOCS

On the basis of IDoc statuses different programs can be used for

reprocessing of failed IDocs. These are given below:

TESTING AND EDITING IDOCS

If an IDoc contains error in the data then such IDocs can be edited using
TCode WE02 or WE05. When an IDoc is edited the original IDoc
information(backup) is saved in a New IDoc under status 70 (for inbound) /
33 (for outbound). These IDoc stays in the system for reference only and
cannot be processed. The status of the edited IDoc becomes 69 (inbound)
and 32 (outbound). These IDocs can then be processed using BD87
transaction or batch jobs.
Debugging of IDocs can be done using by copying the IDocs using TCode
WE19. WE19 is a test tool for Idocs processing. WE19 copies the existing
idoc and creates a new IDoc which can then be modified as per testing
needs. The newly generated IDoc can also be processed using BD87.

CONVERTING IDOC STATUS

Report RC1_IDOC_SET_STATUS can be used to change the status of

IDoc. Status changes are generally needed to move an IDoc to status 68 –
no further processing

SEARCHING IDOCS IN SAP

TCODE WE02/WE05: GENERAL SEARCH

IDocs can be displayed in system via TCODE WE02 and WE05. If IDoc
number is not known then search can be made on the basis of IDoc Date,
Direction, BASIC TYPE, MESSAGE TYPE, and PARTNER NUMBER.
Partner number can be found in the Output Messages of the documents.
IDoc search can also be made on the basis of ISA or Transfer file
Reference.
TCODE WE09: SEARCHING DATA IN IDOC SEGMENTS

If we are looking for specific information within the IDocs Segments then
this can be found using TCODE WE09. This is useful if you are searching
for a particular information in similar kind of IDoc within IDoc segments. For
example, if you want to search a particular Purchase Order number e.g.
100000001 in multiple IDocs which lies in Segment E1EDK01 of an IDoc
under field BELNR. Then the search can be executed in the following
manner.

IDOC VALIDATIONS, COMMON IDOC ERRORS AND

SOLUTION
Though, the IDoc failure may not be related to any of the above mentioned
reasons, the best way to find the IDoc error is to compare the existing IDoc
with the good example. Good example IDoc can be easily searched with
any of the IDoc search methods as described above.

DOCUMENTATION FOR IDOC TYPES

IDoc documentation can be found using TCODE WE60 and can be helpful
to obtain information of the IDoc Type or its particular segment. It also
provides information such as mandatory and optional segments, minimum
and maximum number of segments, etc.
GENERAL INFORMATION FOR COMMON IDOC MESSAGE
TYPES

The following list gives the Basic Type and Message Type combination for
common idocs
ARCHIVING/DELETION OF IDOCS FROM DATABASE

As IDocs grow older they are archived and deleted from the database.
Archived IDocs can be viewed using TCODE SARI in Achieve Explorer
using archiving object as IDoc. Following are the few programs that are
used for archiving and deletion of IDocs from database.
IDocs are text encoded documents with a rigid structure that are used to
exchange data between R/3 and a foreign system. Instead of calling a
program in the destination system directly, the data is first packed into
an IDoc and then sent to the receiving system, where it is analyzed and
properly processed. Therefore an IDoc data exchange is always an
asynchronous process. The significant difference between simple RFC-
calls and IDoc data exchange is the fact, that every action performed on
IDocs are protocolled by R/3 and IDocs can be reprocessed if an error
occurred in one of the message steps.

While IDocs have to be understood as a data exchange protocol, EDI

and ALE are typical use cases for IDocs. R/3 uses IDocs for both EDI
and ALE to deliver data to the receiving system. ALE is basically the
scheduling mechanism that defines when and between which partners
and what kind of data will be exchanged on a regular or event triggered
basis. Such a set-up is called an ALE-scenario.
The philosophical difference between EDI and ALE can be pinned as
follows: If we send data to an external partner, we generally speak of
EDI, while ALE is a mechanism to reliable replicate data between
trusting systems to store a redundant copy of the IDoc data. The
difference is made clear, when we think of a purchase order that is sent
as an IDoc. If we send the purchase order to a supplier then the
supplier will store the purchase order as a sales order. However, if we
send the purchase order via ALE to another R/3 system, then the
receiving system will store the purchase order also as a purchase order.

1.ABAP Development

2.Data Transfers - BAPI, BDC, ALE,

LSMW, DX-WB

3.ALE and IDocs

ALE,IDOC

ALE Technology : Application Link Enabling (ALE) is a

technology to create and run distributed applications. ALE
Technology is proprietary of SAP.
ALE Objectives - ALE incorporates controlled exchange of data
messages ensuring data consistency across loosely coupled
applications. ALE comprises of three layers. Application
Services Distribution Services and Communication Services
.Basic principle of ALE is to provide a distributed and fully
integrated R/3 system. Each application is self-sufficient. The
use of self-sufficient system implies a certain measure of data
redundancy. Hence data has to be both distributed and
synchronized.
Difference Between ALE and EDI :Normally we refer to EDI
technology when a non SAP system is one of the
communication channel. ALE communication occurs from the
SAP side and EDI from the non-SAP side.
IDOCs uses ALE and EDI to deliver the data to the receiving
system. If the data needs to be exchanged between two SAP
systems, then IDOC uses ALE technology . For the exchange of
data between a SAP and Non SAP system, IDOC uses EDI
subsystem to convert and deliver the data.
ALE Communication Diagram

1. What is the difference Between IDOC type and Message

type? How to link the IDOC type with Message type?

Message type gives the meaning of the IDOC . IDOC type

gives the structure of an IDOC.The messages exchanged
between systems are of various message types. The
message type depends on the data contained and the
process involved. It determines the technical structure of
the message and the IDOC type.The IDoc type indicates
the SAP format that is to be used to interpret the data of a
business transaction.
In the OO(Object Oriented) approach, Message Type can
be refferred to a Class and IDOC Type as an instance of
the class Message Type
 The linkage will happen in transaction WE82.

2. Where the IDOC information gets stored?

Table Description
EDIDC Stores the Control Record information an IDOC
EDID4 Stores the Data Records (version 4.6)
EDIDD Data Seg (EDI Intermediate doc)
EDIDS Stores the Status of an IDOC

3. What is process code? What are type of process codes

Process code refers to an workflow or a function module which
helps in reading or writing data from/to Idoc. Process Codes are
used in both ALE and EDI framework to identify the function
module or API (Application Programming Interface) to be
invoked for subsequent processing. Inbound as well as outbound
interfaces use process code but for different purposes. Outbound
process codes are stored in table TEDE1, while inbound process
codes are stored in TEDE2.
Following are types of process code

Process Code Description

Outbound This will read application data and place data in
Process Code Idoc
Inbound This will Idoc and create corresponding
Process Code application data
System Process This will create work item in case some error
Code occurs in idoc / application document
Process Code Description
processing
Status Proces This will handle error that occurs when a idoc is
Code sent to some other system

4. How to reprocess an IDOC?

You can use the below Programs for IDocs Reprocessing:
 RBDMANI2 : Reprocess Idocs manually
 RBDMANIN : Posting of IDocs with Status 51
 RBDMOIND : Outbound Idocs status 03->12
 RSEOUT00 : For Processing 30 Status IDocs
 RBDAPP01 : For Processing 64 Status IDocs
 RBDAGAIN : Reprocess Incorrect Outbound IDocs
 RBDAGAI2 : Reprocessing of IDocs after ALE Input Error
5. How to trace the IDocs of the Receiving system from the
Sending system?
Steps:
 Execute the transaction BD87
 Give the Outbound IDocs in the IDoc Number field and
execute or Just Note the Start time and End time when u
execute the Master Data Transaction say for eg.BD10 and
specify the same in the Time Created input field of
BD87,also give the Message Type and the Receiving
System Names and execute.
 Select the Repective Message Type and Press the Trace
IDoc Button.
6. How to trace IDocs based on the data .
Steps:
 Execute Transaction WE09
 Put in the message type name in the field labeled 'Logical
Message' Ex - DEBMAS
 Now we will move to the section 'Criteria for Search in
Data Records '
 In this section we will put the Segment name in which
we want to search the existance of data in the field labeled
'Search in Segment' EX - E1KNA1M
 In the field labeled 'Search in Field' we will put the field
name of the segment in which we want to search the
existance of data. Ex - KUNNR for searching IDOCs for
certain customer number.
 Now in the field labeled 'For Value' we will put the search
value. Ex - Customer number as 100 .
 We will now execute the transaction.
 The result can be a single Idoc or a list of multiple IDOCS
depending upon the Search Criteria entered.
7. How to Send and Receive an IDoc in the same system.
Steps :
 Create a Dummy Logical System.
o Goto T-Code SALE-> sending and Receiving Systems

-> Logical Systems -> New entries.Enter

SYSID_CLNT, but this one is Dummy so use the first
2 characters of the SYSID and prefix 'D' then
underscore and then the Client number.

 o E.g.: If ERP_100 is the logical system of the R/3 then
create ERD_100 as the dummy system.
 Create Port for the Original System, (ERP_100)
o Goto WE21 and select Transactional Port and press

the Create button. Name the Port as "SAP"

contatenated with the SYSID in our example it would
be SAPERP Select the appropriate version and enter
the RFC dest of the system that you are working on in
this case it will be 'ERP'.
 Create Partner Profile in partner type LS:
o Receiver Side ( Outbound to ) : In Partner type LS

name ERD_100create the Outbound Parameters, give

the Message type, Receiver Port same as the port we
created in step 2. Enter the Basic type.


o Sender Side ( Inbound From ): In partner type LS

name ERP_100 create the Inbound Parameters, give
the appropriate message type and the process code.
 Now create the stand alone program to send the IDoc:
o The program will at some point calls the

MASTER_IDOC_DISTRIBUTE function module.

When you pass the EDIDC structure it will be
populated as follows:
i_edidc-mestyp = message type.
i_edidc-idoctp = basic type.
i_edidc-rcvprt = 'LS'.
Concatenate 'SAP' sy-sysid into l_port.
i_edidc-RCVPOR = l_port.
i_edidc-rcvprn = 'ERD_000'.
CONCATENATE sy-sysid '_' sy-mandt
 INTO l_sndprn.
i_edidc-SNDPRN = l_sndprn.
i_edidc-sndprt = 'LS'.
i_edidc-sndpor = l_port.
 Observe that the Sender port and the receiver port is the
same, this does the trick. The outbound Idoc is sent on the
port SAPERP with the Sender as ERP_100 and receiver as
ERD_100 and then the Inbound Idoc is also sent to the
same port SAPERP with the Sender as ERP_100 and
receiver as ERD_100.
8. What is message control and when do we use it?
Message control is a mechanism by which documents are output
based on a selection criteria and requirements. This concept is
applicable not only to EDI and ALE, but also to other output
mediums (for example: print, fax). Message control determines
the type of document, its timing, number, and the medium.
NAST table stores output records. The conditions (selection
criteria and requirements) for creating an output message are
stored in condition tables. Search mechanisms are used through
access sequences, output processes, and requirements to
determine whether an application document qualifies for output.
Some of the tables for Message Control are :

Transaction Code Description

NACE Condition Record Maintenance
VOK2 SD Message Control Components
VOK3 Purchasing message Control Components
VOFM View Message Requirements
Transaction Code Description
V/86 Condition Table Field Catalog
WE15 IDOC test : outbound from Message Control

9. How do you reprocess the failed trfc entries?

You can reprocess the failed trfc entries using the program
RSARFCEX.
10. What is the transaction used to find the outbound and
inbound process codes at one place?
WE64


=================================================
IDocs are basically a small number of records in ASCII format,
building a logical entity. It makes sense to see an IDoc as a plain
and simple ASCII text file.
IDocs is the acronym for Interchange Document. This indicates
a set of (electronic) information which builds a logical entity.
Any IDoc consists of two sections:
Control record:
- The control record carries all the administrative
information of the IDoc, such as its origin, its destination and a
categorical description of the contents and context of the
attached IDoc data.
- The control record has a fixed pre-defined structure,
which is defined in the data dictionary as EDIDC.
Data record:
- Which contains the application dependent data, as in our
example below the material master data.
- All IDoc data records are exchanged in a fixed format,
regardless of the segment type. The segment's true structure is
stored in R/3's repository as a DDic structure of the same name
Contents of idoc:

1)Control Records
2)Data Records
3)Status Records

Control Record: Contains information about the Sender id,

Receiver id, Sender Port,Receiver Port,Idoc Type,Message
Type.

Data Record: Containing the message to be Exchanged in

multiple Records.

Status Records: Containing the Status of Idoc Exchanged at

various Stages.
Each Record corresponds to one Stages.
01-49 for outbound process
50-75 for inbound process
Status of Idoc's are:
01 IDoc created
02 Error passing data to port
03 Data passed to port OK
04 Error within control information of EDI subsystem
05 Error during translation
06 Translation OK
07 Error during syntax check
08 Syntax check OK
09 Error during interchange handling
10 Interchange handling OK
11 Error during dispatch
12 Dispatch OK
13 Retransmission OK
14 Interchange Acknowledgement positive
15 Interchange Acknowledgement negative
16 Functional Acknowledgement positive
17 Functional Acknowledgement negative
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 still due
23 Error during retransmission
24 Control information of EDI subsystem OK
25 Processing despite syntax error (outbound)
26 Error during syntax check of IDoc (outbound)
26 Error during syntax check of IDoc (outbound)
27 Error in dispatch level (ALE service)
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 Electronic signature not performed (timeout)
37 IDoc added incorrectly
38 IDoc archived
39 IDoc is in the receiving system (ALE service)
40 Application document not created in receiving system
41 Application document created in receiving system
42 IDoc was created by test transaction
50 IDoc added
51 Error: Application document not posted
52 Application document not fully posted
53 Application document posted
54 Error during formal application check
55 Formal application check OK
56 IDoc with errors added
57 Test IDoc: Error during application check
58 IDoc-Copy from an R/2 connection
60 Error during syntax check of IDoc (inbound)
61 Processing despite syntax error (inbound)
62 IDoc passed to application
63 Error passing IDoc to application
64 IDoc ready to be transferred to application
by test transaction
63 Error passing IDoc to application
64 IDoc ready to be transferred to application
65 Error in ALE service
66 IDoc is waiting for predecessor IDoc (serialization)
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
73 IDoc archived
74 IDoc was created by test transaction
What is a IDOC?

An IDoc is simply a data container that is used to exchange

information between any two processes that can understand the
syntax and semantics of the data. IDoc is not a process.
- IDocs are stored in the database.
- In the SAP system, IDocs are stored in database tables.
- IDocs are independent of the sending and receiving
systems.
- IDocs are independent of the direction of data exchange.

Creation of IDOCs

Transaction code: WE 30
Steps of Defining Segment

Creating Segment : Tcode - WE31

Creating Message Type : Tcode - we81
Assigning Message type to Idoc type: Tcode - we82
Process

The two processes for IDoc are Outbound Process and Inbound
Process.

Outbound Process

When the data is sent out from the system, the process is called
Outbound Process and the IDoc is known as Outbound IDoc.
Inbound Process

When the data is coming in, the process is called Inbound

Process and the IDoc is known as Inbound IDoc.

Outbound Process (Sending System) Steps :

1) Goto Tcode SALE:

Creating the logical system
Click on Sending and Receiving Systems à Select Logical
Systems--Here Define the Logical Systems à Click on Execute
Button
Go for New Entries
1) System Name : LOG1:Description: Sending System
2) System Name : LOG2:Description: Receiving System
Press Enter & Save it will ask for Request if you want new
request create new request or press continue for transferring the
objects.
Assigning Client to the Logical System:
Select Assign Client to Logical Systems -
Client : Sending System
Logical System : LOG1
and also
Client : Receiving System
Logical System : LOG2
Save this Data.
Step 2) For RFC Creation:
Goto Tcode SM59 and Select R/3 Connects
Click on create Button
RFC Destination Name should be same as partner's logical
system name and case sensitive to create the ports automatically
while generating the partner profiles
Give the information for required fields:
RFC Destination : LOG2
Connection type : 3
Target Host : sappdc.wipro.com
System No : 00
Client : 210
User : Login user name
Password :
Save this & Test it and Remote Login
Step 3) Goto Tcode BD64:
Click on the change button>Click on the create model view
Short Text: model view
Technical Name: LMOD
Save this & press ok
Select just created model view
Name: "LMOD"
Goto add message type
Model Name : LMOD
Sender : LOG1
Receiver : LOG2
Message type: ZAZHARMESS
Save and press Enter.
4) Goto Tcode BD82:
Give Model View : LMOD
Partner system : LOG2
Execute this by pressing F8
It will gives you sending system port No: A00000000089 (Like)

5) Goto Tcode BD64:

Select the model view
Goto >Edit >model view > Distribute
Press ok & Press Enter.

Run your Zprogram

REPORT ZIDOC1 .
DATA: Begin of imara occurs 0,
matnr like mara-matnr,
mtart like mara-mtart,
end of imara.
DATA: wamas_con LIKE edidc,
imas_data LIKE edidd OCCURS 0 WITH HEADER LINE,
icom_con LIKE edidc OCCURS 0 WITH HEADER LINE.
PARAMETERS: e_matnr LIKE mara-matnr,
e_msgtyp LIKE edidc-mestyp,
e_rcvprn LIKE edidc-rcvprn.
* retrive app. data from DB
SELECT matnr mtart FROM mara INTO TABLE imara
WHERE
matnr = e_matnr.
*Master idoc control record
wamas_con-rcvprt = 'LS'.
wamas_con-rcvprn = e_rcvprn.
wamas_con-idoctp = 'ZAZHARIDOC'.
wamas_con-mestyp = e_msgtyp.
* master idoc data records
LOOP AT imara.
imas_data-segnam = 'ZAZHARSEG'.
move imara to imas_data-sdata .
APPEND imas_data.
ENDLOOP.
CALL FUNCTION 'MASTER_IDOC_DISTRIBUTE'
EXPORTING
master_idoc_control = wamas_con
TABLES
communication_idoc_control = icom_con
master_idoc_data = imas_data
COMMIT WORK.

6) Verifying Transfer of IDOCs Tcode - we05

ALE/IDOC Status Codes (outbound):
01> IDoc Added
30 > IDoc ready for dispatch
29 >Error in ALE service Layer
12 >Dispatch ok
03 > Data passed to port ok.
Inbound Process (Receiving System) Steps:

Do the same step as you did in sending system

> Creating IDoc
> Defining the Segment
> Creating Message Type
> Assigning the Message Type
> Defining the Logical System
> Assigning the Logical System
> Creating the Distribution Model
1) Goto Tcode - we57:
Assign function module to IDoc type
Module: Function module
Basic type:
Message type:
Direction: 2 (inbound)
2) Creating Inbound process code - we42
3) Verifying Idoc List Tcode - we05
4) ALE/IDOC Status Codes (Inbound):
50 > IDoc Added
51 >Application Document not posted
64 >IDoc ready to be transferred to application
62 >IDoc passed to application
53 >Application Document posted

====================================================
 IDOC Process

1. What is Idoc?

IDocs are structured ASCII files (or a virtual equivalent). They are
the file format used by SAP R/3 to exchange data with foreign
systems.

IDocs is the acronym for Interchange Document (Intermediate

Document). This indicates a set of (electronic) information which
builds a logical entity. An IDoc is e.g. all the data of a single
customer in your customer master data file, or the IDoc is all the
data of a single invoice.

The information which is exchanged by IDocs is called a message

and the IDoc is the physical representation of such a message.
The name “messages” for the information sent via IDocs is used
in the same ways as other EDI standards.

2. Why Idoc Configuration?

To exchange IDoc data between systems and partners that are

completely independent or between same systems we need to
configure.

3. Steps in Idoc Configuration

Consider we have to exchange data between two different

clients. Following are the configuration steps common for
Interchange Documents in both the clients.

3.1. Create segment

1. Go to transaction WE31 -> Give your segment name ->

Press Create.
2. Type your field name and data element and press save then
segment definition will be created automatically.
 3.2 Create Idoc Type

Go to Transaction WE30

1. For new IDOC type select the radio button Basic type and
press Create button.
2. Then select the IDOC option to create and press Enter. Give
segment name, minimum and maximum number for and
save it. Check if this is mandatory segment.
3. If you want Header and Item create the segment tree
according to that, you can view as follows then press
Save.
4. Then go back and set release the IDOC type for using it
further. Idoc type will be created successfully once we
release that status. We have to release the segments (in
WE31) and IDOC type as well.

3.3 Create Message Type

Go to transaction WE81 for new message type. Go to change

mode and click New Entries for creating our own message type.

3.4 Associate Message Type with Basic Idoc Type

Go to transaction WE82 for associating the message type with

basic IDOC type.

3.5 Create Logical System

Go to transaction SPRO and press SAP Reference IMG for

creating the logical system for source and destination.

Click the node define logical system from SPRO -> SAP
Reference IMG -> SAP customizing Implementation Guide ->
SAP xApp Resource and Portfolio Management (SAP xRPM) ->
Base system Interfaces -> SAP Human Capital Management
Integration -> Common system configuration and SAP HCM ALE
setup -> Application link enabling (ALE) -> Basic Settings ->
Logical Systems -> Define Logical System

Else go to transaction SALE then go to Basic settings-> logical

system then Define logical system. We can create the same.

3.6 Create Logical Connection

1. Go to transaction SM59 for creating Logical Destination.

a. SM59 -> logical connections -> Create

b. Then Click Connection test icon after marking the

current user checkbox in logon and security tab.

c. Then Destination client will automatically open

3.7 Create Ports

Go to transaction WE21 for creating ports. WE21 ->

Transactional IR -> Create

4. Steps to be done in Source client

1. Go to transaction SE11 -> create a table with entries.

2. Go to transaction WE31 -> create segments as shown before.

Here you have to mention all the fields mentioned in the database
table.

3. Go to transaction WE30 -> create basic IDOC type and

release the segments and basic type.

4. Go to transaction WE81 -> create message type.

5. Go to transaction WE82 -> assign message type to basic Idoc

type.
 6. Go to transaction BD64 -> Click on Display/change
button

7. Click on Edit menu -> model view -> create

8. Specify description and technical name and press

continue.

9. Select your model view -> click edit -> Add message
type

10. In dialog box specify sender, receiver, and message type and
continue.

11. Click on environment menu -> generate partner

profile

12. It will show the following screen. Select your model view and
click on execute.

13. It will show the partner profile log in next screen.

14. Click on back button 2 times it will take to distribution model

screen.

15. Click on Edit -> Model view -> Distribute

16. In displayed dialog box select the partner system and

continue.

17. Then it will show the log of model view distribution.

18. To check partner profile go to transaction WE20.

19. Then write the report program in SE38 to create IDOC

control records and transfer it to destination partner system.
 20. Go to Transaction WE02 to check the generated IDOC
control records.

5. Steps to be done in Destination client

1. Go to transaction SE37 to create the function module for

updating the table from IDOC segments.
2. Specify import, export and table parameters.
3. Go to transaction WE57 for assigning the FM to logical
system. Click on Display/ change button.
4. Specify FM name, function type, basic type(IDOC ),
message type and direction then save it.
5. Go to transaction BD51 to define input method for inbound
function module and click on Display change button
6. Specify your function module and input type by clicking the
new entries.
7. Go to transaction WE42 and create process code.
8. Go to transaction BD64 and generate the partner profile
again.
9. Got to transaction SE 38 and execute the transaction in
source system (client100).
10. Check in destination system (client 800). Go to
Transaction WE02 and check your table in SE11. (You can
get the transferred entries in that table).

IDOC Follow these steps

SAP XI
1) RFC Destination (SM59)

a) Choose create.

b) Specify the name of the RFC destination

c) Select connection type as 3 and save

d) In the technical settings tab enter the details SAP SID/URL and
system number#.

e) Enter the Gateway host as same details above SID/URL.

f) Gateway service is 3300+system number#.

g) In the Logon /Security tab, enter the client user & Password
details of Destination system.

h) Test the connection and remote logon.

2) Create Port (IDX1)

a) Select create new button

b) Enter the port name as SAP+SID (The starting char should be

SAP)

c) Enter the destination client.

d) Enter the RFC Destination created in SAP R/3 towards other

system.

e) Save

3) Load Meta Data for IDOC (IDX2)

a) Create new

b) IDOC Message Type

c) Enter port created in IDX1.

SAP R/3

1) RFC Destination (SM59)

a) Choose create.

b) Specify the name of the RFC destination

c) Select connection type as 3 and save

d) In the technical settings tab enter the details SAP SID/URL and
system number#.

e) Enter the Gateway host as same details above SID/URL.

f) Gateway service is 3300+system number#.

g) In the Logon /Security tab, enter the client user & Password
details of Destination system.

h) Test the connection and remote logon.

2) Create Port (We21)

a) First Select Transactional RFC and then click create button

b) Enter the destination port name as SAP+SID (The starting char

should be SAP)

c) Enter the destination client.

d) Enter the RFC Destination created in SAP R/3 towards other

system.

e) Save
3) Create Partner Profile (WE20)

a) Create New

b) Create the Partner no. name as same the logical system name
of the destination system.

c) Select Partner type LS

d) Enter details for Type: US/USER, Agent, and Lang.

e) Click on the + button to select the message type.

f) Select Partner no. and LS which ever create above.

g) Select Message type

h) Select Process code related to the Message type.

I) save.

In SLD – System Landscape Directory

TS for R/3 (Logical system):-Assign the client name created in

R/3 as Logical system Name.

Ts for Third Party (Logical system):-

BS for SAP R/3 (Logical system):- Assign the client name created
in R/3 as Logical system Name.

BS for Third Party (Logical system):-Enter the XI logical system

name.
In Transaction SALE

Define and Assign the logical system name.

after these settings

go to the Business System .

In the menu

go to servive then adapter specific identifiers and check wether

the settings are right

IDOC STEPS

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

SAP ALE 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.

 DDIC Tables for IDoc

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
 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

 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
Outbound Settings

Define Logical Systems and Assign Client to Logical System –

Transaction SALE

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

 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

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

Inbound Settings

 Define Logical Systems – Transaction SALE (Please refer to

Outbound Settings)
 Assign Client to Logical System – Transaction SALE (Please
refer to Outbound Settings)
 Maintain RFC Destinations – Transaction SM59 (Please
refer to Outbound Settings)
 Define Ports – Transaction WE21 (Please refer to Outbound
Settings)
 Generate/Create Partner Profile – Transactions BD82/WE20
(Please refer to Outbound Settings)
 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.
 IDoc Generation Program

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.

WE02
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