SAP ALE Idoc Overview 2Hrs

ALE (Application Linking Enabling)

&

IDOC (Intermediate Document)

2

What is an Idoc ?

Idoc structure

Extending Idoc vs New/Custom Idoc

Idoc Archiving Procedure

What is an ALE ?

ALE vs EDI

ALE Components

ALE Process (Outbound/Inbound)

Idoc and Workflow Integration

Appendix

Contents

3

Intermediate document

It is not a process

It is a data container used to exchange information between any two

processes(SAP to SAP or SAP to non-SAP) that can understand the syntax

and semantics of the data

In the SAP system, these are stored in database tables

Every IDoc has an unique number

Independent of the sending and receiving systems

IDocs are based on EDI standards, ANSI ASC X12 and EDIFACT, but are

closer to the EDIFACT standards

Independent of the direction of data exchange

Can be viewed in a text editor and do not contain any binary data

IDoc

4

Basic IDoc type

This defines the structure and format of the business document that is to be

exchanged between two systems.

Generally called IDoc type.

A basic IDoc type has the following characteristics.

• Name. A basic IDoc type can be assigned up to a thirty−character name. Custom

IDoc types always start with ‘Z’. The last two characters are the version number.

After a basic IDoc type is released and you move to a newer version of the SAP

system, any changes to the structure of the basic IDoc type will create a new

basic IDoc type. In general, the version number is incremented by one.

Ex: Z1STUREC.

• List of permitted segments. These segments make up the IDoc structure.

Ex: Z1STUSG

• Hierarchy of segments. The hierarchy of segments specifies the physical

sequence and any parent−child relationship in the segments. A parent−child

relationship signifies that the child segment cannot exist without the parent.

IDoc Definition Components

5

Basic IDoc type contd.

• Mandatory versus optional segment. When used in an IDoc type, each segment has

an attribute that defines whether the segment is optional or mandatory.

• Minimum/maximum range for each segment. When used in an IDoc type, each

segment has an attribute that defines the minimum and the maximum number of times

a data record corresponding to a segment can exist in an IDoc.

Basic IDoc type Z1STURECIDoc segments


6

Segments

This defines the format and structure of a data record.

These are reusable components i.e. can be used in more than one IDoc type.

Segment components

• Segment type : This is version−independent name of the segment. SAP−provided segment

types begin with E1, whereas custom−defined segment types begin with Z1.

Segment Type

Segment Definition


7

Segments contd.

• Segment definition : This can be more than 1000 bytes. SAP segment

definitions start with E2, whereas customer segment definitions start with Z2. The

name of a segment definition is 30 characters long and is automatically assigned

by the system from the name of the segment type. The last three characters

represent the version of the segment.

• Segment documentation : This represents the data dictionary documentation

for each field in the segment definition. Segment documentation of

SAP−provided segments begins with E3, whereas the segment documentation of

customer−defined segment types begins with Z3. There is only one segment

documentation per segment.

Data Fields

A data field represents a single data item that is used in a segment. All data field

values must be alphanumeric values.

The valid data types for a field are CHAR, CLNT, CUKY, DATS, LANG, and NUMC.


8

An IDoc is an instance of an IDoc type.

At run time the following events occur.

A unique IDoc number is allocated.

One control record is attached to the IDoc.

Segments translate into data records.

Status records are attached.

Syntax rules are checked.

Although there are several records in an IDoc, they are still classified as one of the

three record types.

• Control record

• Data record

• Status record

The IDoc number is the element that ties the control records, data records, and

status records together.

IDoc Runtime Components

IDoc Runtime Components contd.

9

10

An IDoc type consists of three parts:

• Control Record: This section contains control information regarding the IDoc. Its

constituents are Sender’s name, Receiver name, Message type and IDoc type.

The format of the control record is similar for all IDoc types. The values are

stored in table EDIDC.

• Data Record: It consists of a header that contains the identity of the IDoc. Its

constituents include, a sequential segment number, a segment type description

and field containing the actual data of the segment. The values are stored in

table EDID4 or EDID3.

• Status record: This shows the information regarding the already processed

