Page History
Div | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||
|
IDocs (Interface Documents) are the most common way of interchanging data asynchronously with SAP systems. In order to parse and compose IDocs, the modeler must first import the corresponding IDoc classes from SAP parse grammars. This process is described on Importing SAP IDoc Meta Data in the E2E Builder User Guide. The rules describing the mapping from SAP Metadata to UML classes can be found on IDoc Import Rules.
...
The following pages describe IDoc handling, such as
Children Display | ||
---|---|---|
|
Noteinfo | ||
---|---|---|
| ||
Since Builder 6.0.11.3, the SAP Adapter supports the SAP NetWeaver libraries. This resulted in some changes concerning the IDoc Handling (see also Adapting the Services from the SAP Migration Guide). The IDoc handling described on the following pages refers to the use of SAP NetWeaver. |
Example Overview: IDoc Use Cases
Use Case | Operation | ||||||||
---|---|---|---|---|---|---|---|---|---|
| |||||||||
Receive an IDoc file and send it to SAP (unchanged) | SendAnyIDocFromFile | ||||||||
Receive and IDoc from SAP and send it to SAP | SendAnyIDoc | ||||||||
| |||||||||
Receive and IDoc from SAP and write it to a file | IDOC_INBOUND_ASYNCHRONOUS | ||||||||
| |||||||||
Read an IDoc from file and parse it to an IDoc structure | SingleIDocInString | ||||||||
Receive an IDoc from SAP and parse it to an IDoc structure | SingleIDocSAPTables | ||||||||
Read multiple IDocs (same structure) from file and parse them to an IDoc structure | ArrayOfDocsInString | ||||||||
Receive multiple IDocs (same structure) from SAP and parse them to an IDoc structure | ArrayOfDocsInSAPTables | ||||||||
Read an TXTRAW01 IDoc from file, parse it, make some changes and write it to a new file. | parseTXTRAWIDoc |
Parsing and Composing IDocs in Bridge Versions Before 6.0.11.3
Expand | |||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||||||||
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. Parsing of one IDocThe 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:
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,
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. Figure: SAPIDocParser, single IDoc from Tables Parsing of Multiple IDocsThe 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 FileAn 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:
Parsing Version 3 IDocsAn 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:
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. 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:
An example of composing version 3 IDocs is the following activity diagram: Figure: IDoc3 Composer V3
|