http://www.sapabapiq.com/2012/02/ale-idoc-interview-questions.

html
Idocs :

Master Idoc is an Idoc which consists of all the data 

pertaining to that message and Idoc type and is independent 
of the receiver.This is stored in memory and can not be 
viewed.When we execute a BD10 for a range of 
materials ,only one master Idoc will be created 
irrespective of the number of recivers.

Communication Idoc is the Idoc pertaining to the specific 

receiver .This contains data that the receiver accepts.It 
means tha data from the master Idoc is filtered for a 
specific receiver based on the filter 
conditions,versions,conversions mentioned in the 
Distribution Model and then the communication Idoc will be 
created.

If there is one receiver,then

To send 10 materials at a time through BD10 tcode,
one Master Idoc
One communication Idoc having 10 data records in it for 
these 10 materials for one receiver.

If there N number of recivers,then

To send 10 materials at a time through BD10 tcode,
one Master Idoc
One communication Idoc having 10 data records in it for 
these 10 materials for each receiver.So N number of 
communications Idocs.

master idoc: in the outbond process all the data in sap r/3 
is retreived via outbond program.after retrieving, the data 
is arranged in segments in heirarichal order in an internal 
table.this internal table which has segments and data is 
known as master idoc.

communication idocs : this completely depends upon the 

distribution model which has list of senders and 
receivers.so if receivers are not attached to senders in 
distribution model than we have zero communication idocs.so 
communication idoc is simply the data which gives the link 
between the senders and receivers.
if u send 5 records it means u r sending 5 master idocs and 
the number of communication idocs depend upon the number of 
receivers u have in the distribution model.

ALE IDocs in SAP

ALE IDocs in SAP is a lot about configuration and a lot about Tcodes . So if you have worked on at
least one end to end scenario in ALE IDocs in SAP , you probably already have answers to a lot
of questions.

Cheers!!

But if you haven't , make sure you do this exercise. There are plenty of step by step guides to ALE
IDocs available on the internet . Make sure you read one understand it all the way . Sending IDoc
from client 800 to say client 810 on the same server is easy . If possible ,Try an exercise in which
you send an IDoc from one system to another system. 

Lets get started . Hope you get some value in these pages :)

Question 1:  What is ALE ?

ALE stands for Application Link Enabling. As it's name indicates , it links two systems.
ALE is a technology that can enable exchange of data between two different Systems ( Sap - Sap
OR Sap - Non Sap). ALE technology enables distributed yet integrated installation of SAP systems.
ALE architecture comprises of 3 layers : 

Application layer refers to the application data ( SD , MM , FI or data for any SAP application ) . In
this layer the data is collected to be distributed and then sent to the distribution layer.

Distribution layer determines to whom should the data generated by the application layer has to be
distributed i.e. it is in the distribution layer that the recipient is determined , the data is formatted or
filtered and then an actual is created.

Communication layer takes the responsibility of delivering the Idoc to the receiving system and
communicates to the receiving system via tRFC , File ports , FTP or TCP/IP etc.

ALE uses IDoc as a vehicle to transfer data between two systems.

Question 2:  What is EDI ?

EDI stands for Electronic Data Interchange. It refers  to the electronic exchange of business data in
a structured formatbetween two systems. The EDI subsystem generally converts the Idoc data into
one of the many EDI formats and generates an EDI file in an X12 format. The middleware then
translates the X12 file to an IDOC format and the IDOC is sent to the SAP system.
Question 3:  What is an Idoc?   What is IDoc Type?   What is an IDoc Extension ?
An IDoc (Intermediate document) is a vehicle that is used to transfer data from one system to another.
IDoc is not a technology of some sort , but it is just a container that holds data . 
It holds data in a structured format i.e. in the Fields of the Segments.

IDoc Type vs. IDoc: 

An IDoc Type is nothing but a collection of one or more structures defined in a system with specific
fields. It does not hold Data.
However, an IDoc is something that holds the values in the fields of the structure defined by IDOC type. 

The transaction code to view an IDoc type (Basic and extension) is WE30.
Examples: ORDERS04, DEBMAS04, MATMAS04, CREMAS04.
These are all SAP standard Basic IDoc Types. 

You can even have an IDoc extension in which you can use the existing Basic IDoc type and add extra
segments and fields to it. Usually we extend an IDoc when the standard SAP IDoc type is not able to
cater to the business process.  

Question 4:  What are the types of records in SAP ALE Idocs and where is this information stored ?
There are three types of records in SAP ALE Idocs:
Control Records: Control record information for an IDoc is stored in standard table EDIDC.
Data Records:     Control record information for an IDoc is stored in standard table EDID4.
Status Records:   Control record information for an IDoc is stored in standard table EDIDS.

Question 5:  What is an Idoc status?  What are the different types of Idoc statuses that you know ?
When an IDoc is sent from one system to another , it goes through variuos stages.The IDoc status
indicates the stage that the Idoc in currently in.
There about 75 IDoc statuses.There is no way you can remember those all .
Don't even try to ! You will probably remember only those on which you have worked .

But here are a few that you should know:

0-49 indicates an Outbound IDoc and 50-75 as Inbound IDoc. 

01  IDoc generated
02  Error passing data to port
03  Data passed to port OK

51  Application document not posted

52  Application document not fully posted
53  Application document posted

