Summary of changes to the Common Data Model
Changes to BMC Helix CMDB 23.3.04 Common Data Model
The following attributes and classes are added to the CMDB Common Data Model, primarily to support the service impact-related activities in BMC Helix NetOps.
Attributes added to the BMC_BaseElement class
The following attributes are added to the BMC_BaseElement class:
Class | Attribute | Description | Data type | Required? | Hidden? |
|---|---|---|---|---|---|
BMC_BaseElement | ImpactStatus | Stores the CI's current impact status. When running an impact analysis, it is necessary to understand if this CI is already impacted by another ITSM ticket. You can set this attribute value either manually or through impact analysis in BMC Helix NetOps. This attribute supports the following values:
| Integer | N | N |
BMC_BaseElement | RPLTargetName | Specifies an arbitrary name for a target when calculating ring networks in impact analysis. This ring network determines if a CI has a route available to another CI or services that the CI is running. This attribute supports the following values:
| Character | N | N |
Attributes added to the BMC_BaseRelationship class
The following attributes are added under the BMC_BaseRelationship class:
Class | Attribute | Description | Data type | Required? | Hidden? |
|---|---|---|---|---|---|
BMC_BaseRelationship | Resilient | Flags a relationship as part of a resilient group. When this attribute's value is 1 (Yes), all resilient relationships with the same destination ID will use the same resiliency calculation to determine the impact weight. A value of 0 indicates that the relationship is not part of a resilient group. This attribute supports the following values:
| Integer | N | N |
BMC_BaseRelationship | ImpactReporting | Holds the threshold value for onward reporting of an impact. This value determines whether the next CI in the hierarchy is impacted. When an impact tree is being evaluated to calculate whether the impact is carried forward in the hierarchy, the impact chain ends when the impact weight does not exceed the threshold value. This attribute supports the following values:
| Selection | N | N |
BMC_BaseRelationship | RPLReachableName | Specifies the value that is used in calculating ring networks during impact analysis. During impact analysis, the ring impacts are assessed based on the RPLReachableName attribute value and the RPLTargetName attribute value. When the RPLReachableName attribute value is the same as the destination instance's RPLTargetName attribute value, the impact is considered to propagate from source to destination. This attribute supports the following values:
| Character | N | N |
Classes added to the 23.3.04 Common Data Model
The following classes and attributes are added to the 23.3.04 Common Data Model:
Parent Class | Class | Sub-class | Sub-class | Description | Class type type | Required? | Hidden? |
|---|---|---|---|---|---|---|---|
BMC_BaseElement | BMC_Service | This class is the base class for defining the service hierarchy. All services are related to products or resources. | Regular | N | N | ||
BMC_CustomerFacingService | This class defines the properties of a customer-facing service. For example, a VPN is a customer-facing service, but the sub-services that perform different types of routing between network devices that make up the VPN are examples of resource-facing services. | Categorization | N | N | |||
BMC_ResourceFacingService | This class is an abstract class for resource-facing services. The class defines the characteristics of particular services that support the network or infrastructure part of the service. Resource-facing services are internal technical solutions required to support a customer-facing service. For example, a VPN is an example of a customer-facing service. This particular type of VPN may require a Border Gateway Protocol (BGP) to support it. BGP is an example of a resource-facing service. | Categorization | Y | N | |||
BMC_Resource | This class defines the attributes that fit any of the following descriptions:
| Regular | N | N | |||
BMC_PhysicalResource | This class is an abstract base class for describing the different types of hardware that constitute a product. This class has the following purposes:
| Categorization | N | N | |||
BMC_PhysicalLink | This class is a non-abstract class that represents the connections between hardware entities. This class enables the modeling of wireless and connector-based communication. | Categorization | N | N | |||
BMC_LogicalResource | This class is an abstract base class for describing different logical aspects of devices, such as device interfaces (DeviceInterfaces) that constitute a product. This class has the following purposes:
| Categorization | N | N | |||
BMC_NetworkAddress | This class represents the generic concept of a network address. Its subclasses define different types of addresses for different technologies. It serves as a convenient point for sourcing and terminating relationships, eliminating undue duplication of relationships that interact with the subclasses of NetworkAddress. | Categorization | N | N | |||
BMC_Protocol | This class is an abstract base class for representing protocols that can be managed. This class represents a convenient aggregation point for defining how protocols are managed and used. | Categorization | N | N | |||
BMC_TopologicalLink | This class represents a communication relationship between network entities and indicates the information intended to flow between those network entities. This class always represents a logical relationship. | Categorization | N | N |
Changes to BMC Helix CMDB 23.3 Common Data Model
The following attributes are added to the BaseElement class:
Class | Attribute | Description | Data type | Required? | Hidden? |
|---|---|---|---|---|---|
BMC_BaseElement |
| BMC Helix Discovery regularly updates the end-of-support and end-of-life data for CIs within BMC Helix Discovery. This information is populated in the BMC ADDM dataset in BMC Helix CMDB. In BMC Helix CMDB, the out-of-the-box reconciliation jobs are configured to map the BMC Helix Discovery attributes to these end-of-support and end-of-life attributes. After the BMC ASSET dataset is updated with this information, the consuming BMC Helix ITSM applications such as Asset Management can use this information. Additional attribute details are provided in the following list:
| Date/Time | N | N |
For more information about how these attributes are captured in BMC Helix Discovery, see Viewing a host and OS Support Detail page.
Changes to BMC Helix CMDB 22.1 Common Data Model
There were no changes to the Common Data Model in this version.
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:
Class | Attribute | Description | Data type | Required? | Hidden? |
|---|---|---|---|---|---|
BMC_BaseElement | CloudId | Cloud providers assign a unique identification number to each cloud resource. BMC Discovery maps all the unique IDs of cloud providers to the CloudId attribute and passes this information to CMDB. For example, the cloud provider AWS uses Amazon Resource Name (ARN) to identify all the AWS resources. The CloudId attribute stores the unique ARN for all AWS cloud resources, and the equivalent unique identification values for other cloud providers. Additional attribute details are provided in the following list:
| Character | N | N |
Changes to BMC Helix CMDB 21.05 Common Data Model
There were no changes to the Common Data Model from versions 20.08 to 21.05.
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:
Class | Attribute | Description | Data type | Required? | Hidden? |
|---|---|---|---|---|---|
BMC_BaseElement | UnstructuredData | This attribute is used within CMDBto add and store data about CIs that do not conform to Common Data Model definitions. A CI does not conform to Common Data Model definitions when the data source is not capable of transforming the data or when the format of the data needs to be stored or consumed in an alternate format like JSON. You can use this attribute with structured data to represent a CI. | Character | N | N |
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
- Access the utility.
- 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:
Class | Attribute | Description | Data type | Required? | Hidden? |
|---|---|---|---|---|---|
BMC_BaseElement | ComponentAliases | Is used within CMDB to pass information to the TrueSight Operations Manager tool. BMC Discovery populates this attribute but other discovery sources can also populate this attribute. Note: If the ComponentAliases attribute does not exist in an earlier version, and you upgrade from earlier versions of CMDB to version 19.11, the upgrade process adds the attribute along with the description. But, if this attribute already exists, and you upgrade to CMDB version 19.11, you must add the description of the attribute in the Description field of Class Manager manually. | Character | N | N |
BMC_BaseElement | InstanceName | Indicates a specific instance of a configuration item (CI). For example, if you have a database with various listeners, each DB instance has an InstanceName attribute that indicates the specific DB instance. For a PostgreSQL server, the InstanceName attribute refers to the port number of the PostgreSQL instance. You can use this attribute not only for database servers but also for any class where a specific instance exists. For example, you can use this attribute to indicate specific instances that run in a common server in BMC_VirtualSystemEnabler and BMC_SoftwareServer classes. | Character | N | N |
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:
Class | Attribute | Attribute ID in CMDB 19.11 |
|---|---|---|
BMC_ElementLocation | Floor | OAGAA5V0GOT7HAP6E6UJP6E6UJATIX |
BMC_ElementLocation | Rack | OAGAA5V0GOT7HAP6E6UJP6E6UJATIW |
BMC_ElementLocation | Shelf | OAGAA5V0GOT7HAP6E6UJP6E6UJATIV |
BMC_ElementLocation | Room | OAGAA5V0GOT7HAP6E6UJP6E6UJATIY |
BMC_BaseRelationship | CostApportionment | OAGAA5V0GOT7HAP6E4UTP6E4UTATIU |
BMC_BaseRelationship | CostFlow | OAGAA5V0GOT7HAP6E32XP6E32XATIT |
BMC_BaseRelationship | Pillar | OAGAA5V0H39N2APS8VYZPS8VYZ5091 |
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.
Class | Attribute | Description | Required? | Hidden? | Possible Values | Default Value |
|---|---|---|---|---|---|---|
BMC_BaseElement | isVirtual | Specifies whether the system is virtual or physical. | N | N | No, Yes | No |
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 information about post-upgrade issues with the isVirtual attribute, see 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.
Class | Attribute | Description | Type | Required? | Hidden? | Default Value |
|---|---|---|---|---|---|---|
BMC_ElementLocation | Pillar | Pillar where the CI is located | Char (255) | N | N | Null |
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.
Class | Attribute | Description | Type | Required? | Hidden? | Default Value |
|---|---|---|---|---|---|---|
BMC_Tag | TagName | Attribute to store name of a given tag . Example: Calbro_HR.Costcenter | Char (255) | N | N | Null |
BMC_Tag | TagValue | Attribute to store the value of a tag. Example : Calbro_HR.Costcenter="102" | Char (255) | N | N | Null |
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.
Class | Description |
|---|---|
BMC_RelatedTo | Used to relate CIs where no impact or true dependency exists. RelatedTo allows any class of CI to be related to a CI of any other class. This relationship has no direction, cardinality, or end point rules. |
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.
Class | Attribute | Description | Required? | Hidden? | Possible Values | Default Value |
|---|---|---|---|---|---|---|
BMC_BaseRelationship | IsDR | If the value of this attribute is set to Yes, it indicates that the source CI and destination CI are related to each other for the purpose of disaster recovery. The direction for this attribute is from source to target. | N | N | Yes, No | No |
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.
Class | Attribute | Description | Type | Required? | Hidden? | Default Value |
|---|---|---|---|---|---|---|
BMC_ElementLocation | Floor | Floor where CI is located | Char (256) | N | N | Null |
BMC_ElementLocation | Room | Room where CI is located | Char (256) | N | N | Null |
BMC_ElementLocation | Rack | Rack where CI is located | Char (256) | N | N | Null |
BMC_ElementLocation | Shelf | Shelf where CI is located | Char (256) | N | N | Null |
The following short video shows the steps to add location attributes to a relationship.
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:
Class | Attribute | Description | Hidden? | Needs Change in CDM diagram |
|---|---|---|---|---|
BMC.CORE:BMC_BaseElement BMC.CORE:BMC_BaseRelationship | NormalizationStatus | NormalizationStatus attribute was changed from hidden to non-hidden | N | Yes |
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.
Class | Attribute | Description | Value | Needs Change in CDM diagram |
|---|---|---|---|---|
BMC.CORE:BMC_ComputerSystem | Primary Capability | Added new Enum Items ( Access Point Wireless LAN Controller ) | Access Point Wireless LAN Controller | No |
BMC.CORE:BMC_ComputerSystem | ReconciliationIdentificationError | Added new Enum Item | Error | No |
BMC.CORE:BMC_ComputerSystem | ReconciliationIdentificationError | ReconciliationIdentificationError attribute was added on some classes as attribute and on some only as a field. This was rectified for all non-federated root classes this was added as an attribute. | Yes |