Absent Member.. Absent Member..
Absent Member..

UCMDB Support Tip: Reconciliation Out of the Box Rules

The reconciliation is a process of identifying and matching entities from different data stores. It is designated to avoid duplicates CIs. The following are Out of the box reconciliation rules:


Host Reconciliation

  1. Any host in UCMDB is identified either by an IP address or a strong ID value (such as a MAC address or hardware ID). Hosts identified by an IP address are considered incomplete (the Host Is Complete attribute has a false value).
         Hosts identified by a strong ID are considered complete.
  2. An  incomplete host can be reconciled with a complete host by IP or with an incomplete host with the same id.
  3. A complete host can be reconciled with an incomplete host by IP or with a complete host with the same id.
  4. When an incomplete host exists in the cmdb and a complete host is reported the complete host will replace the incomplete host and all the topology (related CIs) that was connected to the incomplete host will be moved to the new complete host.
  5. When a complete host exists in the cmdb and an incomplete host is reported the properties of the incomplete host will be copied to the complete host that is already in the cmdb.
         Note: the properties will be updated according to conflict resolution policy.


Cluster Reconciliation

  1. A  Cluster Server is a complete host.
  2. If an incomplete host is identified by its IP with two complete hosts that one of them is a cluster it will be identified only with the cluster.
  3. If a Cluster Server and another complete host are connected to the same VIP (virtual IP), all software elements that have VIP in application_ip attribute and all its relationships to other CIs will move from the physical complete host to Cluster Server.


Software Element Reconciliation

  1. Software Element CITs are considered either of a strong type or a weak type:
    1. Strong type Software Element CITs. These CITs are specialized (they are derived  from Software Element) and include more attributes, different identification rules, a display label, and so on.
    2. Weak type Software Element CITs. These CITs are CI instances of the Software Element CI Type itself. They include basic configuration attributes only. Also, only one instance of each software component type can exist in the model. That is, you cannot model two different Oracle instances on a single host using a weak type software element.
  2. A  reconciliation mechanism handles the mapping of weak type software elements to their corresponding strong type, once they are discovered. This mechanism enables DDM to detect the existence of software by one method, and report additional  details about the software when it is discovered using another method, knowing the two CIs will eventually be merged in the UCMDB.
  3. The reconciliation mechanism relies on a shared attribute value between the weak type and strong type: the Name attribute (data_name). All software elements (strong or weak) are created with a distinguishing name: when a strong  software element is discovered on a host containing a weak software element with the same name, the weak software element is merged with the strong  one.
"HP Support
If you find this or any post resolves your issue, please be sure to mark it as an accepted solution."

Click the KUDOS star on the left to say 'Thanks'
Labels (1)
Tags (1)
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.