Question 6:  What is a Port ? What are the types of Ports ?

A port is a communication channel through which Messages can be sent or received in SAP .
The sender and the receiver both specify the port through which they will communicate.

The common port types are the TRFC Port and the File Port.
If both sender and receiver mention TRFC ports, data is exchanged via RFC connections.
If however , a file port is mentioned , the IDOC is written in a flat file at the specified location at the
sender system.Then a FTP transfer should be done from that location to the receiver system or a
Middleware that will send the file to the receiver system.

The transaction to maintain ports is WE21.

Question 7:  What is a Message type and Idoc Type ? What is the difference between Message
type and an IDoc type?
A Message type and an IDoc type are closely related . In fact, you will find that a Message type is
always associated with an IDoc type.Whereas an IDoc type is a detailed version with all the
segments and fields , a Message type is used just to specify the kind of information that a system
can send or receive to or from another system.

So If system SAP1 has a Partner Profile where it specifies MATMAS as an outbound message

type , it just means that SAP1 can send material master data to say system SAP2.

If system SAP1 has a Partner Profile where it specifies MATMAS as an inbound message type , it
just means that SAP1 can receive material master data from say system SAP2.

What all fields can be sent and received will be specified in the IDoc type.
Some other message types: DEBMAS( Customers), CREMAS(Vendors) belong to the Master data.

The link between a message Type and an IDoc type is maintained in Tcode WE82.

Question 8:  What is a partner profile ? What are the types of partner profiles ?
To be able to communicate with a partner via an IDoc interface, each system needs to maintain a
partner profile. A partner profile is a mechanism by which the system can specify what kind of
messages (message types) it can send or receive.
Partner profiles can be maintained in WE20.

Question 9:  What is a distribution model in ALE IDocs ? 

The distribution model describes how ALE messages flow between different logical systems.
You can mention the sender and receiver logical systems, the message type to be distributed and
also distribute data(IDocs) based on certain conditions by using the distribution model. 
The ALE layer uses the distribution model to control which systems will receive the
information(IDocs) and also filter the data based on certain conditions.
Distribution Models can be created and maintained in transaction BD64.

Question 10:  What are process codes ?

The process code is having the function module attachment ...here you will get the logic for the data
population in the idocs....simply process code contains the code of the program
Process Code
Description
Outbound Process Code
This will read application data and place data in Idoc
Inbound Process Code
This will Idoc and create corresponding application data
System Process Code
This will create work item in case some error occurs in idoc / application document processing
Status Proces Code
This will handle error that occurs when a idoc is sent to some other system

Question 11: How do you Edit IDoc contents manually?

we02 edit and save and the reprocess in bd87
           
Question 12: Can you edit IDoc content for successful IDocs ?
No. You cannot.

Question 13: If you send an IDoc say 100008008 from system ECC1 to system ECC2, will the IDoc
number in ECC2 be 100008008?
No. The next number from the IDoc number range in ECC2  will be picked up.

Question Reprocess outbound idoc

If you wanted to reprocess the Outbound IDOC, you need to do the following steps:-
1. Execute the program RC1_IDOC_SET_STATUS by giving the idoc number, current status of the
idoc and new status 30 and remove the test run flag in the selection screen.
2. Execute the program RSEOUT00 by giving the idoc number as input. or we14
Then the outbound idoc will be reprocessed with out generating a new idoc.
- Program RSEOUT00 (to reprocess 30 status IDocs)
- Program RBDSYNER (to reprocess 26 status IDocs - Idocs with syntax error)
- Program RBDAGAIN (to reprocess IDocs with status 02, 29 - Idocs failing with error in port and
partner profile respectively)

Question: How to change idoc status

Execute the program RC1_IDOC_SET_STATUS by giving the idoc number, current status of the
idoc and new status 30 and remove the test run flag in the selection screen.

More interview questions on ALE IDocs :

Question 14: How do you read data from an IDoc in a program ?

IODC_READ_COMPLETELY
Question 15: How do you send Idoc from a program ?

MASTER_IDOC_DISTRIBUTE

'L_IDOC_SEND
Question 16: How do you achieve filtering in a distribution model ?

Segment Filtering:
Segment filtering can be achieved using transaction BD56. Here you can suppress a whole segment
irrespective of data inside it . You have to give Message Type / Sender Partner / Receiver Partner.
https://blogs.sap.com/2013/12/05/ale-idoc-with-segment-filtering/
Data Filtering:
Data filtering can be done in distribution model (BD64) where you can restrict whole IDOCS or
partials IDOCS to be send based on data in fields inside IDOC depending on whether the segment
in which you filter is at the highest level or at a lower level. For example in MATMAS if you put a filter
of E1MARCM for a particular plant, only data for this plant will go and other plants will be ignored.
Please check this link for detail information.
http://freesapabap.blogspot.in/2013/11/collective-transfer-material-master_3.html
Question 17: Can I create a flat file from an IDOC ? If Yes , How ?

In the EDI message type for the logical system you need, you must set the receiver port as file (es:
“EDISAP”) with the transaction WE20.
Question 18: You want to create and send an IDOC to another the moment a PO is created in
your            system . How will you achieve this ?
Question 19: How to Reprocess Idocs in SAP?
Question 20: What is a change Pointer?

