The reconciliation_rules.txt File (for backwards compatibility)

This file is used to configure the reconciliation rules if you want to perform reconciliation when the DBMappingEngine is configured in the adapter. If you do not use the DBMappingEngine, the generic UCMDB reconciliation mechanism is used and there is no need to configure this file.

Each row in the file represents a rule. For example:

multinode[node] expression[^node.name OR ip_address.name] end1_type[node] 
end2_type[ip_address] link_type[containment]

The multinode is filled with the multinode name (the CMDB CIT that is connected to the federated database CIT in the TQL query).

This expression includes the logic that decides whether two multinodes are equal (one multinode in the CMDB and the other in the database source).

The expression is composed of ORs or ANDs.

The convention regarding attribute names in the expression part is [className].[attributeName]. For example, attributeName in the ip_address class is written ip_address.name.

For an ordered match (if the first OR sub-expression returns an answer that the multinodes are not equal, the second OR sub-expression is not compared), use ordered expression instead of expression.

To ignore case during a comparison, use the control (^) sign.

The parameters end1_type, end2_type and link_type are used only if the reconciliation TQL query contains two nodes and not just a multinode. In this case, the reconciliation TQL query is end1_type > (link_type) > end2_type.

There is no need to add the relevant layout as it is taken from the expression.

Types of Reconciliation Rules

Reconciliation rules take the form of OR and AND conditions. You can define these rules on several different nodes (for example, node is identified by name from nodeAND/ORname from ip_address).

The following options find a match:

  • Ordered match. The reconciliation expression is read from left to right. Two OR sub-expressions are considered equal if they have values and they are equal. Two OR sub-expressions are considered not equal if both have values and they are not equal. For any other case there is no decision, and the next OR sub-expression is tested for equality.

    name from node OR from ip_address. If both the CMDB and the data source include name and they are equal, the nodes are considered as equal. If both have name but they are not equal, the nodes are considered not equal without testing the name of ip_address. If either the CMDB or the data source is missing name of node, the name of ip_address is checked.

  • Regular match. If there is equality in one of the OR sub-expressions, the CMDB and the data source are considered equal.

    name from node OR from ip_address. If there is no match on name of node, name of ip_address is checked for equality.

For complex reconciliations, where the reconciliation entity is modeled in the class model as several CITs with relationships (such as node), the mapping of a superset node includes all relevant attributes from all modeled CITs.

Note As a result, there is a limitation that all reconciliation attributes in the data source should reside in tables that share the same primary key.

Another limitation states that the reconciliation TQL query should have no more than two nodes. For example, the node > ticket TQL query has a node in the CMDB and a ticket in the data source.

To reconcile the results, name must be retrieved from the node and/or ip_address.

If the name in the CMDB is in the format of *.m.com, a converter can be used from CMDB to the federated database, and vice versa, to convert these values.

The node_id column in the database ticket table is used to connect between the entities (the defined association can also be made in a node table):

Note The three tables must be part of the federated RDBMS source and not the CMDB database.

Parent topic: Adapter Configuration Files