General guidelines for using CMDB Identification

Release version: Xanadu

Updated August 1, 2024

3 minutes to read

Summarize

Summarized using AI

Summary of General guidelines for using CMDB Identification

This guide provides best practices for effectively using CMDB Identification rules in ServiceNow to accurately identify Configuration Items (CIs). Proper identification rules help ensure data integrity, optimize performance, and reduce errors during CI identification and updates.

Show full answer Show less

Identification Rules

Independent Identification Rules: Prefer creating independent rules that identify CIs solely based on their own attributes, avoiding dependencies on other CIs. This approach is faster, more reliable, and preferred for effective CI modeling.
Dependent Identification Rules: Use dependent rules only when necessary, limiting to a maximum of two dependency levels. Dependent rules rely on related CIs and relationships, requiring more processing time and increasing the risk of errors.
Avoid Lookup Identifier Entries: These reduce system performance and should be avoided if possible. Instead, update class definitions to support independent identification rules.
Limit Identifier Entries: Keep the number of identifier entries within each identification rule ideally to one to maintain optimal performance.
Prioritize Strong Identifiers: Assign the highest priority to the strongest identifier entries to improve accuracy and efficiency.
Rule Scope: Ensure identification rules are applied at the correct class level for the CIs they target.

Payload Best Practices

Limit Payload Size: Restrict the number of CIs included in a single payload to 500 to avoid performance degradation.
Avoid Duplicate Entries: Do not include duplicate CIs within the same payload, as this causes failures.
Exclude System Fields: Do not send system-managed fields (e.g., sysdomain, sysupdatedon) in the payload to prevent conflicts.
Minimal Criterion Attributes: Include only the necessary criterion attributes specified by the associated identification rules.
Use sysId for Matching: When available, provide the CI’s sysid to allow direct CI lookup and faster matching, reducing reliance on attribute-based identification.
Serialize API Calls for Dependent CIs: When inserting multiple dependent CIs related to the same parent CI, serialize API calls to prevent system congestion and performance issues.

Practical Implications for ServiceNow Customers

By following these guidelines, customers can design efficient and robust identification rules that improve CI accuracy and system performance. Prioritizing independent identification rules and limiting payload complexity help streamline CMDB data ingestion and maintenance processes. Using the sysid for updates and inserts minimizes identification errors and speeds up CI processing. Additionally, managing payload size and serialization of dependent CI inserts protects system stability during bulk operations.

Review the following general guidelines for using CMDB Identification effectively.

Identification rules

An independent identification rule identifies a CI based on the CI's attributes, independently of other CIs.

A dependent identification rule identifies a CI by its dependent CIs and the relationships of the identified CI with those dependent CIs. Identification with a dependent identification rule is based on the dependent CIs and the relationships and qualifiers between the identified CI and its dependent CIs. Identification then requires more time than with an independent identification rule and is prone to some identification errors. Usage of dependent rules should therefore be minimized.

CI modeling determines which type of identification rules are required for proper CI identification.

Create identification rules using the following order of importance:

Independent identification rules — It is always preferable to create independent identification rules rather than dependent identification rules. When you model a CI, define the CI with a complete set of attributes that lend themselves to independent identification, eliminating the need to use additional CIs for identification.
Dependent identification rules — If it is necessary to create dependent identification rules, then define a single level of dependency. Two is the maximum number of dependency levels that is supported.
Avoid creating lookup identifier entries. The use of lookup identifier entry is highly discouraged as it can reduce performance. If unavoidable, ensure to first review class definitions and consider updates that allow usage of independent identification rules.
Limit the number of identifier entries within an identification rule, ideally to 1. A second identifier entry can further reduce performance, as will each additional identifier entry.
Create strong identification rules in which the strongest identifier entries and related entries are set with the highest priority.
Ensure that the identification rule is at the class level that it needs to be.

Payload

Create the payload using the following order of importance:

Payload size — Limit the number of CIs per payload to 500.

Avoid duplicate entries in the payload.

Example: If an identification rule has a criterion attribute for the name field, then the following payload has duplicate items resulting in failure:

var payload = {
    items: [{
        className:'cmdb_ci_linux_server',
        values: {
            name:'Win Server 200',
            ram:'2048'
        }},
{
        className:'cmdb_ci_linux_server',
        values: {
            name:'Win Server 200',
            ram:'4096'
        }}]
};

Do not pass system data such as the following in the payload.

var payload = {
    items: [{
        className:'cmdb_ci_linux_server',
        values: {
            name:'Win Server 200',
            sys_domain:'global',
            sys_domain_path:'xyz',
            sys_updated_on:'2017-06-15 16:25:11',
            sys_mod_count:23,
        }}]
};

Provide the minimum necessary set of criterion attributes for each payload item, according to what is specified in the corresponding identification rules.

When matching CIs, use CIs’ sysIds if available. If provided, IRE can use the sysId to directly locate a CI without requiring any criterion attributes from the identification rule. In this case, IRE does not use the sysId in the matching process.

Example: Independent CI that needs to be updated — sysId is available.

var payload = {
    items: [{
        className:'cmdb_ci_linux_server',
        values: {
            sys_id:'194876usytrr65378098',
            ram:'2048',
        }}]
};

Example: Dependent CI that needs to be inserted. Tomcat War CI depends on Tomcat CI, and Tomcat CI depends on Linux Server CI. SysIds for the Tomcat and the Linux CIs are available.

var payload = {
        items: [{
            className:'cmdb_ci_app_server_tomcat_war’, 
            values: {
                name:'war1',
                short_description:'my description'            }
        }, {
            className:'cmdb_ci_app_server_tomcat',
            values: {
                sys_id:'194876usytrr65378098'
            }
        }, {
            className:'cmdb_ci_linux_server',
            values: {
                sys_id:'09876tysueyt6345lakiu'
            }
        }],
        relations: [{
                    parent:1,
                    child:0,
                    type: 'Contains::Contained by’}, {
                        parent:1,
                        child:2,
                        type:'Runs on::Runs'}
                    ]
                };

Example: Dependent CI that needs to be updated — sysId is available.

var payload = {
        items: [{
            className:'cmdb_ci_app_server_tomcat_war', 
            values: {
                sys_id:'039387euey637465sytet',
                short_description:'my description new'            }
        }]
                };

When inserting many CIs, all of which depend on the same CI, you should serialize your API calls. Otherwise, attempting to concurrently process many CIs can clog the system, significantly degrading overall system performance.