The change pointers technique is based on the change document technique, which tracks changes
made to key documents in SAP, such as the material master, customer master and sales order.
Changes made to a document are recorded in the change document header table CDHDR, and
additional change pointers are written in the BDCP table for the changes relevant to ALE.

http://freesapabap.blogspot.in/2013/11/transfer-of-material-master-from-one_3.html

Question 21: What is serialization of Idocs?

Serialization for Sending and Receiving Data

With serialized message distribution, IDocs are created, sent and posted in a specific order. This prevents
errors occurring when inbound IDocs are processed. Interdependent messages can be distributed serially
in different ways, as described in the following sections.

 Serialization Using Message Types

 Serialization Using Business Objects

In this Tutorial we will learn Serialization using IDOC Message types and the details steps involved.
Serialization Using Message Types

When master data is distributed, interdependent objects are often distributed together (for example,
purchasing info record is distributed with vendor and material). With serialized message distribution IDocs
are created, dispatched and posted in a specific order. The interdependency of objects is at message
type level and this avoids errors occurring during inbound processing of IDocs. Serialization groups in
which the messages to be used and the posting order is specified, are used to distribute interdependent
messages serially.

Example

If you distribute materials and the material classes, they must be distributed together. You cannot process
classification data in the receiver system, if this system does not also have the data of the material to be
classified. For this reason materials should be included with the associated classifications in a
serialization group. To use serialized distribution you must carry out the following steps in Customizing:

Steps to be followed: -

 Define Serialization Groups

 Assign Message Types to the Serialization Group

In addition to the message types used, the dispatch of the message type SERDAT must be modeled in
the distribution model.

STEP 1  Define Serialization Groups

In this section you create serialization groups and assign message types and the processing order to
each group. Both the sender and the receiver of the serialization group must know the assignments. This
means this step needs to be carried out in both the receiving system and the sending system.

Serialization groups are required to distribute interdependent objects together so that they are processed
in the correct order.

Example

The message types MATMAS (material master) and CLFMAS (classification) are assigned to a
serialization group for dispatching materials and their accompanying classifications. The message type
MATMAS is assigned the suffix 1 and the message type CLFMAS the suffix 2, so that the materials are
processed first and then the classifications.

http://saptechnical.com/Tutorials/ALE/Serialization/page1.htm
Question 22: Important tcodes in ALE Idocs.
Question 23: Important programs in ALE Idocs:
ANS : These common IDOCs reprocessing questions and answers will come in handy for those who are
supporting users who are using SAP EDI.

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 

 

Reprocessing IDOCS with status 52

Any report or transaction name for reprocessing IDOC with status 52.

Run program RC1_IDOC_SET_STATUS to change the IDoc status 52 to 64 and run program RBDINPUT
to reprocess the IDoc. 
 

IDOC Reprocess Status 03

How to reprocess idocs in status 03 through BD87?

I can give you a work around though:

1) Go to WE19 enter your IDOC number which already has status 03 and execute.

2) On the next screen, it will display the IDOC, choose appropriate button on toolbar (standard Function
Module) to process it.

3) This will generate the new IDOC similar to the one which was posted completely.

4) Now the new IDOC should have status ready (Unless you have clicked Process Immediately in WE21
for this message type, it should be execute by Background Job).

This approach is applicable for testing. 

 

Reprocess the IDOC without using BD87

How to reprocess the IDOC without using BD87?

See the status of the record and process the below program using Submit report (SA38/SE38) by passing
Idoc number:

Program RBDMANI2 for status 51 & 52

Program RBDAPP01 for status 64 ,66

Program RBDAGAIE for status 32 and 69 (Edited IDocs)

Program RBDSYNER for status 26

Program RSEOUT00 for status 30

Re-process IDocs failing in 29 status, use program RBDAGAIN. 

 

Reprocess 26 Status Outbound IDOCS

We had many idocs which failed due to syntax error. We have fixed that error and now want to reprocess
those idocs. We tried BD87 and the status is 03 but it also contains idoc 25 which we want to get rid of. Is
there any transaction / PROGRAM In R/3 by which we can get rid of 26 status and just have 03 status.

Try this Program RBDSYNEO for status 26 and it will give you the desired result. You can check this
program RBDAGAIN /  Tcode BD83 for status 02, 04, 05, 25, 29.

http://www.gotothings.com/bc/programs-for-idocs-
reprocessing.htm
Process Code
The process code is having the function module attachment ...here you will get the logic for the data
population in the idocs....simply process code contains the code of the program
Process Code
Description
Outbound Process Code
This will read application data and place data in Idoc
Inbound Process Code
This will Idoc and create corresponding application data
System Process Code
This will create work item in case some error occurs in idoc / application document processing
Status Proces Code
This will handle error that occurs when a idoc is sent to some other system

Difference between ALE and EDI

