Go to primary content
Oracle Agile Engineering Data Management Enterprise Integration Platform Administration Guide
Release e6.2.0.0
E52568-02
  Go To Table Of Contents
Contents

Previous
Previous
 
Next
Next
 

11 Format of the XML Data Object (XDO)

11.1 Introduction

The XML Data Object (XDO) is an XML-based message, which is used inside the Enterprise Integration Platform. Every application connector has to convert the data, which is read from the application into the XDO format before it is sent to the controller. Vice versa, the connectors receive data in XDO format from the controller only. The XDO format is standardized for the Enterprise Integration Platform and connectors must ensure that they comply with this standard.

This document will describe the structure of the XDO, which is used inside the Enterprise Integration Platform.

11.2 Sample XDO

Below is a sample XDO, which will be further described in the following chapters.

<?xml version="1.0" encoding="ISO-8859-1"?>
<bod version="2.2.0">
     <controlarea>
           <guid>e3a9401d-858b-48da-a3cb-8d44b65628d0</guid>
           <initial>plm</initial>
           <source>plm</source>
           <target>bpm</target>
           <creation-date>2004-08-20</creation-date>
           <creation-time>12:23:20</creation-time>
           <owner>edbcusto</owner>
           <language>en-us</language>
           <version>1</version>
           <type>request</type>
           <synchronous>false</synchronous>
           <correlationid/>
           <error status="" code="" message=""/>
     </controlarea>
     <dataarea>
           <record type="DRAWING" verb="CREATE">
                 <key>15-1</key>
                 <params MTART="HALB" PLANT="1000"/>
                 <data>
                       <T_DOC_DAT.DOCUMENT_ID>eai-test-drawing</T_DOC_DAT.DOCUMENT_ID>
                       <T_DOC_DAT.SHEET_NO>0</T_DOC_DAT.SHEET_NO>
                       <T_DOC_DAT.DOC_VERSION>0</T_DOC_DAT.DOC_VERSION>
                       <T_DOC_DAT.DOC_REVISION>0</T_DOC_DAT.DOC_REVISION>
                 </data>
                 <return>
                       <status>S</status>
                       <code>000</code>
                       <message>Document record successfully created.</message>
                 </return>
                 <result>
                       <DOCUMENT>eai-test-drawing/DRW/000/00</DOCUMENT>
                 </result>
           </record>     
</dataarea>
</bod>

11.3 Business Object Document (bod)

The Business Object Document is the outer frame of the whole XDO message. It contains the control area with the metadata of the XDO and the data area, which contains the data itself.

11.4 Control Area (controlarea)

The control area contains information about the XDO like a unique ID (GUID), source and target connector, date, owner and type of XDO (request or response). This information is mainly used by the controller and connectors of the Enterprise Integration Platform. The details of the elements are described below:

The GUID is a global unique identifier of this XDO message:

<guid>e3a9401d-858b-48da-a3cb-8d44b65628d0</guid>
<initial>plm</initial>

The initial connector shows where the XDO is coming from originally:

The source connector shows where the XDO is coming from in that specific transfer step:

<source>plm</source>
<target>bpm</target>

The target connector defines where the XDO should go. The targets can either be defined by the source connector directly, or can be "calculated" during the mapping process:

This element shows the creation date of the XDO. This information can be used later on to check the "age" of an XDO:

<creation-date>2004-08-20</creation-date>
<creation-time>12:23:20</creation-time>

This element shows the creation time of the XDO:

The owner describes who owned the XDO data in the source application:

<owner>edbcusto</owner>
<language>en-us</language>

The language describes the language used while querying from the source application.

This is the version of the BOD for the specific transfer step. The controller and connector can use this information in order to check, whether the structure has changed in the XDO:

<version>1</version>
<type>request</type>

The XDO type shows whether this is a REQUEST XDO (source connector sends to target connector) or a RESPONSE XDO (target connector returns result to source connector). The value of this element is automatically set by the controller and can be read by a connector in order to find out, whether this is a new request or a response to a previously initiated request:

The synchronous flag shows this XDO is transferred in synchronous or asynchronous mode.

<synchronous>false</synchronous>
<correlationid>1::5b98d360-f522-4a35-a0dd-9384b1abcd91::5</correlationid>

The correlation ID shows the corresponding business process activity (only used when a BPM connector is involved).

The error element shows the details of technical exceptions, e.g. if the transformation problem or target system is not available.

<error status="" code="" message=""/>

11.5 Data Area (dataarea)

The data area contains the data records, which should be transferred between the applications. Multiple data records can be sent in one XDO. The records are processed by the connectors in the sequence as they appear in the data area. It is up to the source connector to ensure the proper sequence of the records in the data area.

The record element contains the data of each record coming from the source application. The record element contains the sub-elements key, params, data, return and result. The attribute type describes the business object (e.g. Item, Drawing, BOM), which is transferred, and the attribute verb describes the operation (e.g. CREATE, UPDATE, QUERY, DELETE), which should be executed in the target system:

<record type="DRAWING" verb="CREATE">
<key>15-1</key>

The key element should contain a unique reference to the record in the source application. This can be the key value of an entry in the transfer queue in the source application. Only the source connector has the knowledge, how this key is generated. Target connector should never change that key information, when they send the response XDO back to the source connector. This might be necessary for the source connector to find out, whether the transfer of a certain record (based on the key) was successful and what initial transfer entry this record does refer to.

The params element contains additional parameter information, which might be required for proper mapping without putting it into the data element (described in the section below). It is up to the source connector, how the params element is used:

<params MTART="HALB" PLANT="1000"/>
<data>     …</data>

The data element is the container for the data, which should be transferred from source to target application. It is the responsibility of the source connector to provide the correct amount and structure of the data. Furthermore, it is the responsibility of the mapping definition (see manual about the mapping definition -> pipe section) to map the data to the correct format as expected by the target connector:

The return element contains the element status, the code element and the message element. These elements only exist in an XDO, when the target connector sends the return code, return status and return message back to the source connector:

<return>
     <status>S</status>
     <code>000</code>
     <message>Document record successfully created.</message>
</return>

The result element contains all result data, which a target connector can provide as result based on the type of request (e.g. QUERY or UPDATE). The structure of the sub-elements of the result element is not predefined. It is the responsibility of the mapping definition to map the result of the target connector to the respective format understood by the source connector. It is up to the source connector to process (e.g. display) the result information:

<result>
     <DOCUMENT>eai-test-drawing/DRW/000/00</DOCUMENT>
</result>