CMDB Data Manager - Product Documentation: Vancouver

CMDB Data Manager

CMDB Data Manager is a policy-driven framework for bulk management of CI life cycle operations such as deletion, archival, and attestation. The CMDB Data Manager is a comprehensive and integrated solution, which scales to large CMDBs and copes with rapid changes in a cloud-based world.

Large CMDBs can over time accumulate large amounts of stale CIs that can impact overall performance. Custom mitigating solutions can be difficult to develop and to maintain, and are also prone to errors. The CMDB Data Manager is the tool where you can create, publish, and manage policies. Create policies to automate and govern CI life cycle operations to help maintain the CMDB in a healthy and efficient operational state.

You can apply CMDB Data Manager policies only to classes that extend the Configuration Item [cmdb_ci] table. Therefore, you can't use the CMDB Data Manager to manage classes such as those that were imported by CMDB CI Class Models.

Terms Policy

A CMDB Data Manager policy captures the overall management plan for a life-cycle event, such as CI retirement. A policy is associated with a subflow (the policy subflow) which creates the tasks (the policy tasks) for the target CIs of the policy. A policy is configured with a policy type and the policy tasks perform operations associated with that policy type, such as archiving or deleting a CI record. Also, you can configure a policy to require an approval.

The policy type, policy subflow, and the policy tasks, are all aligned to a specific life cycle event of CIs. For example, a policy set with the delete policy type, is associated with the delete subflow, and its policy tasks handle the deletion of CIs.

A daily scheduled job processes all published CMDB Data Manager policies.

Policy subflow

The policy subflow contains the underlying logic to process a life cycle event such as retire or delete. If the policy is configured to require approval, then the policy subflow runs only after a policy task is approved.

The base system provides several common subflows, such as delete, archive, and retire, which you can use with policies. You can also create custom subflows that are needed in the organization.

Policy task

A separate task is created and assigned to each unique Managed By Group value within the set of target CIs in a policy. A policy task triggers the policy subflow, tracks the set of target CIs for the task, and handles the approval of the task, if necessary.

If a policy requires an approval, the policy tasks don’t trigger the policy subflow until a member of the group assignment in the Managed by Group attribute of the target CIs, approves the tasks. If a task is rejected or if the Managed by Group attribute is empty, the task is assigned to an administrator who must manually intervene to resolve the task.

If a policy isn't configured to require an approval, then the policy tasks are automatically approved.

CI exclusion list

A set of CIs to which policies of a specified type don't apply.

Policy types You can create policies of the following types: Delete

Use to remove a CI from its current table with no option to restore the CI into an active state.

Retire

Use to retire a CI while keeping the CI active in list views and in processes such as CMDB Health.

Attestation

Use to assign and process attestation tasks that verify the existence of actual IT infrastructure and applications that you own. As CIs are continuously ingested into the CMDB from various data sources, attesting CIs support the integrity of the CMDB. For more information about using the Attestation policy type, see Attesting CIs .

Archive

Use to remove a CI from its current table and store the CI in a separate archive table for temporary retention. Archiving a CI excludes the CI from views and from features such as maps and the relations formatter. During the retention period, you can restore CIs into active state . At the end of the retention period, archived CIs are deleted from their archive table.

Delete CMDB Related Entry

Use to clean up any irrelevant or stale data from related tables to help keep CMDB data healthy and relevant as the state of referenced CIs change.

Related tables, such as the Serial Number [cmdb_serial_number] table, aren't part of the CMDB hierarchy but still qualify as CMDB data. Related tables don't inherent from the Configuration Item [cmdb_ci] table, but have at least one column that references a CMDB CI. Related tables are specified in the Related Entries [cmdb_related_entry] table.

You can implement your Retire, Delete, and Archive policies so that they follow <a class="xref" href="../../csdm-implementation/concept/csdm-landing-page.html" title="The CSDM is the data framework that admins should follow when they set up ServiceNow products and applications. The standards for defining configuration items (CIs) and relationships between CIs in the CMDB ensure that your data resides in the appropriate CMDB tables. The result is maximum value from Now Platform applications.">Common Service Data Model (CSDM) standards where for example, CIs are archived and deleted only when a CI is already in retired state. When you create these life cycle policies, the system applies processes to manage any dependent CIs that might be left behind. For more details about these processes and about verifying that the feature is enabled, see Dependent CIs management .

