sap ale idoc overview 2hrs
DESCRIPTION
uygyuTRANSCRIPT
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
IDoc Definition Components
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
IDoc Definition Components
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.
IDoc Definition Components
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.
Outbound Components contd.
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.
Outbound Components contd.
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.
Outbound Components contd.
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).
Outbound Process- Push Approach contd.
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).
Outbound Process- Push Approach contd.
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.
Inbound Process via Function Module contd.
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).
Inbound Process via Function Module contd.
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