stages and remaining processing stages of the IDoc. It has an identical format for

each IDoc type. The values are stored in table EDIDS.

Every IDoc contains one control record ,one or many data records and one or many

status records.

IDoc Runtime Components contd.

11

Extending IDocs

You extend a basic IDoc type when it meets most of your requirements.

Ex:

1. Extend the SAP screens to include custom fields, such as in the material master and

customer master.

2. When business partner sends you additional information or expects additional information

on an EDI document.

3. When you are interfacing with legacy systems using IDocs.

New IDocs

You create a new basic IDoc type when the standard basic IDoc types or its extension do not

meet your business needs.

Ex:

1. New basic IDoc types are developed especially for interfaces to legacy systems or

third−party products using ALE.

2. A basic IDoc type is created when an existing IDoc cannot be mapped to an EDI transaction

you want to exchange with your business partner.

3. You want to synchronize master data between two SAP systems, and this master data is not

supported in the standard system.

Extending IDoc vs New IDoc

12

Archiving:

Archiving involves Compressing & Transferring the data which is accessed less

frequently, from the database to an external storage device so that the data can

be reused at a later date.

Need for archiving:

Archiving resolves memory space and performance problems caused by large

volumes of transaction data.

Ensures that data growth remains moderate so that the database remains

manageable in the long term.

Archiving IDocs:

IDocs are stored in several database tables. To keep the access times small (to

reduce the database load), without losing any IDocs, we archive the IDocs at

operating system level. These archives can then be moved to external storage

media, such as disks (using Archive Link) or magnetic tape.

Idoc Archiving

Basic Settings for Idoc Archiving

1.Maintaining Logical File Path Definition

Transaction : FILE

Assign a logical name for the path click the new entries button and give a name stating

With Z to represent the path.

13

Basic Settings for Idoc Archiving contd.

2.Assignment of Physical Path to Logical Path

Transaction : FILE

Select the Z logical path created(Step 1) and double Click on assignment of physical

paths. Enter the syntax group and physical path by ending it with < FILENAME>

14

Basic Settings for Idoc Archiving contd.

3.Maintaining File Names

Transaction : FILE

Double click on logical file name definition and Click the new entries button .

The filename contains substitution parameters, Which are represented in angle

brackets .

15

16

Search the IDocs using transaction WE09.

After searching the IDocs, we need to check the status of the IDocs we need to

archive.

Certain IDoc statuses are classified as archivable in the standard system, while

others are not.

The list of status code which can be processed for archiving we can get it from

table STACUST .

The current status of an IDoc must be archivable before the IDoc can be archived.

For example, an IDoc which was not processed yet cannot be archived. And the

IDoc with the status code 53 (posted successfully) can be archived. So in order

to archive an IDoc we need to check the status of that IDoc.

There are two ways to archive an IDoc

1. Through standard report programs

2. Through the central archiving transaction SARA.

Idoc Archiving Procedure

17

Application Linking Enabling(ALE)

Is an R/3 technology that enables you to construct and operate distributed

applications, sometimes in different countries.

Allows efficient and reliable communication between distributed processes.

Guarantees the distribution and synchronization of master data, Customizing data

and transaction data through asynchronous communication.

Synchronous connection is used in ALE to read data only.

ALE Introduction

18

Application data can be distributed between different releases of SAP systems

Data can continue to be exchanged after a release upgrade without requiring

special maintenance

Customers can add their own enhancements

Communication interfaces enable connections to non-SAP systems

SAP R/3 and R/2 Systems can communicate with each other

ALE Benefits

19

Differences between ALE and EDI

ALE (Application Link Enabling) is a way of transferring data between systems i.e

SAP to SAP.

EDI or Electronic Data Interchange is a process in which data is transferred

between an SAP system and another system. The latter one can be a non-SAP

system too.

The main difference between EDI and ALE is in the transfer of data.

For EDI, the transfer of data(Idocs) is through a flat file.

Where as in ALE, it is from Memory to memory transfer.

ALE vs EDI

20

Outbound Process

Sends data to one or more SAP systems

Process flow for an outbound ALE process

Inbound Process

