Idocs tcodes and others , sap idoc


Published on


Published in: Education, Technology, Business
1 Comment
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Idocs tcodes and others , sap idoc

  1. 1. IDOCS Tcodes : jayprakash Barik (JP), @: Intermideate documentes SAP to SAP : ALE(Application link emblening) SAP to NON SAP : EDI (Electronic data interchange) Direction :Inbound : 1 : Outbound : 2 Status : 1 to 50 : outbound and 50 above : inbound Sucess : 53 sucess for inbound idcoc : 12 Sucess for outbound idoc • 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. There are three 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. Example: The structure of an SAP application document and the structure of the corresponding EDI message under the UN/EDIFACT standard. • 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'. 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.
  2. 2. • 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 detals There are 3 record ,will be found out from anyIDOC 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) Note that you have to use uppercase literals when you fill the two fields 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- table EDIDS –Information we get from Status record:      Status number Message IDoc type Direction Data and time stamp
  3. 3.    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.    TCODES 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 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
  4. 4. 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 Steps to create a new IDOC
  5. 5.  1: The first step in creating a new IDOC is to create all the segments that go into that IDOC. There are some rules that have to be followed while creating the segments:   The name of that segment type must start with „Z1‟ For each field in the segment you have to define a field name, a data element for the segment structure and a data element for the segment documentation. The data element for the segment structure has to be of data type „CHAR‟ The IDOC tools create overall three structures: Z1nnnnn - field names Z2nnnnn - data elements for structure definition Z3nnnnn - data elements for documentation IDoc type IDoc structure type Receiver port/partner type/partner number Sender port/sender type/sender number          2: Second step
  6. 6. WE30 The next step is to create the IDOC type by “assembling” all the necessary segments. Part of our scenario analysis was to define the layout of the IDOC. We should have addressed the following questions: Which segments should be used ? What is the hierarchy of the segments ? Which segments are mandatory and which are optional ? How often may a segment be repeated ? SAP recommends to create the structures as flat as possible. Usually each level of segment hierarchy results in a looping structure in the corresponding program. Therefore it’s easier to deal with flat structures. Conceptually the IDOC type describes the technical structure of the message
  7. 7. 3: Third step         Here is how to create a new IDOC type by assembling previously defined segments: Go to the maintenance of IDOC types In the ALE-IMG: Extensions->IDOC types -> Maintain IDOC type Select creation of new basic IDOC type Put segments into the IDOC Segment -> Create Enter segment name Enter attributes (Mandatory/Minimum/Maximum number)
  8. 8. 4: Fourth step WE81
  9. 9. WE82 Once the IDOC type is defined a message type has to be created. A message type determines how the data in the IDOC is being processed. This allows to use the same IDOC in different scenarios but process the data differently through different message types. A Message Type is the equivalent of a business document type. It characterizes the data being sent across systems, e.g. MATMAS is a message type for Material Master. Here is how to define a new message type : Go to the maintenance of IDOC types In the ALE-IMG: Extensions->IDOC types -> Maintain IDOC type Go to message type maintenance:
  10. 10. Environment -> Message types Table view -> Display -> Change New entries Customer message types should be in the customer name range (starting with Z) Last step of the IDOC creation process is to link the new IDOC type with the new message type. Later in the process the message type will be linked to the outbound and inbound programs. With these configurations it is determined how the IDOC is being processed. The relationship between IDOC type and message type is a 1-to-many relationship. That means an IDOC can be associated with multiple message types thus allowing the IDOC to be processed differently, but a message type refers to exactly one IDOC type. Here is how to link the message type with the IDOC type : Go to the maintenance of IDOC types In the ALE-IMG: Extensions->IDOC types -> Maintain message type for Intermediate structure Choose function “EDI: Message types and assignment to IDOC types” Link your message type with your IDOC type Table view -> Display -> Change New entries Message type : Z…… Basic IDOC type: Z….. 5: fifth step Assignment of Messgae type to the Idoc type IDOC STATUS Note: Harmless events are generated only if the specific IDOC was in an error state in the previous polling cycle. Otherwise, no events are generated.
  11. 11. The following table describes outbound IDOC status codes that generate Tivoli Enterprise Console events: Outbound IDOCs Code Error Event Severity SAP Meaning 02 Yes Error Error passing data to port 03 No Error if transaction SM58 Data pass to port OK indicates an RFC transmission error 04 Yes Error Control information of EDI subsystem 05 Yes Error Translation 06 No Harmless Translation 07 Yes Error Syntax check 08 No Harmless Syntax check 09 Yes Error Interchange handling 10 No Harmless Interchange handling 11 Yes Error Dispatch 12, 13, 14 No Harmless OK 15 Yes Warning Interchange acknowledgement negative 16 No Harmless Functional acknowledgement 17 Yes Warning Functional acknowledgement negative 18 No Harmless Triggering EDI subsystem 20 Yes Error Triggering EDI subsystem 22 No Harmless Dispatch OK, acknowledgement still due 23 Yes Error Retransmission 24 No Harmless Control information of EDI subsystem 25 Yes Warning Processing despite syntax error 26 Yes Error Syntax check 27 Yes Error ALE error 29 Yes Error Error in ALE services 30 No Harmless Ready for dispatch (ALE) 31 No Harmless IDOC is marked for deletion 33 No Harmless Original of an IDOC which was edited 34 Yes Error Error in control record of IDOC 36 Yes Error Timeout error; electronic signature not performed 37 Yes Error IDOC added incorrectly 38 No Harmless IDOC archived 39 No Harmless Receive confirmed 40 Yes Error Application document not created in target system 41 No Harmless Application document created in target
  12. 12. document The following table describes the inbound IDOC status codes that generate Tivoli Enterprise Console events: Inbound IDOCs Code Error Event Severity SAP Meaning 51, 52 Yes Error Posting error 53 No Harmless Posting successful 54 Yes Error Error during formal application check 55 No Harmless Formal application check 56 Yes Error IDOC with error added 60 Yes Error Syntax error 61 Yes Warning Processing despite syntax error 62 No Harmless IDOC passed to application 63 Yes Error Error passing IDOC to application 64 No Harmless IDOC ready to be passed to application 65 Yes Error ALE error 68 No Harmless IDOC is marked for deletion 70 No Harmless Original of an IDOC which was edited 73 No Harmless IDOC archived