Summary of changes to the Common Data Model

This topic lists the changes that were made to the Common Data Model.

Changes to the BMC CMDB 19.08 Common Data Model

This section lists the changes to Common Data Model for version 19.08 of BMC CMDB.

isVirtual attribute is moved to BMC_BaseElement class

In earlier releases of BMC CMDB, the isVirtual attribute was included within BMC_System, BMC_SystemComponent, and BMC_Collection classes. In version 19.08, a new isVirtual attribute is added to the BMC_BaseElement class to enable any device (CI) to be represented logically rather than as a physical entity. The existing attribute on all the three classes, BMC_System, BMC_SystemComponent, and BMC_Collection has been renamed to isVirtual_old. The data that is stored in isVirtual_old attribute is maintained as it is.

Adding the isVirtual attribute

For new installations

For new installations of BMC CMDB, the isVirtual attribute is available within the BMC_BaseElement class.

Upgrade scenarios

If you upgrade from earlier versions of CMDB to CMDB version 19.08, during upgrade, the existing attribute is renamed to isVirtual_old on all the three classes. Subsequently, the new attribute isVirtual is added to the BaseElement class. If this upgrade process fails while renaming the existing attribute and creating a new attribute, due to various reasons, for example, if the user has already renamed the attribute to a customized name, or has added another new attribute for isVirtual, the upgrade remains in a 'Pending' state and you must fix the issues manually.

For information about post-upgrade issues with the isVirtual attribute, see  Other BMC CMDB upgrade issues .

For more information about installer issues, see  Troubleshooting installer failure during upgrade .

For Field IDs

In CMDB version 19.08, this attribute is available in the BaseElement class with a new field ID, which is 530075026. If you have any client applications or reports that use the existing field ID (530054200) for this attribute, you must change it to the new field ID.

For ADDM data sources

If data is populated to the isVirtual attribute using ADDM, we recommend that you do a full sync from ADDM to populate the values in the new attribute. If you want any values from the old attribute to be populated into the new attribute, you must migrate the values by creating an AI job and use the job to perform the migration task.

For AI or UDM data sources

If data is discovered using an Atrium Integrator job or UDM, those jobs must be modified to populate the attribute and rerun. If the attribute is referred from BMC_System class or BMC_Collection class, then the mapping has to be updated such that instead of BMC_System, BMC_Collection classes, the class name should now refer to the BMC_BaseElement class.

For Precedence rules for reconciliation merge activities

Manually update precedence rules that use the IsVirtual_old attribute with the new isVirtual attribute.

For more information about creating precedence sets for reconciliation merge activities, see  Creating precedence sets and associations for reconciliation merge activities.

Added the Pillar attribute to Location Relationships

Datacenters and facilities management applications and floor plans often reference ‘Pillars’ for locations. The Pillar attribute enables the CMDB administrator to store the pillar location as part of the relationship between a CI and its location.

Added the TagName and TagValue attributes to Tag class

TagName and TagValue are attributes defined specifically for cloud instances to store descriptors of cloud services.  Tagging is useful for tracking resources related to cloud services for aggregating or creating reports, or for taking bulk actions on these resources. Tagging enables you to define keys and values and associate them with resources. 

For example, Calbro Software has several departments, and within each department there are several cost centers. Calbro Software creates tags for each of these cost centers to track resource usage and costs associated with it. 

When BMC Discovery discovers these cloud services, it splits the descriptors into key-value pairs, and stores each key inside a tag class. The administrator can then create a relationship (RelatedTo) between the tag and the cloud service that is discovered with it. This relationship is not necessarily a Dependency type of relationship. 

Created a new generic RelatedTo relationship

The BMC CMDB common data model contains several relationship types with their own required attributes, cardinality rules, and other elements. With the introduction of TagName and TagValue attributes for CIs that are related to cloud instances, a new generic relationship class ‘RelatedTo’ has been introduced that enables you to define relationships between CIs of different classes. However, it does not indicate a dependency between those CIs. It is also important to note that RelatedTo is is purely informational in nature and is not evaluated as part of Impact or any other processing.

Added the isDR attribute to BMC_BaseRelationship to represent disaster recovery

The IsDR attribute available on BaseRelationship is used to indicate that a relationship with this attribute set to Yes, provides Disaster Recovery (DR) capability to the source. The source CI provides DR capability to the target CI.

Changes to the BMC CMDB 19.02 Common Data Model

This section lists the changes to Common Data Model for version 19.02 of BMC CMDB.

Added location attributes on relationships

New attributes have been added to location relationships to allow specific and detailed information to be stored for locations. For example, for Location CI called 'Datacentre Denver', a CI related to 'Datacentre Denver' can have attributes for elements such as floor, row, rack, shelf that are defined as part of the relationship.

The following short video shows the steps to add location attributes to a relationship.

 https://youtu.be/zQRzqNKNIjc

Added new attributes for Cost Modelling

You can now use the following new attributes in the BMC_BaseRelationship class to allow for cost modeling: 

• CostFlow —The CostFlow attribute enables you identify the directional flow of cost whether it flows upstream or downstream or is NULL.
• CostApportionment —The CostApportionment attribute enables you to identify the percentage of source CI cost that is to be shared by the related item or service.

Example:
Server A hosts two services- Service 1 and Service 2. If Server A is related to the two services, the CostFlow on the relationships is set to Upstream and the CostApportionment is set to 50 to show that the upstream Service 1 and 2 contribute to the cost of Server A equally.

Changes to the BMC CMDB 18.08 Common Data Model

There were no changes to the 18.08 Common Data Model.

Changes to the BMC CMDB 18.05 Common Data Model

The following changes were made to the Common Data Model:

Changes to the BMC CMDB 9.1.04 Common Data Model

The following changes were made to the Common Data Model.

New enum were added to the attributes.