Default CDM Mapping
Root node kind mappings
Each root node kind in the Discovery model is mapped to the Common Data Model (CDM) as follows:
- CDM Mapping for Host
- CDM Mapping for MFPart
- CDM Mapping for Network Device
- CDM Mapping for Printer
- CDM Mapping for SNMP Managed Device
- CDM Mapping for Storage
- CDM Mapping for Cloud
Restart the Tideway service after making changes to class definitions
If any changes are made to the class definitions in the CMDB, for example, adding attributes or whole new classes, you cannot sync to them until BMC Discovery has been restarted. On restart of Discovery, the class definitions are read and all customized classes and attributes are available to CMDB sync.
Extending and modifying the standard mappings
If you need to extend or modify the standard mappings, it is best to do so with extension mappings, rather than by editing the standard mappings. Extension mappings are able to create new CIs and relationships, set additional CI attributes, and change the standard values of existing CI attributes. The standard mappings should only be edited as a last resort, if the mapped structure needs to be different. See the Pattern templates for examples.
ADDMIntegrationId
So that Discovery can correctly maintain the CIs it creates in its dataset, it stores a unique key on every CI, in the ADDMIntegrationId
attribute. These keys are sometimes directly populated from the key on a corresponding node in the BMC Discovery datastore, but in other situations they are constructed by using rules that are appropriate for the mapping structure. See the syncmapping definitions for details of how keys are populated.
Company attribute
If the CMDB is configured for multitenancy, all CIs can have a Company
attribute set appropriately. See Multitenancy for details.
Impact relationships
One of the main features of BMC Atrium CMDB is to indicate the way that one CI impacts another. Versions of BMC Atrium CMDB prior to 7.6.03 represent impact using a specific relationship, BMC_Impact. With those CMDB versions, BMC Discovery is responsible for creating and maintaining the BMC_Impact relationships. In modern CMDB versions, the BMC_Impact relationship has been deprecated, and impact is now indicated with the HasImpact
attribute on all other relationship classes.
In BMC Discovery you can no longer specify the "CMDB 7.6.03 and later with Impact relationships" data model from the UI. The only situation in which "CMDB 7.6.03 and later with Impact relationships" data model is required is with BMC Service Impact Manager (SIM) version 7.4. Ideally you should upgrade to a current version of BMC Proactive Performance Manager. If you must use SIM 7.4, contact Customer Support for advice.
SIM version 7.4 is incompatible with the representation of impact as an attribute, so if SIM is used with CMDB version 7.6.03 or later, Discovery must be configured with the "CMDB 7.6.03 and later with Impact relationships" data model. In that case, Discovery will ask the CMDB to create BMC_Impact relationships, but the deprecation mechanism will translate them into BMC_BaseRelationship
instances with the Name
"ImpactOnly". If you view such a relationship in Atrium Explorer, it will display as a BMC_BaseRelationship
with HasImpact
set to "Yes". However, the deprecation mechanism means that it is still possible to find the relationships as BMC_Impact by using the CMDB API or by using the BMC.CORE:BMC_Impact form. This complicated situation only applies to BMC Service Impact Manager version 7.4 and earlier, not to the SIM functionality built into later versions of BMC Proactive Performance Manager.
Comments
Log in or register to comment.