Receives an IDoc from the remote system and creates a document in the SAP system

Process flow for an Inbound ALE process

ALE Process

21

Distributed SAP systems exchange three types of data for achieving a distributed

yet integrated environment.

Transactional data

Ex: Sales orders, purchase orders, contracts, invoices, G/L postings

Master data

Ex: Material master, customer master, vendor master, employee master

Control data

Ex: Company codes, business areas, plants, sales organizations,

distribution channels, divisions.

Transactional and Master data are distributed using the ALE interface layer.

Control data is transferred using the regular CTS (Change and Transport System)

process.

ALE Outbound

22

Idoc Type

Ex: MATMAS03

Message Type

Ex: MATMAS

Process code

Logical System

Ex: D11CLNT400

Customer Model

Ex: Z15TEG1

Selection Program

Port Definition

Ex: tRFC Port

RFC Destination

Ex: LSIDES800

Partner Profile

Ex: Partner Type LS(Logical System)

Service Program

Ex:RSEOUT00

Configuration Tables

Filter Object

Conversion Rule

ALE Outbound Components

23

Message type and IDoc 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 referred to

a Class and IDOC Type as an instance of the class Message Type.

IDOC type and message type are linked in WE82.

Outbound Components contd.

24

Process Code :

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.

Logical System

The systems involved in distributed processing are assigned logical names, which

uniquely identify systems in a distributed environment.

Customer Model

Identifies the systems involved in a distribution scenario and the messages

exchanged between the systems.


25

Selection Programs

These are implemented as those which 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

In a distributed environment, each recipient of data can have different requirements

for the data being distributed. Filter objects remove unwanted data for each

recipient of data.

Port Definition

A port is used in an outbound process to define the medium in which documents

are transferred to the destination system. ALE uses a tRFC (Transactional

Remote Function Call) port, which transfers data in memory buffers.


26

RFC Destination

The RFC (Remote Function Call) 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. In ALE, the RFC specifies information required to log on

to the remote SAP system to which an IDoc is being sent.

Partner Profile

A partner profile specifies the components used in an outbound process (the logical

name of the remote SAP system, IDoc type, message type, and tRFC port), an

IDocs packet size, the mode in which the process sends an IDoc (batch versus

immediate), and the person to be notified in case of errors.

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.


27

Basic settings for Idocs

Communication Settings

Advanced Settings

Configuring ALE Infrastructure

28

Number Range of Idocs

Transaction: OYSN

Number Range for Idoc(Inbound/Outbound):16 digit.

Basic Settings of Idocs

29

Maintaining a Logical System

Transaction : BD54

10 character alphanumeric

Note: Make an entry for both sending and receiver systems in all the systems in the distributed network.

Communication Setting – Logical System

Logical System of System A

Logical System of System B

30

Allocating Logical Systems to the Client

Transaction: SCC4

Allocate the client to the logical system in all the systems in the distributed network.

client 800

Logical system

ID2CLNT800

Communication Setting – Logical System

31

RFC Destination

Transaction: SM59

Technical settings tab

R/3 sy

stem : T

ype 3

EDI subsyste

m: Type T

IP address of the receiver system System Number

Communication Setting – RFC Destination

32

RFC Destination contd.

Logon and security tab.

Receiver system logon details

Communication Setting – RFC Destination

33

Port Definition

Transaction: WE21

SAP-non-S

AP: File

port

SAP - SAP: t

RFC port

RFC Destination

Port Definition

Port Name

34

Master data can be distributed in the following cases

1. Transferring data from Dev, Quality .. systems to production systems

2. Transferring master data from production systems to test systems

3. Transferring configuration data

Ways of exchanging master data between systems

1. Push Original Copy

2. Push Changes

3. Pull master data

Master data between SAP systems is distributed using two techniques

1. Stand−alone programs

2. Change pointers

Outbound Process- Master Data Distribution

35

Outbound Process via Stand−Alone Programs

Stand-alone programs are started explicitly by a user to transmit data from one SAP

system to another. These provide a selection screen to specify the objects to be

transferred and the receiving system. These when executed calls the Idoc selection

program which is hard-coded in the program.

