| Agile Product Lifecycle Management Import/Export User Guide Release 9.3.6 E71157-01 |
|
 Previous |
| Agile Product Lifecycle Management Import/Export User Guide Release 9.3.6 E71157-01 |
|
Previous |
This Appendix includes the following
Overview
Change History
Object References
Values
Null
Attribute Names
Dates
MultiList Fields
User Defined Flex Fields
The Agile aXML schema provides the XML Schema Definition (XSD) for the aXML structure. This appendix lists and describes the key components of the aXML schema. You can access this file at http://www.oracle.com/technology/products/applications/xml/plm/2009/06/aXML.xsd.
When you export Agile objects to aXML files, the exported data is a zipped file that contains an agile.xml file with extraction data and any file attachments that are included in the extraction.
The following table summarizes the major schema changes that occurred in each release.
| Release # | Schema Location (URL) | Changes |
|---|---|---|
| 9.3 | http://www.oracle.com/technology/products/applications/xml/plm/2009/06/aXML.xsd |
New fields were added and current fields were corrected:
added the Corrected the error in Affected Item references to |
| 9.3.0.1 9.3.0.2 9.3.0.3 | http://www.oracle.com/technology/products/applications/xml/plm/2009/06/aXML.xsd |
New fields were added and current fields were corrected:
Corrected errors in Affected Item references to |
| 9.3.1
9.3.1.1 9.3.1.2 |
http://www.oracle.com/technology/products/applications/xml/plm/2010/09/aXML.xsd |
New fields were added:
A new "Instances" tab was added to parts class. |
| 9.3.2 | http://www.oracle.com/webfolder/technetwork/xml/plm/2011/09/aXML.xsd |
Corrected errors in Relationships table reference for QCR Objects:
Added |
Within an aXML package, related objects are cross-referenced by their IDs. To support this requirement, all objects have their own unique ID attributes identification purposes and to be referenced by referentId attributes in corresponding nodes.
For example, if you export a change and its affected items, the ChangeOrders node will have an embedded AffectedItems node with a referentId attribute that will correspond to the uniqueId attribute of a Parts node that is in the same aXML package.
Specifically, your aXML package would contain the following data:
<ChangeOrdersuniqueId="6000:6119455"> ... <AffectedItemsreferentId="10000:6119451:6119455"> ... </AffectedItems> </ChangeOrders> <Parts uniqueId ="10000:6119451:6119455">
... </Parts>
You can find similar references for example, between BOM Items and their corresponding parts.
If an attribute of an object does not have a value, then the resulting aXML extraction of that object will not contain a node for that corresponding attribute. For example, if you have a part with Page Two.Text01 enabled, and for some object P1, the Text01 field does not contain a value, then this information will not appear within the aXML extraction.
In this example, if Page Two.Text02 is also enabled, and for P1, it has the value "value", the aXML package would resemble the following:
<Parts uniqueId="10000:6119451:6119455"> <TitleBlock> <Number>P1</Number>......</TitleBlock> <PageTwo> <Text02>value</Text02> </PageTwo>
</Parts>
If P1 is subsequently edited, and Text01 gets a value set, then the aXML could look something like this:
The aXML schema uses a "fixed" schema. This means the attribute names of the object attributes are static. For example, If you change the name of the Parts Page Two Text01 attribute to "My Field", the extracted aXML data will still use "Text01" as the node name for that field. Using the example shown in the previous section, regardless of the name you assign to this field, the Text01 node will still be extracted as Text01.
In the aXML package, date fields are always represented in the GMT zone when Export is invoked. For example, even though a field such as the date a change was released appears in your local time zone through the User Interface, the aXML extraction process will always extract the data in the GMT time zone. The date format follows the w3c conventions, with the inclusion of the time zone indicator (see http://www.w3.org/TR/NOTE-datetime for specifics).
When a MultiList field is extracted to aXML, the different values for the field are extracted to separate Value nodes. For example, if a part's Page Two MultiList01 field was extracted, the result would resemble the following:
<PageTwo>
<Multilist01>
<Value>List Value 1</Value>
<Value>List Value 2</Value>
</Multilist01>
</PageTwo>
For user defined flex fields, extraction will produce FlexAttribute nodes, each of which will have a name and value subnode. The value node will have an attribute indicating the type.
The FlexAttribute nodes (for Page Two or Page Three) will all be contained within a FlexAttribute node where xxxx is the attribute ID for the Flex Field attribute.
<FlexAttributes>
<FlexAttribute Id=”xxxx”>
<name>name</name>
<value xsd:type=”xsd:string”>value</value>
</FlexAttribute>
</FlexAttributes>
The following examples show sample outputs for different flex field types.
<FlexAttribute Id="2623172"> <name>Date Field</name> <value xsd:type=”xsd:string”>2008-01-01T00:00:00Z</value> </FlexAttribute>
<FlexAttribute Id="2623173">
<name>List Field</name>
<value xsd:type=”xsd:string”>List Value 1</value>
</FlexAttribute>
<FlexAttribute Id="2623174">
<name>Money Field</name>
<value xsd:type=”MoneyType” Currency=”USD”>100.00</value>
</FlexAttribute>
<FlexAttribute Id=”2623175”>
<name>MultiList Field</name>
<value xsd:type=”MultiListType”>
<Value>List Value 1</Value>
<Value>List Value 2</Value>
</value>
</FlexAttribute>
<FlexAttribute Id=”2623176”> <name>MultiText Field</name> <value xsd:type=”xsd:string”>abcdefg</value> </FlexAttribute>
