Dependent CIs management

  • Release version: Xanadu
  • Updated August 1, 2024
  • 10 minutes to read
    • Summarize
    Summarized using AI
    This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.

    Summary of Dependent CIs Management

    Dependent CIs management in ServiceNow ensures the integrity and health of your CMDB by automatically handling cascading lifecycle updates—such as delete, archive, or retire—on dependent Configuration Items (CIs) when their parent CIs undergo changes. This prevents orphaned dependent CIs, which are CIs lacking required relationships due to parent CI updates, from cluttering your CMDB.

    Show full answer Show less

    This feature relies on CMDB Data Manager for approval workflows and execution of cascade-cleanup operations to maintain accurate and reliable data.

    Enabling and Configuration

    • Configure your environment for CMDB Data Manager, which manages lifecycle update tasks.
    • Enable dependent CIs management by setting the cmdb.dependent.ci.cascade.op.enabled system property to true (default is true but must be added manually if missing).
    • To enable cascade-retirement of dependent CIs, set the cmdb.dependent.ci.cascade.retire.enabled property to true (false by default and must also be added if missing).
    • Use CMDB Data Manager to approve or automate approvals for dependent CI lifecycle tasks to execute cascade operations.
    • For existing orphan dependent CIs created before enabling this feature, run the one-time Cleanup Orphan CIs scheduled job to identify and process them.

    How Cascade Operations Work

    Dependent CIs management uses CMDB Data Manager along with scheduled jobs and business rules to perform cascade-cleanup:

    • Cascade-Retire: When a CI is retired (marked End of Life), dependent CIs are also marked for retirement and processed via Data Manager tasks after approval.
    • Cascade-Archive: Archiving a CI archives its relationships, then identifies orphan dependent CIs to archive them unless they are duplicates, have multiple parents, or belong to excluded classes (which can be customized).
    • Cascade-Delete: Deleting a CI removes its relationships and identifies orphan dependent CIs for deletion, subject to similar exclusion rules as archiving.
    • Extraneous relationships (not part of the dependency chain) are tracked and managed based on the cmdb.dependent.ci.extra.rel.check system property, which can be configured to control their deletion or archiving.

    Practical Benefits for ServiceNow Customers

    • Maintains CMDB data integrity by automatically handling dependent CI lifecycle changes and preventing orphan CI buildup.
    • Enables controlled, auditable cascade operations through CMDB Data Manager workflows with optional manual approvals or automated processing.
    • Provides flexibility to exclude specific classes (e.g., VMware-related CIs) from orphan dependent CI management, tailored to your environment.
    • Supports cleanup of pre-existing orphan dependent CIs with a dedicated scheduled job for one-time remediation.

    Example Scenario

    When retiring a Linux Server CI with dependent CIs such as Network Adapter and File System:

    1. Enable dependent CIs management and publish a retire policy in CMDB Data Manager.
    2. Retire the server CI and approve the retirement task.
    3. Scheduled jobs identify dependent CIs and add them to the dependent CI ledger for retirement.
    4. Approve dependent CI retire tasks to complete cascade-retirement, ensuring all dependent CIs are properly retired.

    Key Considerations

    • Dependent CIs in Data Manager are specifically missing their dependent relationships, differing from the broader orphan CI concept in CMDB Health KPIs.
    • Approval tasks generated by CMDB Data Manager must be reviewed or configured for automatic approval to proceed with cascade operations.
    • Excluded classes can be managed via the CMDB Dependent CI Class Exclusion table, allowing customization of which CIs are exempt from cascade-cleanup.
    • Scheduled jobs and business rules must be active and properly configured to ensure cascade operations function as expected.

    A life cycle update for a CI affects its dependent CIs. For example, when the CI that a dependent CI depends on is deleted, the dependent CI becomes orphan with no further use. To maintain the integrity and health of the CMDB, the system applies cascade-cleanup processes to dependent CIs that are affected by a life cycle update.

    For information about independent and dependent CIs, see CMDB classifications and class dependency.

    To ensure that dependent CIs are properly managed after deleting or archiving CIs, you must:
    1. Enable dependent CIs management as described on this page.
    2. Manually approve the CMDB Data Manager tasks that dependent CIs management generates, or configure those tasks to not require a review or an approval.
    Note:
    An Orphan dependent CI in the context of Data Manager is different from an orphan CI in the context of CMDB Health. An orphan dependent CI within the context of Data Manager belongs to a dependent class, and is missing the dependent relationship. The definition of an orphan CI in the context of CMDB Health is broader, and includes any CI that matches CMDB Health orphan rules. For more information about orphan CIs in CMDB Health, see CMDB Health KPIs and metrics.
    Examples of dependent CIs needing cascade-cleanup:
    • Tomcat application (T1) runs on a Linux Server (L1) and contains a WAR file (W1). When L1 is deleted, T1 and W1 become orphan dependent CIs.
    • Network Adapters become orphan dependent CIs when the hardware itself is deleted.
    • A Linux Server has retired and is set with end of life, the assumption is that if the server is no longer operational then applications which depend on it shouldn’t be operational either.

    Enable dependent CIs management

    To enable dependent CIs management:
    • Configure your environment for CMDB Data Manager. For details about how to configure the environment for CMDB Data Manager and the CMDB Data Manager own prerequisites, see Working with CMDB Data Manager.
    • Ensure that the cmdb.dependent.ci.cascade.op.enabled system property is set to true (true by default). This property enables cascade operations and doesn't exist in the base system. Therefore, to view or modify the property value, you must first add it to the System Properties [sys_properties] table.
    • To enable cascade-retirement processes, ensure that the system property cmdb.dependent.ci.cascade.retire.enabled, which is used to manage cascade-retirement of CIs, is set to true (false by default). The business rule After BR: Track “Retired” CIs, that checks for downstream CI dependencies, runs only if this property is set to true. This property doesn't exist in the base system and to view or modify it, you must first add it to the System Properties [sys_properties] table.

    Cascade-cleanup operations apply only from when you enable the dependent CIs management feature. To apply cascade-cleanup to orphan dependent CIs that already existed in the CMDB before enabling the feature, see Cascade-cleanup existing orphan dependent CIs.

    Use of CMDB Data Manager to perform cascade-cleanup operations

    Dependent CIs management processes use the CMDB Data Manager to process the life cycle updates for the dependent CIs in the CMDB Dependent CI Ledger [cmdb_dependent_ci_ledger] table in the following ways:
    1. Requesting and getting approvals from users for the life cycle updates for the CIs.
    2. Performing the actual delete, archive, or retire CI updates after these operations are approved.

    The system generates tasks for the 'Dependent CI - Deletion', 'Dependent CI - Archive', and 'Dependent CI - Retire' Data Manager policies, with the CIs that are ready to be deleted, archived, or retired as target CIs. These policies are set with the respective 'On Demand' policy types. Then, a Data Manager admin or user, according to the Managed By Group setting, must review and approve these tasks before the Data Manager applies the respective subflow to the dependent CIs.

    To automatically approve those tasks, use the CMDB Data Manager to clear the Needs Review flag of the respective Data Manager policies. Those tasks will then run without requiring any user intervention.

    Cascade-retire dependent CIs

    When a CI is set to retire, dependent CIs management data processes attempt to cascade-update all the CIs depending on that CI, also to retire.

    1. CI is updated to retire as the CI’s Life Cycle Stage attribute is set to End of Life according to CSDM standards.

    2. Business rule After BR: Track “Retired” CIs runs (only if the system property cmdb.dependent.ci.cascade.retire.enabled is true) to check if the CI belongs to a class which has any downstream dependencies.

      If yes: The CI is added to the CMDB CI End Of Life Ledger [cmdb_ci_end_of_life_ledger] table.

    3. For each CI in the CMDB CI End Of Life Ledger [cmdb_ci_end_of_life_ledger] table, the scheduled job CMDB Cascade Retire Dependent CIs checks the CI’s relationships in the CI Relationship [cmdb_rel_ci] table. If there is a dependent relationship with a dependent CI, then that dependent CI is added to the CMDB Dependent CI Ledger [cmdb_dependent_ci_ledger] table with the Retire action.

      For more information about dependent relationship rules, see CMDB dependent relationship rules.

    4. Scheduled Job CMDB DependentCI Policy Processor runs (if the system property cmdb.dependent.ci.cascade.retire.enabled is true) to process the CIs in the CMDB Dependent CI Ledger [cmdb_dependent_ci_ledger] table. Those CIs are set as being ready to retire upon approval using the CMDB Data Manager. A task is created in the CMDB Data Manager against the Dependent CI Retire policy to actually retire the CIs.

    Cascade-archive dependent CIs

    Archiving a CI can leave its dependent CIs as orphans in the CMDB. To prevent the accumulation of stale data, the system applies cleanup processes that cascade-archive those orphan dependent CIs.

    Orphan dependent CIs are not immediately archived. When a CI is archived, all the CI relationship records for that CI in the [cmdb_rel_ci] table, are also archived. The system then checks for any dependent CIs that were orphaned as a result of this archiving. Any CIs in the dependency chain that are identified as orphan dependent CI, are checked for any of the following conditions. CIs that meet any of these conditions are not orphan dependent CIs and therefore will not be archived:

    • The CI is an unhandled duplicate CI (the CI is associated with an unresolved de-duplication task).
    • The CI has multiple parent CIs.
    • The CI belongs to an excluded class. Excluded classes are stored in the CMDB Dependent CI Class Exclusion [cmdb_dependent_ci_class_exclusion] table. In the base system, that table is pre-populated with some classes such as cmdb_ci_vm, cmdb_ci_vmware_instance, and other VMware-related classes. You can manage the set of classes that are exempt from management of orphan dependent CIs, by adding or removing records to that table.
    Eventually, only those CIs that these conditions do not apply to are added to the CMDB Dependent CI Ledger [cmdb_dependent_ci_ledger] table. Those CIs are set as being ready for archival using the CMDB Data Manager, upon approval.

    Cascade-delete dependent CIs

    Deleting a CI can leave its dependent CIs as orphans in the CMDB. To prevent the accumulation of stale data, the system applies cleanup processes that cascade-delete those orphan dependent CIs.

    1. CI is updated to be deleted as the CI’s Life Cycle Stage attribute is set to End of Life according to CSDM standards.

    2. All relationships in the cmdb_rel_ci table, associated with the deleted CI, are deleted.

    3. Business rule After BR: CMDB Dependent CI Delete runs (only if the system property cmdb.dependent.ci.cascade.op.enabled is true) to check each of the deleted relationships in the CI Relationship [cmdb_rel_ci] table, whether the other CI (parent or child) in the relationship is an orphan dependent CI.

      If yes: Those orphan dependent CIs are added to the CMDB Dependent CI Ledger [cmdb_dependent_ci_ledger] table and set with Action = Delete.

    4. Scheduled Job CMDB DependentCI Policy Processor runs (if the system property cmdb.dependent.ci.cascade.retire.enabled is true) to process the CIs in the CMDB Dependent CI Ledger [cmdb_dependent_ci_ledger] table. Those CIs are set as being ready to be deleted upon approval using the CMDB Data Manager. A task is created in the CMDB Data Manager against the Dependent CI Delete policy to actually delete the CIs.

    Orphan dependent CIs aren't immediately deleted. Prior to deleting each of the CIs relationship in the CI Relationship [cmdb_rel_ci] table, the system checks if other CI in the relationship belongs to a dependent class. Any CIs in the dependency chain that are identified as dependent on the deleted CI, are checked for any of the following conditions. CIs that meet any of these conditions aren't orphan dependent CIs and therefore aren't marked for deletion:

    • The CI is an unhandled duplicate CI (the CI is associated with an unresolved de-duplication task).
    • The CI has multiple parent CIs.
    • The CI belongs to an excluded class. Excluded classes are stored in the CMDB Dependent CI Class Exclusion [cmdb_dependent_ci_class_exclusion] table. In the base system, that table is pre-populated with some classes such as cmdb_ci_vm, cmdb_ci_vmware_instance, and other VMware-related classes. You can manage the set of classes that are exempt from management of orphan dependent CIs, by adding or removing records to that table.
    Eventually, only those CIs that these conditions don't apply to are added to the CMDB Dependent CI Ledger [cmdb_dependent_ci_ledger] table. Those CIs are set as being ready for deletion using the CMDB Data Manager, upon approval.

    Extraneous relationships

    For the delete and archive operations, the system also tracks CIs' extraneous relationships in the Dependent CI Relations Evaluation Config [cmdb_dependent_ci_extra_rels_config] table. Extraneous relationships are those relationships that aren't in the CI’s chain of dependency and deleting or archiving them depends on the value of the cmdb.dependent.ci.extra.rel.check system property. This property is set to true by default, in which case extraneous relationships aren'tt deleted or archived. You can set the property to false to delete and archive extraneous relationships.

    The cmdb.dependent.ci.extra.rel.check property doesn't exist in the base system and to view or modify the property value, you must first add it to the System Properties [sys_properties] table.

    Cascade-cleanup existing orphan dependent CIs

    When enabling the dependent CIs management feature, the cascade-cleanup operations apply only from when the feature is enabled. However, it might be necessary to apply a similar cascade-cleanup operation to orphan dependent CIs that already existed in the CMDB before the feature was enabled.

    Activate the Cleanup Orphan CIs scheduled job to perform a one-time cascade-cleanup of orphan dependent CIs across the CMDB. The Cleanup Orphan CIs scheduled job checks throughout the entire CMDB to identify any orphan dependent CIs. These CIs are then processed in the same manner that CIs that are cascade-deleted are processed. CIs that are ready to be deleted are added to the CMDB Dependent CI Ledger [cmdb_dependent_ci_ledger] table. The CMDB Data Manager is then leveraged as described in the Use of CMDB Data Manager to perform cascade-cleanup operations section.

    The Cleanup Orphan CIs scheduled job is intended to run only once, after which the job deactivates itself. Depending on the size of the CMDB, it might take the Cleanup Orphan CIs scheduled job several days to complete.

    Sample scenario: cascade-retire

    1. Enable dependent CIs management.
    2. In CMDB Data Manager, create and publish a Retire policy. For example, retire an independent Linux Server CI with relationships to the dependent CIs Network Adapter and File System.
    3. Wait for the scheduled job CMDB Data Manager Retire Policy Processor to run, or run it manually.
    4. In the Data Manager overview page, select the Open task card and approve the retirement task (Approval=Approved). Change the state of the task to 'Work in progress' if it doesn't change automatically. This will retire the Linux Server CI and add it to the cmdb_ci_end_of_life_ledger table.

    5. Run the scheduled job CMDB Cascade Retire Dependent CIs.

      This scheduled job processes each CI in the cmdb_ci_end_of_life_ledger table, and queries the relationships in the cmdb_rel_ci table for this CI. If a relationship exists with other dependent CI, then those dependent CI are added to the cmdb_dependenct_ci_ledger table with the settings of state = 'Ready' and action = 'Retire'.

    6. Wait for the scheduled job CMDB DependentCI Policy processor to run, or run it manually. This scheduled job creates a task against the OOB Dependent CI Retire policy, targeting the CIs in the cmdb_dependenct_ci_ledger table.
    7. In the Data Manager overview page, select the Open task card and approve the task described with “Dependent CI – Retire..”.