Unlock CMDB Power: Master Real Relationship Mapping

By /




Mastering Real CMDB Relationship Mapping: A Deep Dive with Practical Insights


Mastering Real CMDB Relationship Mapping: A Deep Dive with Practical Insights

In the intricate world of IT Service Management (ITSM), a Configuration Management Database (CMDB) stands as the backbone, providing a centralized repository of all your IT assets and their relationships. But a CMDB is more than just a glorified inventory; its true power lies in understanding the dynamic interplay between these assets – its relationship mapping. This article aims to demystify real CMDB relationship mapping, offering practical insights, real-world examples, and even some interview-focused tips based on common ServiceNow scenarios.

We’ll explore how to build a robust CMDB, the best practices for managing relationships, and delve into the underlying technicalities that make it all work. Whether you’re a seasoned IT professional or just starting your ITSM journey, this guide will equip you with the knowledge to leverage your CMDB for maximum impact.

Understanding the Core: What is CMDB Relationship Mapping?

At its heart, CMDB relationship mapping is the process of defining and documenting the connections between different Configuration Items (CIs) within your IT environment. These relationships are crucial for understanding the impact of changes, diagnosing issues, and performing effective asset management.

Think of it like a city map. A standalone building is just an address. But when you map its connections to roads, utilities (water, electricity), public transport, and nearby businesses, you gain a comprehensive understanding of its role in the city’s ecosystem. Similarly, in a CMDB, mapping relationships allows you to:

  • Impact Analysis: Understand what other CIs will be affected if a particular CI fails or undergoes a change.
  • Root Cause Analysis: Trace the lineage of a problem to identify the underlying causes.
  • Service Dependency Mapping: Visualize how different services rely on various infrastructure components.
  • Change Management: Assess the risk and potential disruptions associated with planned changes.
  • Asset Lifecycle Management: Track dependencies and ensure proper decommissioning.

Building the Foundation: Essential CMDB Concepts

Before diving into relationships, let’s quickly recap some foundational CMDB concepts, referencing common ServiceNow terminology and practices.

Configuration Items (CIs)

CIs are the building blocks of your CMDB. They represent any component that needs to be managed to deliver an IT service. This can include hardware (servers, laptops), software (applications, operating systems), services, users, and even documentation. In ServiceNow, CIs reside in tables that typically extend the cmdb_ci table.

CI Classes and Inheritance

To organize CIs, ServiceNow employs a class hierarchy. For example, there’s a base task table and CI tables like incident, problem, and change_request extend it. Similarly, the cmdb_ci table is a base table for all Configuration Items. When you extend a table, its attributes and fields are inherited by the child table, creating a structured hierarchy.

Troubleshooting Tip: Understanding table inheritance (extending tables) is key. When you extend a table, sys fields don’t get recreated in the child. A ‘class’ field is added to the parent table to track the actual CI type. This is a fundamental concept for database design in ServiceNow.

Out-of-the-Box (OOTB) vs. Custom Tables

OOTB tables are those that come pre-installed with ServiceNow, like incident, problem, and change_request. They typically don’t start with ‘x_’ or ‘u_’. Custom tables, often found in scoped applications, start with ‘x_’. Knowing the difference is important for understanding where data resides and how it’s managed.

The Art of Connection: Defining Relationships

Relationships in a CMDB are not just abstract links; they are formally defined connections between CIs. These relationships are typically stored in a dedicated relationship table, often within the CMDB. Each relationship record defines:

  • Parent CI: The CI initiating the relationship.
  • Child CI: The CI being related to the parent.
  • Relationship Type: The nature of the connection (e.g., “Runs On,” “Depends On,” “Connects To”).

Common Relationship Types

ServiceNow provides a rich set of predefined relationship types, and you can also create custom ones. Some common examples include:

  • Runs On: A server CI “Runs On” an operating system CI.
  • Depends On: An application CI “Depends On” a database CI.
  • Connects To: A network device CI “Connects To” another network device CI.
  • Contains: A server CI “Contains” a software application CI.
  • Used By: A user CI “Used By” a desktop CI.

Interview Relevance: When asked about CMDB relationships, be ready to explain the different types and provide practical examples of how they are used to understand service dependencies and impact.

