Page History
...
Class | e2e-refDiv |
---|
Otp | ||||
---|---|---|---|---|
|
...
Children Display | ||
---|---|---|
|
...
...
...
icon | false |
---|
...
...
Parsing and Composing IDocs in Bridge Versions Before 6.0.11.3
...
title | Click here to read about IDoc handling in E2E Bridge versions before 6.0.11.3... |
---|
Version | ||
---|---|---|
| ||
|
Parsing IDocs means to map an IDoc data buffer to a UML class that has the same structure as the data embodied in the IDoc. To keep the example simple, most simple IDoc (TXTRAW01 ) is read from a file and mapped to the UML class TXTRAW01.
Figure: UML class model of the IDoc TXTRAW01
The details of generating the class TXTRAW01 and its parents and associations are explained in section IDoc Import Rules.
Instances of IDoc classes such as TXTRAW01 can be generated by the <<SAPIDocParser>> component. This parser takes as input two string arrays and assumes that the elements are valid control record and data record strings. These strings are parsed and put into a class that must correspond to the IDoc found in the EDI_DD40 and EDI_DC40 array.
The reason to have these arrays as input is that they correspond to the IDOC_INBOUND_ASYNCHRONOUS interface, used by SAP R/3 to send IDocs via RFC. See also section tRFC Service which describes an IDoc server as an example of a tRFC service.
Parsing of one IDoc
The following activity diagram shows an application of the <<SAPIDocParser>> component. In the first step, a file is read which must contain a valid IDoc. The structure of this file is explained in the SAP help. In a nutshell, the IDoc format consists of a control line (the first line) and data lines called segments, for example, the first line of a TXTRAW01 example file looks like:
Code Block |
---|
EDI_DC40 000000000000003623046D 3012 TXTRAW01
TXTRAW TXTRAWSAPMBS LS MBS_000
E2E_FILE LS FILE_LS
20041019151256 |
It starts with the so-called control record EDI_DC40 and contains meta data such as IDoc number, IDoc type , target system, source system and so on. This line is put as string into the EDI_DC40 array by the Read IDoc File subactivity. The subactivity takes the following line,
Code Block |
---|
E2TXTRW 000000000000003623000000100000002THIS IS A TEXT LINE |
the E2TXTRW data segment, and appends it to the EDI_DD40 array. Since TXTRAW has only one segment, the EDI_DD40 array contains just one string element.
The <<SAPIDocParser>> takes these two arrays and generates an instance of a <<SAPIDoc>> class.
Figure: SAPIDocParser, single IDoc from Tables
Parsing of Multiple IDocs
The example above can just handle one IDoc in the SAPTables, but SAP allows for more than one IDoc per array. This means the control record array (EDI_DC40) contains more than one entry. To handle this, the IDoc must be parsed into an array with an arrayElement of a <<SAPIDoc>> class.
Figure: SAPIDocParser, an array of IDoc from Tables
Parsing an IDoc from a File
An other common case is, that the IDoc is given as a file. For this case it is very convenient that the SAPIDocParser can handle an IDoc as a string too see the next example.
Figure: SAPIDocParser, an array of IDoc fromString
The above examples shows how to parse IDocs being of version 4.x. However, also SAP R/3 3.x systems use IDocs. These IDocs are handled similar to version 4.x IDocs. The differences between parsing version 4 and version 3 IDocs are as follows:
- IDoc3 Parser Stereotype: <<SAPIDoc3Parser>>
- IDoc3 Parser Input: EDI_DD and EDI_DC, both string arrays.
- IDoc3 Stereotype: <<SAPIDoc3>>, this is taken into account if the import was done in version 3 mode (see Builder User Guide).
Parsing Version 3 IDocs
An example of parsing version 3 IDocs is the following activity diagram:
Figure: SAPIDoc3Parser
Note | ||
---|---|---|
| ||
In contrast to the SAPIDocParser for version 4, the SAPIDoc3Parser does not support IDoc-string as input and IDoc-array as output. |
<<SAPIDoc3>> classes differ especially in the so-called control record EDI_DD.
Hide |
---|
Compare the following class diagram and figure UML class model of the IDoc TXTRAW01. |
(for more details refer to IDoc Import Rules):
Figure: UML class model of the IDoc TXTRAW01, version 3
IDocs (Interface Documents) are modeled as UML classes (cf. TXTRAW). Such classes can be serialized into SAP IDoc tables (arrays) by the <<SAPIDocComposer>>. This composer takes as input an IDoc class and generates two arrays:
- EDI_DD40: Each string element corresponds to a serialized segment
- EDI_DC40: Contains exactly one element - the control record
The reason to have these arrays as output is that they correspond to the IDOC_INBOUND_ASYNCHRONOUS interface, used by SAP R/3 to send and receive IDocs via RFC. See also section tRFC Service that describes an IDoc server as an example of a tRFC service.
Figure: IDoc Composer with single IDoc to Tables
The mapping rules describing the relation between IDoc metadata and UML classes are found in IDoc Import Rules.
SAP allows for more than one IDoc per array. This means the control record array (EDI_DC40) contains more than one entry. The SAPIDocComposer does support this too, for this purpose an array with an arrayElement of a <<SAPIDoc>> class. can given as input into the composer, see the example below:
Figure: IDoc Composer with a IDoc-array to Tables
An other common case is, that the IDoc must be written into a file. For this case it is very convenient that the SAPIDocComposer can output the IDoc into a string too; see the next example
Figure: IDoc Composer with a IDoc-array to string
The above examples shows how to compose IDocs being of version 4.x. However, also SAP R/3 3.x systems use IDocs. These IDocs are handled similar to version 4.x IDocs. The differences between composing version 4 and version 3 IDocs are as follows:
- IDoc3 Composer Stereotype: <<SAPIDoc3Composer>>
- IDoc3 Parser Input: EDI_DD and EDI_DC, both string arrays.
- IDoc3 Stereotype: <<SAPIDoc3>>, this is taken into account if the import was done in version 3 mode (see Builder User Guide).
An example of composing version 3 IDocs is the following activity diagram:
Figure: IDoc3 Composer V3
...
icon | false |
---|
...