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:

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,

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

<<SAPIDoc3>> classes differ especially in the so-called control record EDI_DD.

(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