EDI, stands for Electronic Data Interchange, is the electronic exchange of structured business data
between different applications. The EDI architecture consists of
EDI-enabled applications :They support the automatic processing of business transactions.
The IDoc interface: This was designed as an open interface. The IDoc interface consists of IDoc
types and function modules that form the interface to the application.
The EDI subsystem: This converts the IDoc types into EDI message types and vice versa. This
component of the EDI architecture is not supplied by SAP.
Advantages of the EDI Process
Reduced data Entry Errors
Reduced Processing cycle time
Availability of data electronic form
Reduced Paper Work
Reduced Cost
Reduced Inventories and Better Planning
Standard Means of Communicating
Better Business Processes
Competitive Advantage
ALE
PURPOSE
ALE supports the distribution of the business functions and process across loosely coupled R/3
systems. Connections from R/2 and non SAP systems is also supported.
IMPLEMENTATION CONSIDERATIONS
Distributing business applications and at the same time ensuring data consistency is practical
because:
The increasing globalization of markets has led to the physical division of organizational units.
Business processes are not restricted to one organization only and an increasing number of
customers and vendors are involved.
The performance of an R/3 System can be improved by distributing the business applications.
Features
ALE supports:
Distribution of applications between different releases of R/3 Systems
Continued data exchange after a release upgrade without requiring special maintenance
Customer-specific extensions.
Communication interfaces that allow connections to non-SAP systems.
Coupling of R/3 and R/2 Systems.
ALE has functions for controlling messages flows (Audit) and for eliminating malfunctions.
Differences between the two:
ALE is used to support distributed yet integrated processes across several SAP systems whereas
EDI is used for the exchange of business documents between the systems of business partners
ALE is SAPu2019s technology for supporting a distributed environment whereas EDI is a process
used for exchange of business documents which now have been given a standard format
Both ALE and EDI require data exchange. An Idoc is a data container which is used for data
exchange by both EDI and ALE processes.

Idoc Process End to End

ALE (Application Linking and Enabling)

