CMDB synchronization

CMDB synchronization provides a configurable mechanism to keep data in the BMC Atrium CMDB (CMDB) synchronized with information discovered by BMC Atrium Discovery.

Starting from Technology Knowledge Update 2014-Jul-1, the CMDB sync mappings have been enhanced with two new capabilities:

Support for HasImpact population

Relationships in Atrium CMDB can be marked as being “impactful”, by setting the HasImpact attribute to Yes and the ImpactDirection attribute to a suitable value. A new CMDB sync data model means that BMC Atrium Discovery can now set these impact attributes directly, rather than relying on Atrium CMDB’s impact normalization rules. To enable the new data model:

  1. In Atrium CMDB, disable Impact Normalization for the ADDM dataset, in the Normalization Console Configuration Editor.
  2. When adding or editing a connection in BMC Atrium Discovery, ensure the Data Model setting labelled "CMDB 7.6.03 and later (with impact attributes)" is selected (this is the default).

This new data model will become the default in future releases of BMC Atrium Discovery.

Simple static application models

BMC Atrium Discovery allows you define dynamic automatically-updating application models, using Collaborative Application Mapping and related features. That leads to robust comprehensive application models, but it does require time to investigate the application and define a suitable set of patterns. In some circumstances it is useful simply to manually group some hosts or software instances together to create a “static” application model. Such models are of course not automatically updated, but they are extremely quick and easy to define.

To define a static application model, add Hosts or SoftwareInstances to a group in BMC Atrium Discovery, and give the group a name that starts with “StaticApp:”, in exactly that form. Do not use sub-groups. That causes the creation of a BMC_Application CI in Atrium CMDB, named after the group. For example, a group named “StaticApp: Example Application” results in a BMC_Application CI with name “Example Application”.

Data model mapping

The BMC Atrium Discovery data model (Discovery model) is different from the Common Data Model (CDM) used in the CMDB, so the synchronization mechanism is responsible for transforming the required information from one data model to the other. The Discovery model is known as the source model, and the CDM is referred to as the target model.

Both models are graph models, meaning that they represent data as nodes connected to each other with relationships. Synchronization operates on portions of the full graph known as subgraphs. A subgraph contains a root node (such as a host computer), plus all the related nodes that belong to it (such as interface information, software information, and so on), referred to as its components. Some nodes can be shared, meaning that they belong to more than one subgraph. For example, the node representing a subnet is shared by all the host computers on that subnet.

The mapping between the Discovery model and the CDM is defined in syncmapping definitions within TPL files.

The Default CDM Mapping provides a comprehensive mapping from the Discovery model to a best-practices CDM model. If you have added custom nodes to Discovery they are not exported automatically by the default CDM mapping, instead, you will have to create additional mapping definitions within TPL files.

Supported CMDB versions

At the time of its release, integration of BMC Atrium Discovery 10.1 is supported with the following versions of BMC Atrium CMDB:

  • 9.1
  • 9.0
  • 8.1.02
  • 8.1.01
  • 8.1.00
  • 8.0.00
  • 7.6.04

For more information, check the BMC Solution and Product Availability and Compatibility utility (SPAC) (support login required).

Deprecated versions of CMDB synchronization

BMC Atrium Discovery version 8.1 introduced the first automatic integration using CMDB synchronization. At that time the previously used method (the Atrium CMDB adapter) was deprecated. In BMC Atrium Discovery 9.0, the Atrium CMDB adapter was removed.

Synchronization stages

Synchronization occurs in the following stages:

  1. root source node is chosen for synchronization. The root node kinds are Host, NetworkDevice, MFPart, Printer and, SNMPManagedDevice corresponding to the main kinds of device that can be discovered. The list of possible root nodes is fixed and cannot be altered in the Syncmappings.
  2. The source subgraph is populated by retrieving all the relevant data from the Discovery datastore.
  3. The source subgraph is transformed into a target subgraph, centered around a target root node.
  4. The target subgraph is compared with the corresponding subgraph stored in the CMDB.
  5. The CMDB is updated (by creating, updating and (soft) deleting CIs and relationships) so that the stored subgraph matches the target subgraph.


If any changes are made to the CDM (for example, adding attributes), you cannot synchronize to those attributes until the Tideway service has been restarted. After the tideway service starts, the CDM is read and all customized classes and attributes are available for CMDB synchronization.

Initial configuration

The following steps are required to set up CMDB synchronization:

To perform synchronization

Synchronization can be configured to run in a continuous mode, meaning that as soon as BMC Atrium Discovery completes its scan of a device, the data corresponding to it is queued for synchronization with the CMDB. Alternatively, synchronization can be launched manually for one or more devices from within the browsing interface.

To prevent synchronization at certain times

Typically, synchronization can occur at any time. However, synchronization can place a substantial load on the CMDB, so it might be necessary to prevent synchronization from occurring at times the CMDB will be used heavily. This can be achieved by configuring Configuring CMDB Sync blackout windows.

To filter synchronization data

By default, all details about all devices are synchronized to the CMDB. In some situations, it might be useful to only synchronize a subset of the data. After each of the first three synchronization stages, the data can be filtered to affect the data that finally reaches the CMDB.

  1. Filtering the root device node
  2. Filtering the synchronized components
  3. Filtering the CMDB CI classes

Root node deletion synchronization failure

When a non-fatal error occurs during synchronization with the CMDB, the root node is re-queued so the synchronization is attempted again. A root node is re-queued up to three times if it fails repeatedly, then synchronization is not attempted again. When the outage is resolved, subsequent discovery runs trigger continous synchronization and re-submit root node creations and updates. Deletions however are not automatically re-submitted, leading to orphaned graphs in CMDB dataset.

Manual Workaround

To synchronize a selection of the missed deletions, run the report “Aged-out Hosts and other devices that failed last CMDB sync”, found in the main Reports page. Select one or more nodes from the list, and choose Actions > Sync to CMDB.

Was this page helpful? Yes No Submitting... Thank you