Identification and Reconciliation Fundamentals - Support and Troubleshooting

Identification and Reconciliation Fundamentals Table of Contents Overview IRE Overview IRE Components Independent VS Dependent Duplicates Reclassification Partial Items IRE Flow IRE Tools Clean Up Properties Overview The goal of this knowledge base article is to cover the main concepts of the Identification and Reconciliation Engine (IRE) and get new users up to speed.

IRE Overview What is the Identification and Reconciliation Engine? The Identification and Reconciliation Engine is a framework which processes payloads in order to maintain the Configuration Management Database (CMDB). This would include creation of new configuration items (CIs) or updates to existing CIs.

But why do we need the IRE? Multiple sources updating the CMDB with their own logic without a centralized framework could lead to duplicate Cis, undesired updates, as well as attribute flapping (multiple sources continuously updating the same fields with different values).

A centralized framework is necessary to ensure that the CMDB is free of duplicates and has the most relevant information up to date.

Note: There is no logic to block updates to the CMDB directly and bypass the IRE. However, updating the CMDB directly foregoes the benefits of using the IRE. For this reason we suggest any updates to the CMDB be made via the IRE.

IRE Components Identifier An identifier is a set of rules for a class which the IRE uses to determine if a CI already exists in the CMDB. If a class does not have an identifier it will inherit it from the hierarchy. For example, most classes in one of the child branches from cmdb_ci_hardware inherit the "Hardware" identifier.

Identification Rules Identification rules are what the IRE uses to find Cis in the CMDB. Each identification rule is comprised of a set of attributes which are used to search the CMDB for a match.

The IRE analyzes the payload received and uses the identification rules, in order of priority, to find a CI in the CMDB. A new CI would be created if no CI is found.

Inclusion Rules The inclusion rules are used to narrow down the scope of what Cis are included in the identification process.

CIs which do not match the criteria set by the inclusion rules will not be used by the IRE.

Thus, first we use the identification rules to find the CIs in the CMDB and then we use the inclusion rules to check if those Cis can be used.

But why have inclusion rules in the first place?

As an example, suppose there is a environment requirement that retired windows servers in the CMDB should no longer be updated by data sources. We could use an inclusion rule to stop retired servers from being used/updated by the IRE. A drawback to inclusion rules is that they can lead to "duplicate" CIs if not configured properly.

Note: Configuring an inclusion rule to exclude CIs by class leads to duplicates.

For more information on identification rules, inclusion rules, and how to configure them, please see:

Identification rules Reconciliation Rules The IRE uses the reconciliation rules to determine what datasources should be prioritized. Data sources with highest priority determine what an attribute value should be. This prevents less reliable data sources from updating fields in a class. Without reconciliation rules, datasources would overwrite each other's updates.

This way we can prevent multiple data sources from updating the same CI attributes over and over.

For more information on reconciliation rules, as well as the different types of reconciliation rules (dynamic vs static), please see:

Reconciliation Rules Data Refresh Rules What would happen if there were no more updates from a high priority datasource that updated a CI last?

Over time that data may no longer be relevant. We need a way to allow other sources to update those records when this happens.

The data refresh rules specify if the data for a CI has become stale. When this happens, other allowed data sources of lower priorities will be able to update those Cis.

Note: Data refresh rules have no impact when dynamic reconciliation rules are in effect. Data refresh rules are used in conjunction with static reconciliation rules.

For more information on Data Refresh rules please see:

Data refresh rules Multisource CMDB Multisource CMDB retains a complete history about discovery sources and proposed values, involved in updates of CI attributes. Multisource CMDB data can be used to track how the CMDB is populated by various discovery sources at the CI attribute level. Also, to revert CI updates from a specific discovery source, or to recompute attribute values using updated reconciliation rules.

When multiple discovery sources attempt to update the same CI attribute, the Identification and Reconciliation Engine (IRE) uses reconciliation rules to select a single discovery source for the update. Without Multisource CMDB, details about the lower-priority discovery sources whose values were rejected, are discarded. Also, it is difficult to identify the source of an attribute value without Multisource CMDB.

With Multisource CMDB, the raw details for every discovery source and CI combination are retained for both, discovery sources that were selected for an update and all others that were not. Multisource CMDB data, consisting of records for each discovery source and CI combination, is stored in the CMDB MultiSource Data [cmdb_multisource_data] table. You can examine, query, and report on this Multisource CMDB data store.

For more information on Multisource CMDB, and how to set it up, please see:

Multisource CMDB Independent VS Dependent CI dependency is specified in the CI Class Manager by the dependent relationship rules for the CI's class:

Independent CIs CIs, such as Server CIs, which exist on their own and are not dependent on any other CIs.

Dependent CIs CIs which depend on a relationship to another CI and can't exist on their own in the absence of the dependent relationship.

For example: Network Adapter CIs can't exist meaningfully without the Hardware CIs that contain them.

Application CIs can't exist on their own without the Server CI they are hosted on.

In the following image we see the "Dependent Relationships" necessary for class Tomcat.

The steps for identifying dependent CIs can be different from the steps for identifying independent CIs. This difference is reflected in the differences between dependent identification rules and independent.