Ale Technology is SAP’s technology to support distributed yet integrated processes across several
SAP systems.
Distributed Process:
A distributed process is one in which part of a business process is carried out on one system and
part on another. The two systems would exchange data with each other at appropriate points to stay
synchronized.
Need for Distributed Process:
• Business in Different Geographical Locations.
• Non availability of dedicated network.
• Cultural and language differences in Geographical locations.
• Running of Mission-critical Applications (Like Maintenance downtime etc.).
• Separate up gradation of Modules.
Distributed SAP SYSTEM – CHALLENGES
• A system that understands the syntax and semantics of the data. It was important from the very
beginning to base the distribution of data on business rules, not on database replication techniques.
• Distributed systems that can maintain their autonomy while being integrated as one logical SAP
system. The systems should be able to operate independently and support logical processing of
transactions and data.
• Distributed systems that can handle different data models. A local implementation should be able
to customize the system to meet its local needs.
• Receiving systems that can handle their own problems and not tie up the sending system.
• Systems that maintain continued operation in spite of network failure. Changes made to either
system should be synchronized after the network connection is restored.
• A sound technology and methodology that can be used in all distribution scenarios.
SAP Distributed environment:
ALE allows for efficient and reliable communication between distributed processes across physically
separate SAP systems.
ALE is based on application to application integration using messaging architecture. A message
defines data that is exchanged between two processes. IDocs are containers that hold data
exchanged between the two systems.
Benefits of ALE:
• Integration with non-SAP systems: ALE architecture allows third party applications to integrate with
SAP system.
• Reliable Distribution: Once message type created and the receiver of the message is determined,
ALE delivers the message to the recipient. If there is any network problem it will buffer the message
and delivers the message once the network is restored. It also ensures that the message is not
delivered twice.
• Release Upgrade: Any of the distributed system can be upgraded to the new release of SAP
without affecting the functionality. The ALE layer ensures backward compatibility of messages
exchanged between systems.
ALE Architecture:
It consists of an Outbound process, an Inbound process, and an Exception – Handling process.
Outbound Process:
ALE Outbound Process in SAP sends data to one or more SAP Systems. It involves four steps.
1. Identify the need of IDoc: This step starts upon creating a application document, can relate to a
change to a master data object.
2. Generate the Master IDoc: The document or master data to be sent is read from the database and
formatted into an IDoc format. This IDoc is called as a Master IDoc.
3. Generate the Communication IDoc: The ALE Service layer generates a separate IDoc from the
Master IDoc for each recipient who is interested in the data. Separate IDocs are generated because
each recipient might demand a different version or a subset of the Master IDoc. These recipient-
specific IDocs are called Communication IDocs and are stored in the database.
4. Deliver the Communication IDoc: The IDoc is delivered to the recipients using an asynchronous
communication method. This allows the sending system to continue its processing without having to
wait for the destination system to receiver or process the IDoc.
Inbound Process:
The inbound process receives an IDoc and creates a document in the system.
1. Store the IDoc in the database: The IDoc is received from the sending system and stored in the
database. Then the IDoc goes through a basic integrity check and syntax check.
2. Invoke the Posting Module: The control information in the IDoc and configuration tables are read
to determine the posting program. The IDoc is then transferred to its posting program.
3. Create the Document: The posting program reads the IDoc data and then creates a document in
the system. The results are logged in the IDoc.
Over view of IDocs:
IDoc is a container that is used to exchange data between any two processes. The document
represented in an IDoc is independent of the complex structure SAP uses to store application data.
This type of flexibility enables SAP to rearrange its internal structure without affecting the existing
interface.
IDoc interface represents an IDoc Type or IDoc data. IDoc Type represents IDoc’s definition and
IDoc Data is an instance of the IDoc Type.
IDoc Types:
IDoc type structure can consist of several segments, and each segment can consist of several data
fields. The IDoc structure defines the syntax of the data by specifying a list of permitted segments
and arrangement of the segments. Segments define a set of fields and their format.
An IDoc is an instance of an IDoc Type and consists of three types of records.
i. One Control record: each IDoc has only one control record. The control record contains all the
control information about an IDoc, including the IDoc number, the sender and recipient information,
and information such as the message type it represents and IDoc type. The control record structure
is same for all IDocs.
ii. One or Many Data records: An IDoc can have multiple data records, as defined by the IDoc
structure. Segments translate into data records, which store application data, such as purchase
order header information and purchase order detail lines.
iii. One or Many Status records: An IDoc can have multiple status records. Status record helps to
determine whether an IDoc has any error.
Message in IDoc Type:
A Message represents a specific type of document transmitted between two partners.
Outbound Process in IDocs:
Outbound process used the following components to generate an IDoc. A customer model, and IDoc
structure, selection programs, filter objects, conversion rules, a port definition, an RFC destination, a
partner profile, service programs, and configuration tables.
The Customer Model:
A customer model is used to model a distribution scenario. In a customer model, you identify the
systems involved in a distribution scenario and the message exchanged between the systems.
Message control:
Message control is a cross application technology used in pricing, account determination, material
determination, and output determination. The output determination technique of Message control
triggers the ALE for a business document. Message control separates the logic of generating IDocs
from the application logic.
Change Pointers:
The change pointers technique is based on the change document technique, which tracks changes
made to key documents in SAP, such as the material master, customer master and sales order.
Changes made to a document are recorded in the change document header table CDHDR, and
additional change pointers are written in the BDCP table for the changes relevant to ALE.
IDoc Structure:
A message is defined for data that is exchanged between two systems. The message type is based
on one or more IDoc structures.
Selection Program:
Is typically implemented as function modules, are designed to extract application data and create a
master IDoc. A selection program exists for each message type. A selection program’s design
depends on the triggering mechanism used in the process.
Filter Objects;
Filter Objects remove unwanted data for each recipient of the data basing on the recipients
requirement.
Port Definition:
A port is used in an outbound process to define the medium in which documents are transferred to
the destination system. ALE used a Transactional RFC port, which transfers data in memory buffers.
RFC Destination:
The RFC destination is a logical name used to define the characteristics of a communication link to a
remote system on which a function needs to be executed.
Partner Profile:
A partner profile specifies the components used in an outbound process(logical name of the remote
SAP system, IDoc Type, message type, TRFC port), an IDoc’s packet size, the mode in which the
process sends an IDoc (batch versus immediate), and the person to be notified in case of error.
Service Programs and Configuration Tables:
The outbound process, being asynchronous, is essentially a sequence of several processes that
work together. SAP provides service programs and configuration tables to link these programs and
provide customizing options for an outbound process.
Process flow for Distributing Transactional Data:
Transactional data is distributed using two techniques: with Message control and without message
control.
Process flow for Distributing Master Data:
Master data between SAP systems is distributed using two techniques: Stand alone Programs and
Change Pointers.
Triggering the Outbound Process via Stand-Alone Programs:
Stand-Alone programs are started explicitly by a user to transmit data from one SAP system to
another. Standard Programs for several master data objects exist in SAP. Ex. The material master
data can be transferred using the RBDSEMAT program or transaction BD10.
The stand-alone programs provide a selection screen to specify the objects to be transferred and the
receiving system. After the stand-alone program is executed, it calls the IDoc selection program with
the specified parameters.
Triggering the Outbound Process via Change Pointers:
The change pointer technique is used to initiate the outbound process automatically when master
data is created or changed.
A standard program, RBDMIDOC, is scheduled to run on a periodic basis to evaluate the change
pointers for a message type and start the ALE process for distributing the master data to the
appropriate destination. The RBDMIDOC program reads the table TBDME to determine the IDoc
selection program for a message type.
Processing in the Application Layer:
The customer distribution model is consulted to make sure that a receiver has been defined for the
message to be transmitted. If not, processing ends. If at least one receiver exists, the IDoc selection
program reads the master data object from the database and creates a master IDoc from it. The
master IDoc is stored in memory. The program then calls the ALE service layer by using the function
module MASTER_IDOC_DISTRIBUTE, passing the master IDoc and the receiver information.
Processing in the ALE Interface Layer:
Processing in the ALE Layer consists of the following steps:
• Receiver Determination: The determination of the receiver is done through Customer Distribution
Model.
• IDoc Filtering: if an IDoc filter is specified in the distribution model for a receiver, values in the filter
are compared against the values in the IDoc data records. If a data record does not meet the filter
criteria, it is dropped.
• Segment Filtering: For each sender and receiver combination, a set of segments that are not
required can be filtered out.
• Field conversion: Field values in data records are converted by using the conversion rules specified
for the segment.
• Version change for segments: Segments are version-controlled. A new version of a segment
always contains fields from the preceding version and fields added for the new version. Release in
IDoc type field of the partner profile to determine the version of the segment to be generated.
• Version change for IDocs: IDocs are also version controlled. The version is determined from the
Basic Type field of the partner profile.
• Communication IDocs generated: The final IDoc generated for a receiver after all the conversions
and filtering operations is the communication IDoc. One master IDoc can have multiple
communication IDocs depending on the number of receivers identified and the filter operations
performed. IDoc gets the status record with a status code of 01 (IDoc Created).
• Syntax check performed: IDoc goes through a syntax check and data integrity validation. If errors
found the IDoc get the status of 26 (error during syntax check of IDoc – Outbound). If no errors
found the IDoc gets the status 30 (IDoc ready for dispatch – ALE Service).
• IDoc dispatched to the communication Layer: In the ALE process, IDocs are dispatched using the
asynchronous RFC method, which means that the sending system does not await for data to be
received or processed on the destination system. After IDocs have been transferred to the
communication layer, they get a status code 01 (Data Passed to Port OK).
Processing in the Communication Layer:
To dispatch an IDoc to a destination system, the system reads the port definition specified in the
partner profile to determine the destination system, which is then used to read the RFC destination.
The RFC destination contains communication settings to log o to the remote SAP system. The
sending system calls the INBOUND_IDOC_PROCESS function module asynchronously on the
destination system and passes the IDoc data via the memory buffers.
Inbound Process in IDocs:
An inbound process used IDoc structure, posting programs, filter objects, conversion rules, a partner
profile, service programs, and configuration tables to post an application document from an IDoc.
Posting Program:
Posting programs, which are implemented as function modules, read data from an IDoc and create
an application document from it. A posting program exists for each message. Each posting program
is assigned a process code. A process code can point to a function module or a work flow. In the
standard program process codes always point to a function module.
Ex. The posting program for message type MATMAS is IDOC_INPUT_MATMAS which has a
process code MATM.
Workflow:
A workflow represents a sequence of customized steps to be carried out for a process. The workflow
management system is used to model the sequence, identify information required to carry out the
steps and identify the person responsible for the dialog steps.
Partner Profile;
A partner profile specifies the components used in an inbound process (partner number, message
type, and process code), the mode in which IDocs are processed (batch versus immediate), and the
person to be notified in case of errors.
Process flow for the Inbound process via a Function Module:
In this process, IDocs are received from another system and passed to the posting function module
directly.
1. Processing in the communication Layer:
The IDOC_INBOUND_ASYCHRONOUS program, triggered as a result of an RFC from the sending
system, acts as the entry point for all inbound ALE processes. The IDoc to be processed is passed
as an input parameter. Control is transferred to the ALE/EDI layer.
2. Processing in the ALE/EDI Interface Layer:
• Basic integrity check: A basic integrity check is performed on the control record.
• Segment Filtering and conversion: Filtering out unwanted segments and carry out any required
conversion of field values.
• Creation of Application IDoc: The application IDoc is created and stored in the database and a
syntax check is performed. If there are errors it gets status code of 60 (Error during Syntax check of
IDoc – Inbound). At this point a tangible IDoc, which can be monitored via one of the monitoring
transactions, is created and the IDoc gets status code 50 (IDoc Added).
• IDoc Marked ready for Dispatch: IDoc gets the status code 64 (IDoc ready to be passed to
application).
• IDoc is passed to the posting program: The partner profile table is read. If the value of the
Processing field is set to Process Immediately, the IDoc is passed to the posting program
immediately using the program RBDAPP01.
3. Processing in the Posting Module:
The process code in the partner profile points to a posting module for the specific message in the
IDoc. The posting program implemented as a function module either calls a standard SAP
transaction by using the Call Transaction command for posting the document or invokes a direct
input function module.
The results of execution are passed back via the function module’s output parameters. If the posting
is successful IDoc gets the status code 53 (Application Document Posted) or it gets status code 51
(Error: Application Document Not Posted).