Ex: Material master data can be transferred using the RBDSEMAT program or

transaction BD10.

Outbound Process via Change Pointers

This 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.

Ex: If a user changes the basic description of a material master or creates a new

material, the system automatically generates an IDoc for the material and sends it to

the destination system.

Outbound Process- Master Data Distribution contd.

36

Maintaining the Distribution Model

Transaction: BD64

Used to model a distributed environment in which you specify messages exchanged between sending and

receiving systems.

Create a model view

Distribution Model

37

Then add a message type to transfer between two systems.

Note: A distribution model is maintained on only one system. It is distributed to other systems for use. Two models cannot distribute the same message between the same set of senders and receivers.

Distribution Model contd.

Logical system names of Sender(A) and Receiver(B)

38

Transaction: BD82

Partner profiles can be generated automatically for your partner systems.

The distribution model and settings in the ALE tables TBD52 and EDIFCT are read to generate partner

profiles and port definitions.

Note: The process code and function module is taken from tables EDIFCT and TBD52.

Partner Profile

39

The partner profile can be viewed with Transaction WE20.

MATMAS Message type

Partner Profile contd.

40

Transaction:BD64

After all the necessary configurations for Model(message type, port, partner profile, logical systems)

distribute the model to the systems in the distributed network.

Note: After selecting the Distribute, select the target Logical system to proceed.

Distributing the Model

41

In this data is transferred explicitly from one system to another.

Transaction : BD10 or execute program RBDSEMAT

If kept blank, the system assumes that you want to send all the materials.

Push Approach

Receiver Logical System

42

You can view the Idoc using Transaction WE02/WE05 and by giving the necessary

details.

The Idoc contains the material master data to be transferred to the receiving system.

Outbound IdocIdoc number

Current Idoc status

Outbound Idoc View

43

Outbound Process with Push Approach by Stand-Alone Program

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: For Material master data ,the program is RBDSEMAT or transaction BD10.

Process flow for an outbound process for master data

Outbound Process- Push Approach

44

Processing in the Application Layer

Based on the receiver and the message type to be transmitted, the distribution

model is read.

If at least one receiver exists, then 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 function module

MASTER_IDOC_DISTRIBUTE, passing it the master IDoc and the receiver

information.

Outbound Process- Push Approach contd.

45

Processing in the ALE Layer

• If the receivers are not known, they are determined from the customer distribution model. If

a receiver is not found, processing ends.

• For each receiver, these steps occur.

• IDoc filtering

• Segment filtering

• Field conversion

• Version change for segments

• Version change for Idocs

• Communication IDocs generated

Based on filter operations and no. of receivers one master Idoc can have multiple

communication Idocs and are saved in SAP database . The IDoc gets a status record with a

status code of 01 (IDoc Created).

• Syntax check performed

If errors are found, Idoc gets a status code 26 (Error during Syntax Check of Idoc

Outbound). if no errors are found, the IDoc gets a status code of 30 (IDoc Ready for

Dispatch ALE Service).


46

Processing in the ALE Layer contd.

• IDocs dispatched to the communication layer

The timing of dispatch is read from the output mode in partner profile. If the mode

is set to Transfer IDoc Immed., IDocs are immediately transferred to the

communication layer; if not, they are buffered until the next run of dispatch

program RSEOUT00. If transferred to the communication layer, Idocs get a status

code of 03 (Data Passed to Port OK).

Processing in the Communication Layer

Then the system reads the port definition from the partner profile and from it the RFC

destination is known.

The sending system calls the INBOUND_IDOC_PROCESS function module

asynchronously on the destination system and passes the IDoc data via the

memory buffers. Then the Idoc gets a status code of 12(Dispatch OK).


47

The inbound process must handle three types of data.

1. Transactional data

2. Master data

3. Control data

Transactional and master data are received via the ALE interface layer.

Control data is received via the CTS process.

Ways of posting the transactional and master data

• Via a function module

• Via workflow

ALE Inbound

48

• IDoc structure

Ex: MATMAS03

• Posting programs

Ex: IDOC_INPUT_MATMAS01 for MATMAS message.

• Filter objects