The IRE will return an error if a dependent CI payload is processed which does not have the necessary relationships. On the image above we see that Tomcat payloads must have a "Runs on" relationship to a hardware CI.

If working directly with the IRE framework, the identification simulation can be used as a tool to check if your payload is not missing any component. Please see:

How to build an Identification and Reconciliation Engine payload Identification rules: Independent identifier An identifier that identifies a CI based on the CI's own attributes, independently of other CIs or relationship.

Dependent identifier An identifier in which identifying a CI requires identifying an independent CI first. A CI can have dependency on one or more CIs, and a dependent CI can have only a single parent CI with dependency. The relationship types between the CI and its dependent CIs are also included in the identification process. To help with the identification process of dependent CIs, create dependent relationships that define the dependency chain within CI types.

The payload used for identification of a dependent CI, can include a relationship with a qualifier chain. For such relationship, if there is a matching parent/child pair, the system compares the qualifier chain in the payload, with the qualifier chain of the CIs in the database. If there is a difference, the qualifier chain in the database is updated to match the qualifier chain in the payload for that relationship.

In the following image we see the Identification Simulation being used to create a payload.

Note that the created payload has:

Independent CI, this is the cmdb_ci_win_server Dependent CI, this is the cmdb_ci_network_adapter Relationships, this is the required "Owns::Owned by" relationship for a network adapter

Duplicates When the IRE api is called it may find duplicates. If duplicates are found a de-duplication task will be created.

Please see the following on how to use de-duplication tasks to resolve duplicate CIs:

Review de-duplication tasks Remediate a de-duplication task Manually create a de-duplication task Detecting duplicate CIs For troubleshooting duplicate CIs please see:

Duplicate CMDB CI records Duplicates may also be found by the CMDB Health Correctness job. Please see the following document on details about this job:

CMDB Health - Duplicate Metric - algorithm Reclassification CIs can be upgraded, downgraded, and switched.

Upgrade example (goes up the hierarchy):

Server → Windows Server

Downgrade example (goes down the hierarchy)

Linux Server → Server

Note: Avoid the CI class downgrade and CI class switch operations as those can lead to data loss. When automatic CI reclassification is enabled (which is by default), the identification process can result in some automatic reclassifications which lead to data loss.

Switch example (goes to different branch of the hierarchy altogether)

Printer → Switch

Data for fields which do not exist on target class will be lost

For more information and properties which control this behavior please see:

CI reclassification during IRE processing Partial Items A payload item is determined to be a partial item if it contains the necessary data for unique identification and if it has one of the following errors. Unique identification requires that the payload item has the sys_object_source_info section with source_name and source_native_key values, or the full set of the identification criterion attributes specified for the CI class, or both.

IRE errors for a partial item: MISSING_MATCHING_ATTRIBUTES –— Item does not have identification criterion attributes to use at least one identifier entry for matching. REQUIRED_ATTRIBUTE_EMPTY –— Unable to create a CI because a required attribute is missing. MISSING_DEPENDENCY –— Dependent CI is missing a dependency relation which is specified in the payload. INSERT_NOT_ALLOWED_FOR_SOURCE –— An IRE data source rule prevents the specified data sources from creating CIs of the specified class. If processing fails because payload items are determined to be partial items, then the partial items are saved as partial payloads in the CMDB IRE Partial Payloads [cmdb_ire_partial_payloads] table in JSON format for later potential processing. IRE uses identifier keys to attempt to match incoming payloads with stored partial payloads.

If later, a data source sends the data that was missing in the partial item, IRE matches the incoming payload with the stored partial payloads. IRE then merges any matching partial payloads with the incoming payload. To resolve any conflicting attributes, IRE uses either source_recency_timestamp (when source_native_key and source_name are identical), or static reconciliation rules specified for the class. The result is a complete and valid payload which IRE then processes to create or update the respective CIs.

Partial payloads older than 90 days are deleted from the CMDB IRE Partial Payloads [cmdb_ire_partial_payloads] table.

IRE Flow How the CMDB Identification and Reconciliation Engine works when passing a CI IRE Tools CI Class Manager The CI Class Manager is your one stop shop for configuring the tools available for the IRE

To open the CI Class Manager navigate to

Configuration > CI Class Manager In the following image we see the CI Class Manager and the configuration for the identification rules as well as inclusion rules for class "Windows Server"

Identification Simulation To open the Identification Simulation navigate to:

Configuration > Identification/Reconciliation > Identification Simulation Please see following KB on how to use the Identification Simulation to create IRE payloads:

How to build an Identification and Reconciliation Engine payload Debug Identification and Reconciliation For more information on how to debug the identification and reconciliation engine please see

Debugging Identification and Reconcilliation Engine using scripts in scripts background List of IRE errors:

https://docs.servicenow.com/bundle/rome-servicenow-platform/page/product/configuration-management/concept/identification-simulation.html#id-engine-error-messages Clean Up How to identify and delete duplicate CMDB CI Relationship records, or ones that have orphan or missing parent/child relationships Properties For a comprehensive list of IRE properties please see:

Properties for Identification and Reconciliation