1.      Flat File Creation

How can I create a flat file from IDOC file generated through transaction code WE19 for outbound processing?

ANSWER:

Choose the standard outbound processing and send the created IDOC file to your file. Port type file is maintained in
transaction codes WE20 and WE21.

2.      Qualifiers and Message Types

Where can I find documentation on what each qualifier is and what is mandatory for message types in general?

ANSWER:

View the User Settings on transaction code WE60.

3.      Filter Group Creation

When I am creating my distribution model and adding my Z message I do not have the option to add filter groups. How do I
create a filter group for my message?

ANSWER:

To create a filter group, implement transaction codes BD59and BD95.

4.      Searching Within IDOC Files

If an IDOC file fails because data within the IDOC file is not correct, is there a fast way to search for error lines within the
IDOC file?

ANSWER:

Table EDID4 includes all the header and segment data of an IDOC file. Use transaction code SE16 to data browses the
table. Another alternative is to implement transaction code WE09 or WE10. It retrieves IDOC files that match the condition
you input (e.g. segment, field and value.).

5.      How to Set IDOC File Status Using ABAP Routine

I have an ABAP program that reads several IDOC files with status 3 (port OK). After processing them I must change the
status to 6 (translation OK). Is there a function module or routine in ABAP that does this or if I should modify it directly in
table EDIDC?

ANSWER:

You should use the following function modules to change an IDOC file status: EDI_DOCUMENT_STATUS_SET,
IDOC_STATUS_WRITE_TO_DATABASE.

6.      Application Link Enabling (ALE) Interface Definition

What is an Application Link Enabling interface?

ANSWER:

ALE or Application Link Enabling is the technical basis for integrating business processes in a distributed system
environment. It includes developer and testing tools and preconfigured Application Link Enabling Business Processes
delivered in the standard R/3 Release. Application Link Enabling has functions for managing messaging and for handling
communication and application errors.

7.      Determining IDOC File Source