Now Platform® data archiving The functionality that the Archive policy type in CMDB Data Manager provides, relies and extends the Now Platform® data archiving feature , applied specifically for CMDB CIs. While processing an Archive policy to archive CMDB CIs, CMDB Data Manager uses components and processes of Now Platform® data archiving in the following ways: The Archive Rule [sys_archive] table contains the Now Platform® archive rules including the Archive Configuration Items CMDB archive rule which CMDB Data Manager Archive policies use. Data Manager relies on the Archive scheduled job to run (every hour by default) and process CMDB Data Manager archive policies. The Archive scheduled job is stored in the Schedule Item [sys_trigger] table. In the Now Platform® table Archive Job Execution Chunks [sys_archive_run_chunk], the Keys attribute contains the sys_ids of the CMDB CIs to be archived (where Rule ID is the CMDB archive rule ID). Archived records are stored in the Now Platform® archive tables, which are prefixed by 'ar_'. In a similar way, the first time that a CMDB archive job runs, it creates an archive table for each CMDB class (prefixed by 'ar_cmdb'). Therefore, that initial CMDB archive task takes longer than subsequent CMDB archive tasks.

For each Data Manager archive policy, the system batches the policy CIs to be archived into batches of 1000 CIs. The sys_archive_run_chunk table contains a record per each of those batches.

CMDB archive tables, such as ar_cmdb_ci_computer, are listed under All > System Archiving > Archive Tables .

When using the CMDB Data Manager to archive CIs, you can also directly apply Now Platform® data archiving features, such as restoring archived records during a CIs retention period.

Life cycle state rules and retirement definitions Life-cycle rules define the retirement state for classes in your organization and support the transition of CIs through life cycle stages when using the CMDB Data Manager. After retiring CIs, CMDB Data Manager configures the retired CIs according to the retirement definitions specified by life-cycle rules for the CIs class. Using a Retire, Archive, or Delete CMDB Data Manager policies requires that an active life-cycle rule exist for each targeted class in the policy. You can activate life-cycle rules in the base system to apply the default definitions, customize those rules, or add life-cycle rules for classes needed in your organization.

The life cycle state of a CI affects the CIs visibility and inclusion in on-going CMDB processes: A retired CI isn't excluded from any views or processes such as CMDB Health. An archived CI no longer exists in its active table and instead it's stored in a separate archive table. Archived CIs are no longer visible or included in processes such as list views, maps, and relations formatters. Archived CIs can be retained for a specified retention period before being deleted from the archive table. During that retention period, archived CIs can be manually restored into an active state by using the Now Platform® feature to restore archived records . A deleted CI no longer exists in the table that it belonged to and there's no way to restore it into an active state. Deleting a CI is an irreversible operation.

For more information about accessing and managing life-cycle rules, see <a class="xref" href="life-cycle-rules.html" title="Use a life-cycle rule to specify the retirement definition for a class, reflecting processes and protocols in your organization. These rules support the transition of CIs through life-cycle stages as implemented by CMDB Data Manager policies. A life-cycle rule is required for each targeted class in a Retire, Archive, or Delete CMDB Data Manager policy.">Life-cycle rules and retirement definitions .

Configure the environment for CMDB Data Manager Prepare your environment for using the CMDB Data Manager: Some policy types such as the life cycle policies Retire, Archive, and Delete, require that an active <a class="xref" href="life-cycle-rules.html" title="Use a life-cycle rule to specify the retirement definition for a class, reflecting processes and protocols in your organization. These rules support the transition of CIs through life-cycle stages as implemented by CMDB Data Manager policies. A life-cycle rule is required for each targeted class in a Retire, Archive, or Delete CMDB Data Manager policy.">life cycle rule exists for each targeted class in the policy. This requirement doesn't apply to all policy types. For example, this requirement doesn't apply to the Attestation policy type. If you attempt to create a policy of a policy type for which this requirement applies but isn't met, an error message appears and the operation fails. You can streamline approval of policies by populating the Manage by Group attribute of CIs that you plan to target in policies. Use the CI Class Manager to populate that attribute for an entire class, in a single synchronization operation. For more information about this data synchronization, see Set the group for a CI or an entire class of CIs . If the Managed by Group attribute isn't populated for a CI, then the approval process is directed to the administrator.

CMDB Data Manager experience in CMDB Workspace You can use the CMDB Workspace landing page and its views to access high-level metrics and details of CMDB Data Manager tasks. For example: Use the Important actions tile on the landing page to access data attestation and life cycle approval tasks such as reassignment requests and unassigned overdue tasks. Drill down these task cards to see further details about the tasks. Use the My work tile on the landing page to access all open attestation tasks that are assigned to you, or to the group assigned in the Managed by Group attribute and which you're a member of. Review and process these attestation tasks by checking the physical existence of IT infrastructure or applications associated with the CIs in the tasks. Use the Governance view to access attestation tasks that are assigned to you or to an assignment group that you belong to in accordance with CMDB Data Manager Attestation policies. Overdue tasks appear in a separated Overdue tasks list. For information about reviewing and processing attestation tasks, see Review CMDB Data Manager Attestation tasks .

To access the Governance view, navigate to Workspaces > CMDB Workspace and then select Governance in the CMDB Workspace menu bar. Access requires the sn_cmdb_admin (CMDB Admin), sn_cmdb_editor (CMDB Editor), or sn_cmdb_user (CMDB User) role.

CMDB Data Manager