• Conversion rules

• Partner profile

Ex: Partner Type KU(customer), Partner Type LS(Logical System)

• Service programs

Ex: RBDAPP01

• Configuration tables

Ex: TBD51

Inbound Components

49

Posting Programs

These 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 workflow.

Ex: For MATMAS message type ,the posting program is IDOC_INPUT_MATMAS01

and the process code is MATM.

Partner profile

This specifies the partner number, message type, process code, the mode in which

IDocs are processed (batch versus immediate), and the person to be notified in

case of errors.

An inbound record exists to receive an inbound message from remote SAP system.

Inbound Components contd.

50

Partner profile

This specifies the partner number, message type, process code, the mode in which IDocs

are processed (batch versus immediate), and the person to be notified in case of errors.

An inbound record exists to receive an inbound message from remote SAP system.

Trigger immediately

Partner Profile

Process Code

51

Process flow Technical Flow

Note:Ver:4.0x Idocs: IDOC_INBOUND_ASYNCHRONOUS

Ver:3.0x Idocs -INBOUND_IDOC_PROCESS

Inbound Process via Function Module

52

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.

Inbound Process via Function Module contd.

53

Processing in the ALE/EDI Interface Layer

Basic integrity check: On control record, direction, message type, and IDoc type is

checked.

Segment filtering and conversion.

Application IDoc is created

The application IDoc is stored in the database, and a syntax check is performed on

it. The IDoc gets a status code of 50 (IDoc Added).If the IDoc fails the syntax

check, it gets a status code of 60 (Error during Syntax Check of Idoc Inbound).

IDoc is marked ready for dispatch: Idoc gets a status code of 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.

If the field is set to Background processing, the IDoc is buffered in the system until

RBDAPP01 is executed explicitly.


54

Processing in the Posting Module

The process code in the partner profile points to a posting module for the specific

message in the IDoc.

If the posting is successful, an application document is created.

The IDoc gets a status code of 53 (Application Document Posted).

If the IDoc contains errors, it gets a status of 51 (Error: Application Document Not

Posted).


55

Inbound Idoc

You can view the Idoc using Transaction WE02/WE05 and by giving the necessary details.

Inbound ALE Idoc View

56

Reasons for Workflow Integration with Idocs

Idoc Error Handling

Idoc Status Tracking

Notification to user when an Application document is posted through Inbound

Idoc

Approval for Idoc Posting

Idoc and Workflow Integration

Thank You!

58

Idoc Error Handling is done through Workflow.

The procedure is:

1. Setup your partner profile to work as usual (including the distribution model).

2. Set a specific user in the "Post Processing Agent" field for the partner profile (WE20).

3. Perform workflow customizing in SWU3 especially "Maintain Definition Env -> Prefix

Numbers" and "Maintain Additional Services -> Activate Send to Objects and HR

Objects".

4. In SWDM (workflow builder), choose a search range.

Select the "Object" tab and entercategory: "BOR Object Type"

Obj Type: "IDOCAPPL"

Method ID: "ERRORPROCESS”

and

category: "BOR Object Type"

Obj Type: "IDOCAPPL"

Method ID: "INPUTFOREGROUND“

NOTE: IDOCAPPL is the root IDoc business object, but depending on the IDocs you want to monitor, you may

have to use a specific IDoc object e.g. IDOCMATMAS etc.

Idoc Error Handling

59

5. If you want to change the standard workflow tasks you can customize the

existing ones by copying the following standard tasks to your own tasks (based

on IDOCAPPL):TS00007989 name it: ZErrorProcO

TS00008070 name it: ZSynErrorO

TS00008074 name it: ZSynErrorIn

TS00008068 name it: ZErrorProcIn

TS20000051 name it: ZIDOC_APPL_E

6. Before any of the existing tasks can be executed by any user, you MUST ensure

that they are of type "General Task". This means that any user is a possible

agent:

7. If you have copied the standard tasks, you also need to change the "Process

Codes" table in WE40 to reflect the new tasks.

8. Make sure that the workflow linkage is active (ticked) for the

IDOCAPPL.INPUTERROROCCURED method (TS20000051) in transaction

