|
This appendix contains the XSD describing the format of the mapping files. <?xml version="1.0" encoding="utf-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<!-- The direction of a relationship between the main
and a sub CI -->
<xs:simpleType name="relationshipDirection">
<xs:restriction base="xs:string">
<xs:enumeration value="main-to-sub"/>
<xs:enumeration value="sub-to-main"/>
</xs:restriction>
</xs:simpleType>
<!-- A field in the CMDB, ie. a CI attribute. -->
<xs:complexType name="Field">
<!--
Set a field's "const" attribute to specify a set value to write
to a field in the CMDB. A Field can have either "const" or
"src" set, not both.
-->
<xs:attribute name="const" type="xs:string"/>
<!--
The field in the query's result set to take this field's value
from. You can use aliases for long fields.
For example, use "name" as the src attribute in the following
query:
query host show name
Or use the alias name "ip_address" as the src attribute in
the following:
query host
show
#HostWithAddress:HostAddress:AddressOfHost:
IpAddress.address as ip_address
(The traversal is on two lines for readability, in reality
it is on a single line.)
-->
<xs:attribute name="src" type="xs:string"/>
<!--
The CMDB class' attribute to write the value to.
-->
<xs:attribute name="dest" type="xs:string" use="required"/>
<!--
If this field is required in the CMDB, set this value to "true".
If you set this to "true" and a null value is returned from the
foundation data store, the sub-CI will be ignored, that is,
the exporter will not attempt to insert it into the CMDB.
Failure to do this could cause the CMDB to throw an exception
when
committing the transaction for the main CI. You would lose
the main CI and all of its sub-CIs instead of just the sub-CI
with the null field.
-->
<xs:attribute name="required" type="xs:boolean" default="false"/>
<!--
Does this field form part of the CI's identity? "false" by
default. If any field is set to true then the transform engine
will do a lookup in this CMDB class to see if an object with the
same values for the identity fields exists, and use that if
one is found. If none is found, this item will be inserted.
If no fields are marked as identity fields, all items will be
inserted as new, even if they're identical.
-->
<xs:attribute name="identity" type="xs:boolean" default="false"/>
</xs:complexType>
<!-- A relationship between the main CI and a sub-CI. -->
<xs:complexType name="Relationship">
<xs:sequence>
<!--
A relationship can have fields in the same way as a CI can.
-->
<xs:element name="field" type="Field" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<!--
The cmdb class name for this CI.
-->
<xs:attribute name="cmdb-name" type="xs:string" use="required"/>
<!--
The direction the relationship goes in. For example, if this is
the dependency relationship from an application to a host, then
the application is dependent on the host. The direction is thus
"main-to-sub" if the main CI is the application.
-->
<xs:attribute name="direction" type="relationshipDirection"
use="required"/>
</xs:complexType>
<!-- A mapping for one CI class -->
<xs:complexType name="CI">
<xs:sequence>
<!--
The fields for this CI
-->
<xs:element name="field" type="Field" minOccurs="1"
maxOccurs="unbounded"/>
<!--
How this CI relates to the main CI
-->
<xs:element name="relationship" type="Relationship"
minOccurs="0" maxOccurs="1"/>
</xs:sequence>
<!--
CI class name in the CMDB
-->
<xs:attribute name="cmdb-name" type="xs:string" use="required"/>
<!--
Is this the "main" CI? There is one main CI and (optionally)
many sub-CIs.
-->
<xs:attribute name="main" type="xs:boolean" default="false"/>
<!--
If true (the default), any existing item found in the CMDB based
on the identity fields will have its non-identity fields
overwritten by the fields from the imported item. If false, the
existing object will be left untouched.
This value should possibly be set per-attribute.
-->
<xs:attribute name="overwrite-non-id-fields" type="xs:boolean"
default="true"/>
<!--
If true, then all of the fields that make up this CI have to be
collection fields, and all the collections have to have the same
length. The transform engine will generate one sub-CI per set of
values in the collections.
If this is false and any of the fields for this CI are returned
as a collection, an error will occur.
This is only applicable to sub-CIs. Defaults to "false".
-->
<xs:attribute name="collection" type="xs:boolean"
default="false"/>
<!--
Some items exist only in the context of their main CIs. A good
example is an IP address - the same IP address may exist many
times on the network, but will only exist once per Host. Thus,
the IP address is identified by its address and its relationship
to its main CI, namely the Host.
Set this attribute to true to tell the lookup to treat the
relationship to the main CI as part of the identity.
-->
<xs:attribute name="parent-is-identifier" type="xs:boolean"
default="false"/>
<!--
Specify which field contains a reference to the Foundation node
that this CI is an export of. The exporter uses this reference
to store and retrieve the ID given to this CI in the remote
system. This ID is then used to reconcile the CI against the
remote system before resorting to lookups based on identity
fields.
In Foundation QL, you specify a node reference by "#". For
example, you retrieve some fields and the node reference from
a Host by:
"search Host show name, fqdn, # as host_ref"
In this example, you would set the "node-reference-field" to
"host_ref".
-->
<xs:attribute name="node-reference-field" type="xs:string"/>
</xs:complexType>
<!-- The main document element. -->
<xs:element name="mapping">
<xs:complexType>
<xs:sequence>
<!-- The query to run against the data store -->
<xs:element name="query" type="xs:string" minOccurs="1"
maxOccurs="1"/>
<!-- The CIs in this mapping-->
<xs:element name="ci" type="CI" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="description" type="xs:string"
default="No description."/>
</xs:complexType>
</xs:element>
</xs:schema>
|
Labels:
None
