SALE - IMG ALE Configuration Transation code

·         SALE - IMG ALE Configuration root 
WE20 - Manually maintain partner profiles 
BD64 - Maintain customer distribution model 
BD71 - Distribute customer distribution model 
SM59 - Create RFC Destinations 
BDM5 - Consistency check (Transaction scenarios) 
BD82 - Generate Partner Profiles 
BD61 - Activate Change Pointers - Globally 
BD50 - Activate Change Pointer for Msg Type 
BD52 - Activate change pointer per change.doc object 
BD59 - Allocation object type -> IDOC type 
BD56 - Maintain IDOC Segment Filters 
BD53 - Reduction of Message Types 
BD21 - Select Change Pointer 
BD87 - Status Monitor for ALE Messages 
BDM5 - Consistency check (Transaction scenarios) 
BD62 - Define rules 
BD79 - Maintain rules 
BD55 - Defining settings for IDoc conversion 

·         WEDI - ALE IDoc Administration 
WE21 - Ports in Idoc processing 
WE60 - IDoc documentation 
SARA - IDoc archiving (Object type IDOC) 
WE47 - IDoc status maintenance 
WE07 - IDoc statistics 

·         BALE - ALE Distribution Administration 
WE05 - IDoc overview 
BD87 - Inbound IDoc reprocessing 
BD88 - Outbound IDoc reprocessing 
BDM2 - IDoc Trace 
BDM7 - IDoc Audit Analysis 
BD21 - Create IDocs from change pointers 
SM58 - Schedule RFC Failures 

·         Basic config for Distributed data: 
BD64: Maintain a Distributed Model 
BD82: Generate Partner Profile 
BD64: Distribute the distribution Model 

·         Programs:
RBDMIDOC – Creating IDoc Type from Change Pointers 
RSEOUT00 – Process all selected IDocs (EDI) 
RBDAPP01 - Inbound Processing of IDocs Ready for Transfer 
RSARFCEX - Execute Calls Not Yet Executed 
RBDMOIND - Status Conversion with Successful tRFC Execution 
RBDMANIN - Start error handling for non-posted IDocs 
RBDSTATE - Send Audit Confirmations 
For testing you can use WE19 

IDOCs Related Transaction Code

Idocs Related Transation code

                                                                                                                                                                                                                          

·         WE31 IDoc segments

·         WE30 : Idoc creation

·         WE19: To change the IDOC

·         WE02/WE05/WE09 : to search the IDOC

·         WE09 : To search the IDOC by segment

·         WE30 IDoc types

·         WE81 Message types

·         WE82 IDoc type / message

·         WE57 Message/Application objects

·         WE42 Assign a process code to the message type

·         WE34 IDoc styles

·         WE32 IDoc views

·         WE05 IDoc list

·         WE02 Display IDoc

·         BD51 Set Function attribute

·         BD64 Display distribute model

·         BD67Link the function module to the process code

·         BD54 Define logical system

·         SCC4 Assign logical system name to client

·         SM59 Define RFC destination

BD87 : Reprocess the IDOC 

SAP IDOCS

IDOCS -Intermideate documentes

IDOCS means -Intermideate documentes.

IDoc (for intermediate document) is a standard data structure for electronic data interchange (EDI) between application programs written for the popular SAP business system or between an SAP application and an external program.

SAP to SAP : ALE(Application link emblening)

SAP to NON SAP : EDI (Electronic data interchange)

Direction :

                 Inbound : 1 ,Status 50    above 

                 Outbound : 2 ,Status : 1 to 50 : outbound  

IDoc or Intermediate Document is a standard SAP document exchange format. IDocs allow different application systems to be linked via a message-based interface. The IDoc interface consists of the definition of a data structure (where the data structure is the IDoc) and a processing logic for this data structure. 

The main aims behind the use of IDocs:

The structured exchange of business documents so that they can be processed automatically.

The various degrees of structural complexity as displayed by different application systems can be reduced to a structure which is as simple as possible.

A typical scenario is the system data administration, where material master records have to be distributed from one central to several satellite systems. Nowadays, pure EDI scenarios are more and more executed on the basis of ALE technology, only that the system connection is 'just' bilateral.

 IDocs allow for extensive exception handling before the data is posted to the application.

 Electronic Data Interchange (EDI) was the first form of data transfer to use IDocs. In EDI application scenarios, the processes, by definition, involve two partners: The sender and the recipient of an EDI message. EDI is a bilateral, document-oriented form of data transfer

Application Link Enabling (ALE) enables integration of business processes that are developed across several SAP systems or non-SAP systems. Thus, ALE is oriented to connect different applications on different systems. System-wide ALE message flows are modelled in a so called 'distribution model'. 

In an SAP System the Application Link Enabling (ALE) is one of the core integration technologies. It involves the exchange of hierarchical data documents known as Intermediate Documents (IDOCs).

Idocs has three main Structure/Records.

1. Control recored
2.  Data record 
3. Status Record   

Control record is a kind of “envelope” record that contains information about the IDOC like

• Ÿ  IDOC type (“what data is in the IDOC”)
• Ÿ  Message type (“how is the IDOC being processed”)
• Ÿ  Sender information (“who is the sender of that IDOC”)
• Ÿ  Receiver information (“who is the receiver of that IDOC”)
• Ÿ  Latest status of EDI processing.
• Ÿ  EDI standard and version.
• Ÿ  The only two mandatory fields that must be filled are the
• Ÿ  Message type (MESTYP) and  IDOC type (IDOCTP)

Ÿ  

Ÿ       The sender information - along with additional information -  is automatically filled in by the ALE layer (in function module “MASTER_IDOC_DISTRIBUTE”)Ÿ  

     The receiver information is optional:

If a receiver is specified, a check is carried out against the Distribution Model if this receiver is valid. If it is, an IDOC is created; otherwise no IDOC will be created.If no receiver is specified, “MASTER_IDOC_DISTRIBUTE” will determine all valid receivers that are maintained in the distribution model for that message type and create an IDOC for each receiver !

Data Record

• Ÿ The IDOC data records contain the data of the message. The data records are passed in an internal table and they have to match the structure of the IDOC (sequence of segments, min/max, hierarchy etc.)Ÿ  
• EDIDD is a generic structure used for all IDOC segmentsŸ  
• SEGNAM field identifies the segment typeŸ  
• SDATA contains the actual data of the segment 

Status Record

• Status number
•  Message
• IDoc type
•  Direction
•  Data and time stamp
•  Detailed description of status by code and text
•  Location of exception in Intermediate Document
•  Detector of exception by program and user.

Ÿ  The statuses for outbound IDocs are between '01' and '49', while the statuses for inbound

IDocs begin from '50'.Ÿ  

When an IDoc is created, the IDoc Interface sets the status in the function module EDI_DOCUMENT_CLOSE_CREATE. All additional status records are written explicitly by the function module EDI_DOCUMENT_STATUS_SET. It is possible to have Custom Statuses also.

table EDIDS –Information we get from Status record: