Mapping File Reference

A mapping must be created for each target attribute in the transformed XML output. The mappings specify where and how to obtain the data. If the data is in another corresponding attribute in UCMDB, then a direct mapping is used.

To pull data from multiple attributes, or attributes from the UCMDB CI’s child or parent CI’s attributes, other complex mappings may be necessary. The mapping schema below shows all possible mappings.

The mapping file is an XML file which defines which CI/Relationship types in UCMDB are mapped to which CI/Relationship types in the target data store. The format is explained in detail below. The mapping file controls which CI and relationship types are pushed, as well as controlling exactly which attributes are pushed.

A mapping entry exists for each attribute to be pushed to the target MDR. Each mapping entry may consist of one or more attributes in the raw UCMDB push data. Mapping entries allow completely granular control of the final structure and naming of the data to be pushed to the target MDR.

Mappings transform one data model to another (in this case, the UCMDB to the push target MDR). Transformations may be simple, in the case of a 1:1 relationship between the UCMDB attribute and the target, they differ only by name and perhaps type.

Most attribute mappings are direct. For example, the server name “ServerX”, may be represented in UCMDB as a CI of type unix with an attribute name of primary_server_name, of type string with a length of 50. The target MDR’s data model may specify the same logical entity with a CI type of linux, with an attribute name of hostname with a type of char[] with a maximum length of 250. Direct mappings can accomplish all these aforementioned types of translation tasks.

Here is an example of a direct mapping:

 <target_attribute name="dns_domain" datatype="char">

<map type="direct" source_attribute="domain_name" />

</target_attribute>

This direct mapping maps the UCMDB attribute dns_domain to the domain_name attribute in the target data model.

Use the char data type regardless of the actual data type, unless it is necessary to use the actual data type.

More complex mappings enable additional transformations:

• To map attribute values from multiple CIs to one target CI.
• To map attributes of children CIs (those having a container_f or contained relationship) to the parent CI in the target data store. For example, setting a value called Number of CPUs on a target Host CI. Another example could be setting the value Total Memory (by adding up the memory size values of all memory CIs of a host CI in UCMDB) on a target Host CI.
• To map attributes of parent CIs (those having a container_f or contained relationship) on the target data store’s CI. For example, setting a value called Container Server on a target attribute called Installed Software CI, by getting the value from the containing host of the software CI in UCMDB.

Below is an example of a complex mapping, using two source attributes separated by a comma character, to create the target attribute os”:

<target_attribute name="os" datatype="char">

<map type="compoundstring">

<source_attribute name="discovered_os_name" />

<constant value="," />

<source_attribute name="host_osinstalltype" />

</map>

</target_attribute>

It is possible that the UCMDB contains data that differs in structure from source to source. For example, the relationship between an IpAddress CI and an Interface CI may be a parent, as may occur with the HPE Network Node Manager integration. Or it may be a containment link as is commonly created by Universal Discovery. Furthermore, the direction of these links are opposite to each other.

It is currently not possible to reverse the direction of links in the mappings file. Reversal of the _end1 and _end2 variables either switches the order of the data in the transformed XML or the link is missing in the source data.

One possible solution to this problem is to define an Enrichment rule as follows:

1. The enrichment’s TQL part is a subset of a TQL that is used by the push adapter. This TQL in particular selects all the links that are in the opposite direction of what is desired in the transformed xml.
2. The enrichment part defines a new link of the correct direction and desired type.
3. Enrichment is activated and then creates the correct links.
4. The integration job TQL now refers to the enriched link rather than the original link.
5. The <link> mappings in the push adapter then refer to the enriched link as well and produce a set of links consistent in type and direction.