Idoc processing

[Former Member]

Hi Experts,

I need your help .I am very new in Idoc kindly provide me some valuable document with steps for reprocessing Idoc which is fail.

Thanks in Advance.

Ankur Garg.

[Former Member]

Hello Ankur Garg,

You can reprocess a failed IDOC using transaction BD87. But before that, you have to correct the error that caused the failure. You may find a hint for the error in status records (WE05).

Thanks,

Venu

[Former Member]

Hi Ankur,

To reprocess an Idoc which is failed follow the steps:

For failed transactional data ,

At Inbound side(51 status).

1. In the partner system open transaction SE38.

2.Use program RBDMANI2.

3.Give the Idocs and save as background job.

4.Go to SM36 and run the job.

5.Check the Idocs in the spool.

For Outbound error i.e in 02 status,

1.In partner sys open SE38.

2.Use RBDAGAIN program and run a job.

3.The Idocs will be in 30 status now.

4.Now in SE38 again,use RSEOUT00 and run a job which would then pass the Idocs to the port,which is a success state(03 status).

Hope its useful,

Sravani

Please assign points if useful.

[Former Member]

Hi Ankur

Pls find this material.

Pls reward pts also.

Regards

Deepanker.

ABAP IDOC PROCESSING

Creating and processing IDocs is primarily a mechanical task, which is certainly true for most interface programming. We will show a short example that packs SAP R/3 SAPscript standard text elements into IDocs and stores them.

Outbound IDocs from R/3 are usually created by a function module. This function

module is dynamically called by the IDoc engine. A sophisticated customising

defines the conditions and parameters to find the correct function module.

The interface parameters of the processing function need to be compatible with a

well-defined standard, because the function module will be called from within

another program.

IDoc inbound functions are function modules with a standard interface, which will

interpret the received IDoc data and prepare it for processing.

The received IDoc data is processed record by record and interpreted according to

the segment information provided with each record. The prepared data can then be

processed by an application, a function module, or a self-written program.

The example programs in the following chapters will show you how texts from the

text pool can be converted into an IDoc and processed by an inbound routine to be

stored into another system.

The following will give you the basics to understand the example:

SAP R/3 allows the creation of text elements, e.g. with transaction SO10. Each

standard text element has a control record which is stored in table STXH. The text

lines themselves are stored in a special cluster table. To retrieve the text from the

cluster, you will use the standard function module function READ_TEXT . We

will read such a text and pack it into an IDoc. That is what the following simple

function module does.

If there is no convenient routine to process data, the easiest way to hand over the

data to an application is to record a transaction with transaction SHDB and create a

simple processing function module from that recording.

Outbound routines are called by the triggering application, e.g. the RSNAST00

program.

Inbound processing is triggered by the central IDoc inbound handler, which is

usually the function module IDOC_INPUT . This function is usually activated by

the gatekeeper who receives the IDoc.

Outbound is triggered by the application.

Inbound is triggered by an external event.

The most difficult work when creating outbound IDocs is the retrieval of the application data which needs sending. Once the data is retrieved, it needs to be converted to IDoc format, only.

Each R/3 standard text element has a header record which is stored in table STXH.

The text lines themselves are stored in a special cluster table. To retrieve the text

from the cluster, you will use the standard function module function

READ_TEXT.

The program below will retrieve a text document from the text pool, convert the text

lines into IDoc format, and create the necessary control information.

The first step is reading the data from the application database by calling the

function module READ_TEXT.

Our next duty is to pack the data into the IDoc record. This means moving the

application data to the data part of the IDoc record structure EDIDD and filling the

corresponding segment information.

Finally, we have to provide a correctly filled control record for this IDoc. If the IDoc routine is used in a standard automated environment, it is usually sufficient to fill the field EDIDC-IDOCTP with the IDoc type, EDIDC-MESTYP with the context

message type and the receiver name. The remaining fields are automatically filled

by the standard processing routines if applicable.

Inbound processing is basically the reverse process of an outbound.. The received IDoc has to be unpacked, interpreted and transferred to an application for further processing.

The received IDoc data is processed record by record and data is sorted out according to the segment type.

When the IDoc is unpacked data is passed to the application.

Finally the processing routine needs to pass a status record to the IDoc processor.

This status indicates successful or unsuccessful processing and will be added as a

log entry to the table EDIDS.

The status value '51' indicates a general error during application processing and the

status '53' indicates everything is OK.