SWE2.

9. Test by creating by Outbound/Inbound error(Use WE19 - Idoc simulation ).Then

a workflow is created and placed in user’s Business Workplace Inbox. Also a

workitem is listed in SWI1.

Idoc Error Handling contd.

Refer Table TEDS1 for all status codes.

Successful Transmission: 03 - Successful outbound transmission 12 – Dispatch OK IDoc being processed: 01 - IDoc created 30 - IDoc ready for dispatch IDoc Processed Successfully: 50 - IDoc added 53 - Successful posting IDoc ready for processing: 64 - IDoc ready to be passed to application. Errors in IDoc Processing: 51 - Error - application document not posted 56 - IDoc with errors added (You should never see this error code) 60 - Error during syntax check of IDoc (inbound) 61 - Processing despite syntax error (inbound) 63 - Error passing IDoc to application 65 - Error in ALE service - indicates partner profiles are incorrect 69 - IDoc was edited

Idoc Status

61

Main menus

WEDI Main menu for EDI−related activities

BALE Main menu for ALE−related activities

SWLD Main menu for workflow−related activities

SALE Main area for ALE configuration

NACE Main menu for Message control configuration

IDoc Definition

SE11 Data dictionary

WE31 Segment editor

WE30 IDoc editor to create and extend IDoc type

BD53 Reduce IDoc types for master data

WE60 IDoc documentation (IDoc structure and segment definition)

WE61 IDoc documentation (control record, data record, and status record)

IDoc Monitoring

WE02 IDoc display

WE05 IDoc list

WE07 IDoc statistics

AL11 SAP Directories

Transaction Codes

62

Configuration (Basic Infrastructure for ALE and EDI)

WE20 Maintain partner profile manually

BD82 Generate partner profiles automatically

WE21 Port definitions

SM59 RFC destination

BD64 Maintain customer model

BD54 Define a Logical System

SCC4 Assign a client to the Logical system

Testing

WE19 Test tool for IDocs

WE12 Convert an outbound IDoc to an inbound IDoc

WE16 Process an incoming IDoc file

WE17 Process an incoming status file

Reprocessing IDocs

BD88 Process outbound IDocs (before 4.6A)

BD87 Manual processing of Idocs

Miscellaneous

XD02 Maintain customer master

Transaction Codes contd.

63

Miscellaneous contd.

XK02 Maintain vendor master

MM02 Maintain material master

VA01 Create sales order

ME21 Create purchase order

ME11 Create purchasing information records

BD10 Material Master Data Distribution

BD12 Customer Master Data Distribution

BD14 Vendor Master Data Distribution

Configuring New Components

WE81 Create new message type

WE82 Link IDoc type and message type

WE41 Create outbound process code

WE42 Create inbound process code

WE57 Allocate inbound function module to message type

BD51 Define settings for inbound function module

BD67 Assign input methods for a process code (inbound)

Transaction Codes contd.

64

The following programs are scheduled to run on a periodic basis for processing at

different layers of ALE and EDI processes.

1. RSNAST00: Processes buffered entries in the NAST table

2. RBDMIDOC: Generates IDocs by processing change pointers that have been

logged for changes made to master data objects

3. RSEOUT00: Processes outbound IDocs (status 30) that have been buffered to

support mass processing

4. RBDAPP01: Processes inbound IDocs (status 64) that have been buffered to

support mass processing

5. RBDMANIN: Reprocesses inbound IDocs that failed because of application

errors (status 51)

6. RBDMOIND: Updates the status of IDocs that have been successfully

dispatched to a receiving SAP system

7. RSEIDOCM: Can be scheduled to run as a monitoring program

Programs

65

The following are the programs used for archiving IDocs

RSEXARCA – program for archiving.

RSEXARCD – program for deleting archived IDocs from the database.

RSEXARCR – program to read the IDocs from archive file.

RSEXARCL – Program to Retrieve IDocs from the archive into the database.

SARA -- Transaction for Idoc Archiving

Idoc Archiving

SAP ALE Idoc Overview 2Hrs

Documents

Transcript of SAP ALE Idoc Overview 2Hrs