Step by Step procedure for creation of IDOC
目录
Step by Step procedure for creation of IDOC
Skip to end of metadata
Created by Anonymous on Jun 04, 2008
Go to start of metadata
Introduction
The main objective of an implementation of the SAP R/3 ERP is to group all the functions of the company together, in a single system. But it is very unlikely that this philosophy is applied so strictly.
Indeed, for such various reasons as load-balancing, task segmentation or also risk distribution, it is common to meet with a software landscape with more than one implementation of SAP R/3. It is even more common that these implementations of SAP R/3 run together with other heterogeneous systems, like AS/400 mainframes (IBM iSeries).
To communicate with each other, SAP has designed for R/3 systems its own communication tool: IDocs. These Intermediate Documents are the basis of every interface between R/3 systems. It is even possible, using a middleware EDI system, to have a R/3 system communicate by IDocs on its side, with an open system by XML files on the other side.
1 Structure of an IDoc interface
1.1 Structure of an IDoc
1.1.1 Segment
A segment is a record, defined as such in the vocabulary of databases. Indeed, as a line of a database, a segment is a sequence of fields of different length. There is no hierarchical structure within a segment, every fields are at the same level.
1.1.2 Section
An IDoc is made of three sections: control, data and status. Each section is named following the name of the one or many segments that composed it. Thus, the control section contains a single control segment only, the data section contains one or many data segments, the status section contains one or many status segments.
It is important to notice that when exchanging IDocs between systems, whether they are SAP R/3 or not, only control and data sections are sent. Indeed, the status section remains system specific. Nevertheless, the status section is conceptually associated with the IDoc, so it is systematically represented as being a part of the IDoc.
1.1.2.1 Control section
The particularity of the control section is that it contains only one single segment. This section represents the header of the IDoc, it contains an identifier of the IDoc, along with data concerning the sender system and the receiver system.
1.1.2.2 Data section
The particularity of the data section is that it contains one or many segments which are organized in a hierarchical way. There is a concept of parent segment and of child segment, a concept in which the child segment could not exist if the superior parent segment does not exist in the hierarchy.
This section is the most important, because as it is implied in its name, it is this section which contains the application data to transmit.
1.1.2.3 Status section
The particularity of the status section is that it is specific to the system where the IDoc is displayed. Indeed, after its transfer into an other system, the IDoc is actually rebuilt by copy, segment by segment. The status segments only are not transfered: there are specific to each one of the systems.
This status section is composed of one or many status segments. These segments are organized in a sequential way, so that only the last segment has a real importance. In consequence, what is refered as being the IDoc's status is actually copied from the status mentioned in the last segment of the IDoc's status section.
1.2 Structure of a segment
1.2.1 Control segment
The most important fields of the control segment are the following
IDoc number: number of the IDoc in the local system
Direction: direction of the IDoc, from the point of view of the local system; 1 stands for outbound, 2 for inbound
Status: current status of the IDoc in the local system
Basic type: basic IDoc type
Extension: type of extension, if applicable
Message type: message type
Sender or Recipient information: details concerning the sender or the receiver
Port: port
Partner number: number of logical system
Partn.Type: partner type; most of the time LS which stands for Logical System
SAP Release: version number of the IDoc
Output Mode: output mode; 2 stands for immediate sending, 4 for collected sending
1.2.2 Data segment
The structure of a data segment depends on the segment type. Each segment type has a different number of fields, each field having a different length.
The only common characteristic between all the segment types is the format of the data. Indeed, every fields of every data segments have the character format, whatever the way the fields are represented in the IDoc display.
1.2.3 Status segment
The structure of a status segment is the following
Status: the status reported by the segment
Message: the text describing the status
The other fields of the status segment are used to create a message following a SAP standard structure.
1.3 Structure of an interface
An interface is made of the following elements
A view of the distribution model (optional)
No, one or many filters
A sending system
A receiving system
A message type
For outbound interfaces
A port to emit to
An output mode
A packet size
A basic IDoc type
For inbound interfaces
A process code
1.3.1 View of the distribution model
The creation of a view in the distribution model is optional. Indeed, it is strictly obligatory only in a case where the application of a filter is necessary.
After the creation of a view in the distribution model, it is possible to distribute this view to the partner system, as it is also possible to generate the partner profiles for this view.
1.3.2 Message type and basic IDoc type
A message type represents the group in which every basic IDoc types must belong. A message type is conceptually the nature of the data transmitted within an IDoc.
For example, the MATMAS message type is related to material master data, Material Master. To this MATMAS message type is associated several basic IDoc types: MATMAS01, MATMAS02, MATMAS03, MATMAS04 et MATMAS05. Each basic IDoc type is able to contain essential data on material master data. MATMAS01 is the first version, each subsequent version increments the sequence number (MATMAS02, etc.) and adds fields comparing with the previous version.
By convention, each basic IDoc type which follows the ascending numbering can not remove a field or change the applicative meaning of a field comparing with the previous version of the basic IDoc type. The standard message types and basic IDoc types in SAP R/3 respect this convention, and it is preferable to do so for all the new types to be created.
1.3.3 Partner profiles
Dealing with every interfaces which do not have any filter, only the partner profiles are effective. Indeed, the views of the distribution model are there only to simplify and conceptualize the partner profiles, without replacing them though.
The parameters in the partner profiles are displayed with a reference frame which is the local system. For exemple, the parameters LS / REMSYST / Outbound deal with the outbound interfaces with the REMSYST logical system.
These parameters are different whether they affect an outbound or an inbound interface.
For outbound interfaces
A port to emit to
An output mode
A packet size
A basic IDoc type
For inbound interfaces
A process code
2 Customizing of an outbound interface
This chapter approaches the creation of a new outbound interface entirely specific. It uses no one of the standard SAP R/3 structures.
2.1 Creation of a new message type
2.1.1 Creation of a new segment type
Launch the WE31 transaction (Development segments: Initial screen).
Fill the Segment type field with the value Z1VISTAPM then press F5 (Create).
Fill the Short Description field and add as much lines as wished fields in the segment. For each field, give it a name and a Data Element to refer to.
Save.
2.1.2 Creation of a new basic IDoc type
Launch WE30 transaction (Develop IDoc Types: Initial Screen).
Fill the Obj. name field with the value ZVISTAPM01 then press F5 (Create).
In the popup window which appears, choose Create new and fill the Description field.
Select the ZVISTAPM01 header line then choose the Create segment... button. In the popup window which appears, fill the fields like the following:
Segm.type: Z1VISTAPM
Mandatory seg.: checked
Minimum number: 1
Maximum number: 999999
Save.
2.1.3 Creation of a new message type
Launch the WE81 transaction (Display View "EDI: Logical Message Types": Overview).
Choose the Display -> Change button then the New Entries button.
In the Message type column, type the value ZVISTAPM then in the Short text column type a short description.
Save.
2.1.4 Association of the basic IDoc type to the message type
Launch the WE82 transaction (Display View "Output Types and Assignment to IDoc Types": Overview).
Choose the Display -> Change button then the New Entries button.
In the Message Type column, type the value ZVISTAPM. In the Basic Type column, type the value ZVISTAPM01. In the Release column, type the value 620.
2.2 Customizing of a new interface
2.2.1 Creation of a new distribution model view
Launch the BD64 transaction (Display Distribution Model).
Press the Switch between display and edit mode button, then the Create model view button.
In the popup window which appears, enter in the Short text field a short description and in the Technical name field the value YVISTAPM.
Place on the newly created entry then press the Add Message Type button.
In the popup window which appears, enter in the Sender field the name of the local logical system, in the Receiver field the name of the receiving logical system and in the Message type field the name of the message type of the interface.
Validate then save.
2.2.2 Distribute the distribution model view
This step is necessary only if the partner system is a SAP R/3 system. It allows to centralize the changes to make on the interface. Be careful! The partner profiles also have to be generated and managed in the partner system.
...