Is it possible to determine if the source of an IDOC file is Application Link Enabling or     EDI?

ANSWER:

Yes, if the IDOC file Control is Logical System, then the IDOC file is from Application Link Enabling. Otherwise, it is EDI.

8.      Processing an IDOC File through Transaction Code BD87

When I attempt to process an IDOC file through transaction code BD87, I receive the following error: ‘No batch data input for
screen’. Application document not posted. What am I doing wrong?
ANSWER:

Some of the SAP standard function modules for processing IDOC files internally use BDCs. The problem is with the BDC
and it could be either missing data for the screen or it could also be a pop-up message. Analyse the screen fields. You could
also reprocess this IDOC file via transaction codeWE19 instead of transaction code BD87. In transaction codeWE19 you
should tell the system to process the IDOC file in foreground and this should bring up the BDC screen.

9.      IDOC File Error during Application

I tried the IDOC file in transaction code BD87 in foreground but I am receiving the error message: Error during application
process. What is the problem?

ANSWER:

Before reprocessing the IDOC file, you must analyse the message of the application error to suppress the cause. You
should receive the detailed message from transaction codeBD87 by double-clicking on the status 51. For example, you may
have an error because you are attempting to post on a closed financial period. You must open the period before attempting
to process again (or create an IDOC file with a different date if your business process does not allow posting in the past.)

10.  IDOC File Status History

How do you view the IDOC file status history?

ANSWER:

Select the IDOC file with transaction code WE02. Double-click on the IDOC file you wish to display. On the left side, you will
have both the IDOC file content (segments) and the status history (successive status values). By clicking on the status, you
will receive even more details, such as time and user ID.

11.  Error in Inbound IDOC File

 If there is an error in inbound IDOC file, can SAP send out email?

ANSWER:

It is possible to still send email by using workflow event inputErrorOccurred. For basic configuration of this event, you should
refer to SAP Help - Application Link Enabling Programming Guide - Error Handling. You may need to add an e-mail
distribution step by yourself.

12.  IDOC File Status Conversion

I have a problem with HR Payroll and FI/CO interface. I have an IDOC file in status 64 that is not receiving posted date nor
is an application document created. Normally IDOC file converts to status 62 and then 53 automatically. Where am I going
wrong? 

ANSWER:

Status 64 means that IDOC file is waiting to be processed yet. Usually it occurs on a busy system when there are no free
resources available at the time the IDOC file arrives. Your system might not be configured to process these IDOC files
automatically when system recourses are available. Ask your BASIS to implement a SAP note dealing with the issue.
Meanwhile, you may re-process IDOC files manually via transaction code BD87 (select node/message with status64 and
click ‘Process’ button). This can also be related to workflow. Please check your event linkage. Also KBA 1776428 might be
of help.
1. What is the difference between repair and correction in sap?

SAP system present in customer environment is copy of

original system which is at SAP itself. That means all the
objects present in customer environment are copy of the
object originally created in SAP environment.

So, If we modify copy of object then it is called as repair

and assigned to development task repair. Repair of object is
also called as modification.

Whereas if we modify object in it's original system where it

is actually created may it be SAP system or the objects
created by customer in customer environment. Then such
changes is called as corrections and assigned to task
Development/Correction

2. Where all the Idocs get stored after creation?

EDIDC stores control/header record.

EDIDD/EDID4 stores data records.
EDIDS stores status records.

3. I HAVE GENERATED AN IDOC WITH ERROR AGAIN WHEN IAM GENERATING IT.
IT IS GENERATED WITH DIFFERENT IDOC NUMBER. BUT I WANT THE SAME NO
PREVIOUSLY IT IS GENERATED?

You can use BD87 if you want to reprocess same idoc 

number,here it will not generate new idoc number.
suppose there was RFC Issue ,connection got failed then 
after rectifying RFC Connection then you can reprocess
same idoc number.

in case data is missing,then you need to WE19 Transaction -

> enter idoc number -> fill the missing data.
just drag the segments ,here you can fill data where ever 
required.

If you use WE19 then it creates new idoc ,it gives work 
flow message.

4. Suppose i was sent 10 records using outbound in ale/idoc 8 records are up dated
in data base tables what happend remaing records did not showing error in we02?
u r trying to generate the idocs with 10 
records, and u find only 8 (records) idocs created rest
(records) are missing.

Check with the filter set up for the records for its 
receiving partner system(logical system). 

Correct the filters then try regenarating the idocs(missing 

records).

5. What is the diff between sap memory and abap memory?

SAP memory (Global Memory): - is available to a user during 

the entire duration of a terminal session. Its contents are 
retained across transaction boundaries as well as external 
and internal sessions.

ABAP/4 memory 
The contents of the ABAP/4 memory are retained only during 
the lifetime of an external session (see also Organization 
of Modularization Units). You can retain or pass data 
across internal sessions. The EXPORT TO MEMORY and IMPORT 
FROM MEMORY statements allow you to write data to, or read 
data from, the ABAP memory.

6. Explain some real time scenarios in ALE IDocs?

- communicating between two physically separated systems. 

Either SAP to SAP or SAP to Non-SAP ,we use IDOC.

- SAMPLE Scenario is a new custom ALE where the receiver of an 

internal service must be able to reverse the invoice receipt, 
which will then cancel the applicable billing document 
automatically on the service providers system. To avoid the conflicts between two systems.

