XML Metafile Structure

If a package is built by hand, this metafile must be constructed and packaged into a .jar file with the content XML files.

The type tag in XML specifies the type of entity being imported.

A sample metadata file is shown here:

<message>Exported from FNO 8.3 installed on host blind</message>

</statusInfo>

</fileInfo>

<fileName order="1">lictech_1.xml</fileName>

</fileSet>

<fileName order="1">licmodel_1.xml</fileName>

</fileSet>

<fileName order="1">feature_1.xml</fileName>

</fileSet>

<fileName order="1">product_1.xml</fileName>

</fileSet>

<fileName order="1">entitlement_1.xml</fileName>

<fileName order="2">entitlement_2.xml</fileName>

<fileName order="3">entitlement_3.xml</fileName>

<fileName order="4">entitlement_4.xml</fileName>

<fileName order="5">entitlement_5.xml</fileName>

</fileSet>

</fileDetails>

</fileMetaInfo>

File Order

The order in which entities are loaded is important. Before an entity is loaded, all of its dependencies must exist in the system. There are two points to consider while determining the file order in the metafile:

•

Different entity types: For example, before an entitlement is loaded, the product and license model the entitlement refers to must exist in the system. So, the product XML files must be loaded before loading the entitlement XML files.

•

Same entity types: If there is a parent-child relationship between the same entity types, the parent must be loaded before the child is loaded. For example, if an entitlement line item is defined as an upgrade of another line item. The parent line item must be loaded before the upgraded line item is loaded.

Each content XML file must be of a reasonable size to ensure that the I/O processes proceed smoothly.

Content XML Files

In general, all constants in the content XML files are enumerated types which are defined in the corresponding .xsd file.

In general, if the user wants to update even one attribute, such as state, the entire XML file must be submitted along with all the collections and references.

For example, if the user wants to import a product, then the entire product definition along with the features, bundles, license models, parts, and associated parameters, has to be provided in the XML file. If the product already exists in the system, the user is given a choice to either update the record or report an error during the import process. If the user selects to update the record, then the entire product definition is replaced by the details in the XML imported. This means that the existing features, bundles, license models, parts in the product are replaced by the new collections mentioned in the imported XML.

Common specifications for each content XML include:

•

Date values must be entered in yyyy-mm-dd format.

•

Time Zone must be entered in a format like -7:00, which indicates GMT -7 hours.

•

Locales must be entered as en or en_US. A locale's language is specified by the ISO 639 standard and the locale's country code is specified by the ISO 3166 standard. If the locale entered does not conform to these standards, then a default value of en is stored.