IDocs are basically a small number of records in ASCII format, building a logicalentity. It makes sense to see an IDoc as a plain and simple ASCII text file, even if itmight be transported via other means.
Any IDoc consists of two sections:
the control recordwhich is always the first line of the file and provides the administrative information.
the data record which contains the application dependent data, as in our example below the material master data.We will discuss the exchange of the material master IDoc MATMAS in theparagraphs that follow..The definition of the IDoc structure MATMAS01 is deposited in the data dictionary
and can be viewed with WE30.
The very first record of an IDoc package is always a control record. The structure of this control record is the DDic structure EDIDC and describes the contents of the data contained in the package.
The control record carries all the administrative information of the IDoc, such as its origin, its destination and a categorical description of the contents and context of the attached IDoc data. This is very much like the envelope or cover sheet thatwould accompany any paper document sent via postal mail.
For R/3 inbound processing, the control record is used by the standard IDocprocessing mechanism to determine the method for processing the IDoc. Thismethod is usually a function module but may be a business object as well. The processing method can be fully customised.Once the IDoc data is handed over to a processing function module, you will no longer need the control record information. The function modules are aware of theindividual structure of the IDoc type and the meaning of the data. In other words:
for every context and syntax of an IDoc, you would write an individual function module or business object (note: a business object is also a function module in R/3) to deal with.The control record has a fixed pre-defined structure, which is defined in the datadictionary as EDIDC and can be viewed with SE11 in the R/3 data dictionary. Theheader of our example will tell us, that the IDoc has been received from a senderwith the name PROCLNT100 and sent to the system with the name DEVCLNT100 .It further tells us that the IDoc is to be interpreted according to the IDoc definition called MATMAS01 .
All records in the IDocs, which come after the control record are the IDoc data. They are all structured alike, with a segment information part and a data part which is 1000 characters in length, filling the rest of the line.All records of an IDoc are structured the same way, regardless of their actual content. They are records with a fixed length segment info part to the left, which is followed by the segment data, which is always 1000 characters long.
You can view the definition of any IDoc data structure directly within R/3 with transaction WE30.Regardless of the used IDoc type, all IDocs are stored in the same database tablesEDID4 for release 4.x and EDID3 for release 2.x and 3.x. Both release formats areslightly different with respect to the lengths of some fields.
Depending on the R/3 release, the IDoc data records are formatted either according the DDic structure EDID3 or EDID3. The difference between the two structuresreflects mainly the changes in the R/3 repository, which allow longer names startingfrom release 4.x.All IDoc data record have a segment info part and 1000 characters for data IDoc type definition can be edited with WE30 Data and segment info are stored in EDID4 .
All IDoc data records are exchanged in a fixed format, regardless of the segment type. Thesegment’s true structure is stored in R/3’s repository as a DDic structure of the same name.the segment info tells the IDoc processor how the current segment data is structuredand should be interpreted. The information, which is usually the only interest, is the name of the segment EDID4-SEGNAM.The segment name corresponds to a data dictionary structure with the same name,which has been created automatically when defining the IDoc segment definition with transaction WE31 .
For most applications, the remaining information in the segment info can be ignoredas being redundant. Some older, non-SAP-compliant partners may require it. E.g.the IDoc segment info will also store the unique segment number for systems, whichrequire numeric segment identification.To have the segment made up for processing in an ABAP, it is usually wise to movethe segment data into a structure, which matches the segment definition.When R/3 processes an IDoc via the standard inbound or outbound mechanism, the IDoc is stored in the tables. The control record goes to table EDIDC and the data goes to table EDID4.
All IDoc, whether sent or received are stored in the table EDID4. The correspondingcontrol file header goes into EDIDC.There are standard programs that read and write the data to and from the IDoc base.These programs and transaction are heavily dependent on the customising, where rules are defined which tell how the IDocs are to be processed.
Of course, as IDocs are nothing more than structured ASCII data, you could alwaysprocess them directly with an ABAP. This is certainly the quick and dirty solution,bypassing all the internal checks and processing mechanisms. We will not reinventthe wheel here.To do this customising setting, check with transaction WEDI and see the points,dealing with ports, partner profiles, and all under IDoc development.All inbound and outbound Documents are stored in EDID4 Avoid reinventing the wheel Customising is done from the central menu WEDI and see the points,dealing with ports, partner profiles, and all under IDoc development.
RELATED POSTS
No comments :
Post a Comment