Summary of changes to the Common Data Model

Changes to BMC Helix CMDB 21.3 Common Data Model

CloudId attribute added to the BaseElement class

The details of the attributes are as given in the following table:

Changes to BMC Helix CMDB 21.05 Common Data Model

There were no changes to the Common Data Model from versions 20.08 and later.

Changes to 

BMC Helix CMDB

 20.02 Common Data Model

UnstructuredData attribute added to the BaseElement class

The details of the attributes are as given in the following table:

Changes to ComponentAliases attribute

In versions earlier than 20.02, the maximum length of the ComponentAliases attribute was 0. In this release, the maximum length of this attribute is changed to 512 for new installations only. If you upgrade to CMDB version 20.02, the maximum length still remains as 0.

While upgrading to BMC Helix CMDB 20.02, to change the maximum length of the attribute to 512, you must run a utility that changes the input length of the ComponentAliases attribute from 0 to 512. For the changes to take effect, you must perform a resync from your source data, such as BMC Discovery, SCCM, Atrium Integrator, or any external databases or files.

Perform the following steps to run the utility

1. Access the utility.
2. Run the following script: 
   ${JAVA_HOME}/bin/java -jar $SDIR/cdmchanges-9.1.10-SNAPSHOT.jar $ENCRYPTED_RAS_PASSWORD $AR_SERVER_CONNECT_NAME $AR_SERVER_PORT

Changes to BMC Helix CMDB 19.11 Common Data Model

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

ComponentAliases and InstanceName attributes are added to the BaseElement class

The details of the attributes are as given in the following table:

Change in attribute IDs for some attributes

Attribute IDs for Floor, Rack, Shelf, Room, Pillar, CostApportionment, and CostFlow attributes have changed. If you have used any of these attribute IDs for performing any customization, or have referred to the ID in any client program, then you must update these IDs with new attribute IDs. 

The following table lists the attribute IDs in CMDB version 19.11:

Changes to BMC Helix CMDB 19.08 Common Data Model

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

isVirtual attribute is moved to BMC_BaseElement class

In earlier days, only systems could be virtualized, because of which the isVirtual tag was included within BMC_System, BMC_SystemComponent, and BMC_Collection classes. But nowadays, almost any device can be virtualized. 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 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 Helix 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.

After upgrading, move the data associated with isVirtual_old attribute to isVirtual attribute by using the isVirtual Mapper utility. See Moving-data-from-isVirtual_old-attribute-to-isVirtual-attribute.

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 Helix 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 BMC Helix CMDB 19.02 Common Data Model

This section lists the changes to Common Data Model for version 19.02 of BMC Helix 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 BMC Helix CMDB 18.08 Common Data Model

There were no changes to the 18.08 Common Data Model.

Changes to BMC Helix CMDB 18.05 Common Data Model

The following changes were made to the Common Data Model:

Changes to BMC Helix CMDB 9.1.04 Common Data Model

The following changes were made to the Common Data Model.

New enum were added to the attributes.