7. What is the difference between template and table in smart forms?

Table node:tables are dynamic because the table size depend 

on the amount of tha data selected at runtime.

Templete node:templetes are static because the no of column 

and lines are determind before the actual output.

8. how to reprocessing the idoc?

If you have any error in IDOC u can edit it by using we02 tcode,
after that you can reprocess the corrected IDOC by using bd87
tcode.
9. Can we, generate i doc for more than 1 vendor.
i.e can we generate idoc for more than 1 po order?

No it is not possible.because vendor number or po numbers 

are the uniqe.so it can holds the same vendor or po number 
uniquely.

10. How to debug IDOC manually? if i want to extend the standard IDOC say
MATMAS, where we have to write code for extension?

For errors we need to check for the status codes and cming to
debug we can debug our the assingned function module i.e
idoc_input_matmas05 or z(fun module) in case of custom and
while processing in bd87 the complete idoc can be processed
by selecting the option available.

Download Interview PDF  

11. Why we need to create RFC destination from PI to R/3?

pi(process integration) itself acts as middleware for

creating connection between A2A OR B2B SCENARIOS.pi provides
sinle point of integration.

12. What is the table for trfc port?

'TidDatabaseConnectionString' this is the type of port for

processing idoc's.

DIFFERENT TYPES OF PORTS

1.TRFC --> IDOCS/ALE

2.XML --> JAVA
3.FILE PORT --> IDOCS
4.INTERNET --> WEB APPLICATIONS
................

13. What is the main difference between ALE/IDOC and BAPI?

ALE/IDocs are used for asynchronous information 

interchange.while BAPIs are used for synchronous 
information interchange

14. Without using the distribution model, can we send data from one system to
another system by using ALE?
no we con't send.because When ever we try to send an IDOC 
it checks with distribution model and is there any 
filtering is defind or not, if it is defined then checks 
with filter data and then it checks with reciver and 
messagetype.

15. How to send the idoc to multiple sub systems?

If you are sending one idoc is to more systems you are 

create one sender logical system and more recive logical 
systems in T.CODE is SALE. then yoou are send In T.CODE 
BD64.

16. What is the main difference between interfaces and XI, I think both are cross-
applications right? What is the exclusive difference?

According to my knowledge in SAP XI we have so many kind of 

control levels to process the message. For instance i will 
discuss on few points, like
1) Here using XI we can communicate with the SAP or Non-SAP 
at sender side or reciever side.
2) XI supports both Syncronus and asyncronus communications
3) in XI we can find the status of the message where it is 
during the process of Message processing.
4) We have so many kinds of monitoring techniques.
5) Here we can have N number of senders and N number of 
recievers based on your requirement.
6) It supports to process multiple messages at a time from 
different senders to multiple recievers.
So I feel we cant perform all these things in 
Interfaces.That is the reason XI come into picture.

17. When idoc is created in which table its stored?

EDIDD to store data records.

EDIDC to store control information.
EDIDS to store status of IDOC

18. How to debug an idoc?

for outbound we can send through program or

functionmodule.but inbound idoc only through function
module.so its depends wheather it is outbound or
inbound.then we will debug

19. While sending idoc from receiver side i got msg type 3 and 12.but in receiver side
while executing we02, i am gettig the error no idocs selected instead of getting 
msg type 53.i am simply sending a material from one client to another client?
The very first setting you need to check is in distribution 
model if the message type is configured for given sending 
recieving system combination.if this is correct and partner 
profile is wrong, you will get an IDoc stuc in 56 status on 
inbound.
You can also check in we09 with giving more details like 
segment name (related to MARA table ) and the corresponding 
material no. in the field for selection with MATNR.

20. How the data is coming from 3rd party system to SAP System?

Data from 3rd party can come from middleware tools like MERCATOR. Also data can from
3rd Party from email or fax also. This can be done by intergration mail system with SAP
inbox. 

The usual connection for middle ware tool can be type 4 TCP/IP - depending upon the
setting of your gateway server properties one can integrate SAP with other party
Middleware systems.

21. Where to see idoc in inbound side whether it is received in receiver system or
not?

By executing Conversion Program RBDMOIND... 

1) Execute RBDMOIND in outbound program
2) If the status code is convert into 3 to 12 then we can 
confirm the IDOC received successfully..

22. Suppose their is one sender and we have three receivers.

While generating an IDOC will it generate 3 IDOCs for three receivers? Explain in
detail how the flow goes from outbound to inbound systems?

in SALE we maintain the Sendor as well as three Receivers

(how many receivers to send the same idoc),
and assign the sendor in sendor system as well as assign 
receivers in receivers system(sale-->assignment) three 
receivers.

maintain the RFC destination on sendor side and all 

receiver side also (sm59).

maintain the port for sendor and three receivers.

maintain the sendor and all receivers for a same message 

type in distribution model.(bd64)

maintain the partner profiles for sendor and all receiver 

side also (we20).
execute the outbound program(idoc generation)like BD12 for 
DEBMAS message type .

check out the status using we02 or we05.

23. Can we attach more than one messages with One IDOC?

yes, we can attach more than one message types to one idoc. 
For example sendor wants the records on both material and 
purchase at same time then we need to add two message types 
to one idoc.

24. Which type of workprocess can execute only once in r/3 system(sap)?

Dialog work processor