Best Practices for Real CMDB Relationship Mapping

Simply creating relationships isn’t enough. To maximize the value of your CMDB, follow these best practices:

1. Standardize Your CI Identification and Naming Conventions

Consistent naming and identification are paramount. If a server is named ‘WebSrv01’ in one system and ‘webserver01.example.com’ in another, it’s nearly impossible to link them. Use discovery tools and automation to ensure CIs are uniquely identified and consistently named.

2. Define Clear Relationship Types

Don’t be ambiguous. “Connected to” is vague. “Networked via Ethernet” is specific. Clearly defined relationship types make it easier to understand the nature of the connection and perform accurate analysis.

3. Prioritize Critical Relationships

You don’t need to map every single micro-dependency. Focus on the relationships that are critical for your core services, high-impact CIs, and business-critical applications. Start with the most important and expand iteratively.

4. Automate Relationship Discovery

Manual mapping is time-consuming and prone to errors. Leverage discovery tools (like ServiceNow’s Discovery and Service Mapping) to automatically identify CIs and their relationships. This is crucial for maintaining an up-to-date CMDB.

5. Regularly Audit and Validate Relationships

Your IT environment is dynamic. CIs are added, removed, and modified constantly. Regularly audit your CMDB relationships to ensure accuracy and remove obsolete connections. This can involve automated checks and manual validation.

6. Integrate with Other ITSM Processes

The real power of CMDB relationships shines when integrated with other ITSM processes:

  • Incident Management: When an incident occurs on a CI, its relationships can quickly reveal the potential impact on other services and applications.
  • Change Management: Before implementing a change, analyze the relationships of the affected CI to understand the potential ripple effects.
  • Problem Management: Use relationships to identify recurring patterns and root causes across interconnected CIs.

Real-World Example: Imagine a web application (Application CI) suddenly becomes unavailable. By examining its relationships, you might discover it “Runs On” a specific web server (Server CI), which “Connects To” a particular database (Database CI), and this database “Relies On” a storage array (Storage CI). This interconnectedness helps pinpoint the most likely culprit.

Under the Hood: Scripting and Automation in ServiceNow

ServiceNow’s scripting capabilities, particularly using GlideRecord, are invaluable for managing CIs and their relationships programmatically. Let’s look at some practical examples based on the provided references.

Managing Users and Groups

Understanding user and group management is fundamental to access control and resource allocation, which indirectly impacts CMDB access and ownership.

Creating User Accounts

When you need to provision new user accounts, scripting is efficient:

var userGr = new GlideRecord('sys_user');
userGr.initialize();
userGr.username = 'jdoe';
userGr.firstname = 'John';
userGr.lastName = 'Doe';
userGr.email = 'jdoe@example.com';
userGr.insert();

This script creates a new user record in the sys_user table.

Creating Groups

Similarly, creating new IT teams or support groups can be automated:

var newGr = new GlideRecord('sys_user_group');
newGr.initialize();
newGr.name = 'Testing Team';
newGr.manager = '62826bf03710200044e0bfc8bcbe5df1'; // sys_id of the manager
newGr.email = 'testing@tcs.com';
newGr.description = 'A team for testing purposes';
newGr.insert();

This creates a new entry in the sys_user_group table.

Adding Permissions to Users and Groups (Best Practice!)

Permissions, in the form of roles, are crucial for controlling access. The best practice is to assign roles to groups rather than individual users.

Best Practice: Assigning permissions (roles) to groups is the recommended approach. When an employee leaves, removing them from the group automatically revokes their roles, simplifying user management and enhancing security.

Adding a role to a user:

var userRole = new GlideRecord('sys_user_has_role');
userRole.setValue('user', '62826bf03710200044e0bfc8bcbe5df1'); // sys_id of the user
userRole.setValue('role', '2831a114c611228501d4ea6c309d626d'); // sys_id of the role
userRole.insert();

Adding a role to a group:

var grpRole = new GlideRecord('sys_group_has_role');
grpRole.setValue('group', '477a05d153013010b846ddeeff7b1225'); // sys_id of the group
grpRole.setValue('role', '2831a114c611228501d4ea6c309d626d'); // sys_id of the role
grpRole.insert();

Managing Group Memberships

Programmatically adding or removing users from groups is a common administrative task.

Adding a member to a group:

var grMem = new GlideRecord('sys_user_grmember');
grMem.user = '62826bf03710200044e0bfc8bcbe5df1'; // sys_id of the user
grMem.group = '477a05d153013010b846ddeeff7b1225'; // sys_id of the group
grMem.insert();

Removing a member from a group:

var grMem = new GlideRecord('sys_user_grmember');
grMem.addQuery('user', '62826bf03710200044e0bfc8bcbe5df1');
grMem.addQuery('group', '477a05d153013010b846ddeeff7b1225');
grMem.query();
if (grMem.next()) {
    grMem.deleteRecord();
}

Creating and Linking CIs, Incidents, Problems, and Changes

The interconnectedness of Incident, Problem, and Change management with the CMDB is where relationship mapping truly proves its worth.

Creating Incident, Problem, and Change Records

These records are often linked to CIs, establishing a direct CMDB relationship.

Creating an Incident:

var gr = new GlideRecord('incident');
gr.initialize();
gr.caller_id = '86826bf03710200044e0bfc8bcbe5d94'; // sys_id of the caller
gr.category = 'inquiry';
gr.subcategory = 'antivirus';
gr.cmdb_ci = 'affd3c8437201000deeabfc8bcbe5dc3'; // sys_id of the CI
gr.short_description = 'Test record using script';
gr.description = 'Test record using script';
gr.assignment_group = 'a715cd759f2002002920bde8132e7018'; // sys_id of the assignment group
gr.insert();

Creating a Problem:

var gr = new GlideRecord('problem');
gr.initialize();
gr.caller_id = '86826bf03710200044e0bfc8bcbe5d94';
gr.category = 'inquiry';
gr.subcategory = 'antivirus';
gr.cmdb_ci = 'affd3c8437201000deeabfc8bcbe5dc3';
gr.short_description = 'Test record using script';
gr.description = 'Test record using script';
gr.assignment_group = 'a715cd759f2002002920bde8132e7018';
gr.insert();

Creating a Change Request:

var gr = new GlideRecord('change_request');
gr.initialize();
gr.category = 'inquiry';
gr.subcategory = 'antivirus';
gr.cmdb_ci = 'affd3c8437201000deeabfc8bcbe5dc3';
gr.short_description = 'Test record using script';
gr.description = 'Test record using script';
gr.assignment_group = 'a715cd759f2002002920bde8132e7018';
gr.insert();

Interview Relevance: When asked about the relationship between Incident, Problem, and Change, explain the lifecycle: an incident arises from an issue, a problem is identified for recurring incidents, and a change request is raised to fix the underlying problem. Each can be linked to a CI, forming a vital CMDB connection.

Automating Workflows with Business Rules

Business rules are essential for automating actions based on record changes, directly impacting relationship management and workflow integrity.

Closing Child Incidents When Parent is Closed

This ensures consistency and avoids orphaned records:

// After Business Rule on Incident table
// Condition: current.state.changesTo(7); // Assuming 7 is the 'Closed' state
if (current.state == 7 && current.parent == '') {
    var grChild = new GlideRecord('incident');
    grChild.addQuery('parent', current.sys_id);
    grChild.query();
    while (grChild.next()) {
        grChild.state = 7; // Set state to Closed
        grChild.update();
    }
}

Preventing Incident Closure with Open Tasks

This enforces process adherence:

// Before Business Rule on Incident table
var grTask = new GlideRecord('incident_task');
grTask.addQuery('incident', current.sys_id);
grTask.addQuery('state', '!=', 3); // Assuming 3 is 'Closed' state for incident tasks
grTask.query();

if (grTask.hasNext()) {
    gs.addErrorMessage('Cannot close the incident because there are open tasks.');
    current.setAbortAction(true);
}

Similar logic applies to problems and change requests, ensuring all associated tasks are resolved before closure.

Closing Associated Incidents When a Problem is Closed

This maintains data integrity and reflects resolution status across related records.

// After Business Rule on Problem table
// Condition: current.state == 7; // Assuming 7 is the 'Closed' state
if (current.state == 7) {
    var grIncident = new GlideRecord('incident');
    grIncident.addQuery('problem_id', current.sys_id);
    grIncident.addQuery('state', '!=', 7); // Assuming 7 is 'Closed'
    grIncident.query();
    while (grIncident.next()) {
        grIncident.state = 7; // Set state to Closed
        grIncident.update();
    }
}

Deep Dive into ServiceNow Dictionary and Field Types

Understanding the underlying table structure and field types is crucial for effective CMDB design and relationship mapping.

Field Types

ServiceNow offers a wide array of field types, each serving a specific purpose:

// Examples of Field Types:
// Reference, String, List, Choice, Email, Date/Time, Date, Boolean, Integer, Journal, Attachment

Reference fields are particularly important for relationships, as they link records from one table to another.

Table Concepts

  • Base Tables: Tables that do not extend any other table but are extended by many others (e.g., task, cmdb_ci).
  • Extending Tables: Child tables inherit properties from parent tables. This is fundamental for organizing CIs and other data.
  • Temporary Tables: Store data for a limited period (e.g., 7 days) and extend the import_set_row table. Retention can be adjusted via archive rules.
  • Remote Tables: Provide live data from external sources, unlike normal tables which store local data.

Relationships Between Tables

  • One-to-Many: One record in table A can be related to many records in table B (e.g., one User can have many Incidents).
  • Many-to-Many: Records in table A can be related to many records in table B, and vice-versa (e.g., Incidents and Groups).

Dictionary Overrides and Attributes

Dictionary Overrides allow you to modify field properties in child tables that differ from their parent. Attributes are special keywords that modify field behavior (e.g., no_email, no_attachment). For instance, to disable attachments on a form, you’d use the no_attachment attribute on the collection field.

Reference Qualifiers

These are essential for controlling the data shown in reference and list fields, ensuring users select relevant CIs for relationships.

  • Simple: Fixed queries (e.g., active=true).
  • Dynamic: Context-aware queries using Dynamic Filter Options.
  • Advanced: Custom JavaScript for complex filtering logic.

Troubleshooting Tip: If your reference field isn’t showing the expected CIs, double-check your reference qualifier settings. A common mistake is an incorrectly formulated query or an incorrect Dynamic Filter Option.

User Management and Access Control

While not directly CMDB relationships, user and group management are critical for who can access, modify, and view CMDB data and its related records.

  • Web Services User: A user account exclusively for third-party applications to connect to ServiceNow, without direct login capabilities.
  • User Delegation: Allowing one user to act on behalf of another, often used for absence coverage.
  • Impersonation: Logging in as another user for testing purposes (requires appropriate roles like security_admin).
  • User Preferences: Individual settings that only affect the logged-in user.

Interview Relevance: Be prepared to explain concepts like User Delegation, Impersonation, and the difference between client-side (g_user.UserID) and server-side (gs.getUserID()) ways to get the current user’s ID.

Ensuring Data Integrity: UI Policies and Data Policies

UI Policies and Data Policies are crucial for enforcing data consistency and user experience, both client-side and server-side.

  • UI Policies: Control field visibility, mandatory status, read-only state, and show/hide related lists on the client-side. The global checkbox affects all views, while reverse if false and on load control their behavior.
  • Data Policies: Enforce similar rules but operate on both client and server sides, ensuring data integrity regardless of how the record is accessed.

Conversion: UI Policies can often be converted into Data Policies, though certain functionalities like controlling data visibility, views, related lists, or scripts might not be directly convertible and require manual adaptation.

Conclusion

Real CMDB relationship mapping is a continuous journey, not a destination. By understanding the core concepts, implementing best practices, and leveraging the power of automation and scripting, you can transform your CMDB from a static inventory into a dynamic, intelligent system. This, in turn, empowers your IT organization to make informed decisions, resolve issues faster, manage changes more effectively, and ultimately deliver superior IT services.

Mastering CMDB relationships is not just about technical proficiency; it’s about understanding the intricate web of your IT ecosystem and using that knowledge to drive business value.


Scroll to Top