CDM Mapping for Cloud

This topic provides information about mapping for cloud nodes. The CIs created are described in this topic.

Data models

Note

The default mapping works with CMDB versions 7.5, 7.6, and 7.6.03 and later. The data model in each is slightly different.

BMC_Impact relationships are not normally created with CMDB 7.6.03 and later, since the CMDB automatically maintains them itself. See the information about impact relationships for more details.

Click here for reference information on impact and the data models.

Different versions of the CMDB have subtly different data models. Syncmappings can support multiple data models with datamodel declarations. CMDB data models are assigned simple integer values:

The mappings performed during CMDB-synchronization are specified in syncmapping blocks in TPL. A syncmapping is similar to a pattern, but it triggers from a queued synchronization action, rather than from data being updated in the data store.

The form of a syncmapping is:

syncmapping name version
description
overview
   overview_entries
end overview;
[constants
   constant_definitions
end constants;]
mapping mapping_source as source_name
   mapping_definitions
end mapping;
body
   body_details
end body;
end syncmapping;

As with pattern blocks, the name, version, and description are mandatory.

Pattern-templates are provided to help you create your own syncmappings.

Overview section

The overview is required. It contains information about the pattern and the entities it creates. It must contain a tags entry, and can have an optional datamodel entry, as described in Data models.

The overview section can also have an optional overrides entry, which enables you to change the behavior of an existing mapping and to preserve those changes on subsequent TKU updates to the overridden mapping. Non-syncmapping patterns have an "overridden" flag displayed on the pattern management page, syncmappings do not.

Here is an excerpt from an overriding mapping:

...
*from* CMDB.Host_ComputerSystem *import* Host_ComputerSystem 1.2;
*from* CMDB.SoftwareInstance_SoftwareServer *import* SoftwareInstance_SoftwareServer 3.2;
// The mapping referred to by the overrides keyword must be imported

*syncmapping* SoftwareInstance_SoftwareServer_override 3.2
   """
   Example override mapping.
   """
   *overview*
       *tags* CMDB, Core_Mapping;
       *datamodel* 0, 1, 2, 3, 4, 5, 6;
       *overrides* SoftwareInstance_SoftwareServer; // The overridden pattern is imported above
   *end* *overview*;

   *mapping* *from* Host_ComputerSystem.host *as* host
       *traverse* Host:HostedSoftware::SoftwareInstance *as* si_node

           *traverse* Element:Maintainer:Pattern:Pattern *as* si_pattern
           *end* *traverse*;
...

Note

The mapping referred to by the overrides keyword must be imported. All definitions from the original mapping section such as node kinds, traversals and names must be preserved. It is possible to add additional traversals and names in the overriding mapping.

Mapping section

The mapping section declares the starting point for the mapping, the structure of source data retrieved from the Discovery model, and the target CIs created in the CMDB model. It does not describe how the source data is transformed to the target model — that is performed in the body section.

Mapping source

Each mapping is either a root mapping, meaning that it is invoked by the synchronization of a single root node with the corresponding kind, or an extension mapping, meaning that it extends another mapping at a suitable point.

You should not use DDD directly in mappings, rather, you should copy the required DDD into the inferred model first.

Root mappings have a mapping declaration using the on keyword:

*mapping* *on* _node_kind_ *as* _name_
_mapping content..._
*end* *mapping*

For example, this specifies the root mapping for Host nodes:

*mapping* *on* Host *as* host_node

Extension mappings have a mapping declaration using the from keyword:

*mapping* *from* _source_scoped_name_ *as* _name_

For example:

*mapping* *from* ExampleMapping.host_node *as* host_node

The source_scoped_name is the name of a source mapping variable from another mapping block, either the source name specified in the mapping declaration, or a traversal name as described below.

Multiple "From" expressions in the mappings block

Multiple parent mappings are supported, by using more than one "From" expression in the mapping block, for example:

SoftwareInstance_SoftwareServer 4.0
...
mapping from Host_ComputerSystem.host from Cluster.cluster as hosting_system
...

In this example the mapping input can be from a Host or a Cluster node in the (BMC Discovery model). All of the input parameters used in the mapping statement must have corresponding references in the body. An example in the case of the above mapping statement is:

hosting_ci := Cluster.cluster_ci or Host_ComputerSystem.computersystem;

The hosting system (in the CMDB model) is either a BMC_Cluster or a BMC_ComputerSystem. The order matters here; the interpreter takes the first defined object which it finds (checking from left to right).

Mapping traversals

The source subgraph is declared using traverse clauses inside the mapping with a syntax similar to traversals in search expressions:

*traverse* _traversal_specification_ *as* _nodename_
_traversal contents..._
*end* *traverse*

The nodename defined by the traversal can only be used in a

for each

expression; it cannot be used in any other context.

You can also define a relationship relname for a traverse clause inside the mapping. The first is the name of the relationship and the second is the name of the node.

*traverse* _traversal_specification_ *as* _relname_, _nodename_
_traversal contents..._
*end* *traverse*

In each case the relname and nodename defined by the traversal can only be used in a

for each

expression; they cannot be used in any other context. You can access the attributes on a relationship by using the name you assigned to the relationship followed by a dot and the attribute as specified in the syncmapping.

Where clauses

The initial source node and the results of traversals can be filtered with where clauses, specified before the as token. where clauses in mapping blocks use the same subset of search where clauses as trigger conditions in pattern blocks.

*mapping* *on* _node_kind_ *where* _condition_ *as* _name_

*mapping* *from* _source_scoped_name_ *where* _condition_ *as* _name_

*traverse* _traversal_specification_ *where* _condition_ *as* _name_

However, you cannot use search in a syncmapping. CMDB synchronization takes a graph of connected nodes in BMC Discovery and transforms them into a graph of connected CIs in the CMDB. If the where clause contains a search there is no guarantee of any such connection.

Target CI declarations

As the subgraph is processed in the body, target CIs are specified. The mapping block contains declarations of the CIs that are mapped, in the form:

_name_ *->* _CI_class_;

For example:

computersystem *->* BMC_ComputerSystem;

Targets are specified within the traversal structure. For example, part of the mapping of virtual machines is as follows:

*mapping* *from* Host_ComputerSystem.host *where* virtual *defined* *as* host
*traverse* ContainedHost:HostContainment:HostContainer:SoftwareInstance *as* vm_si

   vse *->* BMC_VirtualSystemEnabler;

   *traverse* RunningSoftware:HostedSoftware:Host:Host *as* containing_host
     containing_cs *->* BMC_ComputerSystem;
   *end* *traverse*;
*end* *traverse*;
*end* *mapping*;

Grouping

In some circumstances, a number of nodes in the Discovery model must be grouped together to construct a single CI in the CMDB model. This is declared in the mapping with a group block. The form of a group block is

*traverse* _traversal_specification_ *as* _traversal_name_
*group* _group_name_
   _group contents..._
   *expand* *group* *as* _expansion_name_
     _expansion contents..._
   *end* *expand*;
*end* *group*;
*end* *traverse*;

The declaration indicates that nodes from the containing traversal will be grouped together (according to rules specified in a group block in the body), and then the group will be expanded to the individual group members. The expand is not required if there is no need to process the individual nodes within the group.

Syncmapping body

The body of a syncmapping is responsible for implementing the mapping described in the mapping block. The majority of language features and functions available in pattern body blocks are permitted, except that functions in the following namespaces are not available since they are only appropriate for patterns that perform discovery and construct the Discovery model.

discovery
inference
mail
model

Additionally, user-defined functions are not supported.

Any date/time fields should be passed as datetime objects rather than formatted datetime strings.

Body execution

The body of a syncmapping is executed at a time that depends upon the mapping source definition.

The body of a root mapping (specified with mapping on) is executed at the time the root node is scheduled for synchronization.

The body of an extension mapping (specified with mapping from) that extends the source node of another mapping is executed when the body of the extended mapping completes.

The body of an extension mapping that extends a traversed-to node of another mapping is executed each time the associated for each loop (see below) completes.

When a node in the Discovery data store is marked as destroyed, only the root mapping's body is executed, and the target root CI is scheduled for deletion in the CMDB. When the delete is synchronized with the CMDB, the root CI and all the related CIs previously created by the mapping are deleted. For best performance during deletion, root mappings should not perform any traversals or other time-consuming activities.

CI definition

CIs and relationships in the CMDB are specified with functions in the sync namespace similar to those in the model namespace used within pattern blocks.

Any CMDB class can be specified with a function call of the form

value := sync._BMC_ClassName_(key := _some_key_, _attributes..._);

Any class name can be specified. Specifying a class that is not defined in the CMDB results in a run-time error. The key attribute must be set, and is used to populate the ADDMIntegrationId attribute in the CMDB. Any other attribute name can be set; attributes that are not defined in the CI class are ignored.

The result of the function must be assigned to a target CI name specified in the mapping block. The class specified in the function must be the same as the one specified in the mapping or a subclass of it.

CI class namespaces

CMDB classes are assumed to be in the BMC.CORE namespace. To refer to a class in a different namespace, provide a namespace parameter to the function call:

value := sync._BMC_ClassName_(key := _some_key_, namespace := "My.NameSpace", _attributes..._);

The namespace must be a literal string — it cannot be constructed at runtime.

Shared CIs

The subgraph of data in the Discovery model is transformed into a subgraph of CIs in the target CMDB model. Most of the CIs belong to a single target subgraph, but some are shared by more than one subgraph. An example is the BMC_IPConnectivitySubnet CI that is shared by all the computers on a particular subnet. For deletion to work correctly, the system must know that such CIs are shared. This is achieved by calling the function in the sync.shared namespace:

value := sync.shared._BMC_SharedClassName_(key := _some_key_, _attributes..._);

External CIs

Similarly, it is sometimes necessary to specify a relationship to a CI that is not part of the target subgraph. An example is to relate the BMC_ComputerSystem for a physical host to the one for a virtual host — the two CIs belong to different subgraphs. External CIs are specified with a function in the sync.external namespace:

value := sync.external._BMC_ClassName_(key := _some_key_ _[, namespace := "_NAMESPACE_" ]);

The key must be specified, and namespace must be specified if required. No other attributes can be set.

It is not an error if a CI with the specified key does not exist in the CMDB. In that situation, the CI and any relationships to it are simply ignored.

Cross-reference CIs

As the mapping is processed, the CIs are specified in a tree traversal across the graph. To refer to a CI specified in a different branch of the tree, it can be specified with a function in the sync.crossref namespace:

value := sync.crossref._BMC_ClassName_(key := _some_key_ _[, namespace := "_NAMESPACE_" ]);

The key must be specified, and namespace must be specified if required. No other attributes can be set.

It is a runtime error to specify a cross-reference to a CI that is not fully specified elsewhere within the mapping.

TokenId rules

TokenId is an attribute that, in some circumstances, aids the reconciliation of CIs populated by multiple data sources. BMC Discovery sets TokenId depending on the Node kind.

For most Nodes, TokenId is one of the forms:

key

ADDM:%key%

ADDM:%hashed_key%

For databases, TokenId is a database host found as a result of all possible combinations of where the database might be running:

%hosting_ci.TokenId%:%database_node.type%:%si_instance%:%database_node.instance%

and

%hosting_ci.Name%:%database_node.type%:%si_instance%:%database_node.instance%

For the Fibre Channel Node, TokenId is of the form:

WWN:%wwpn%

For physical hosts, TokenId is of the form:

%host.hostname%:%host.dns_domain%

If the domain name is unavailable, then

%host.hostname%

For virtual hosts that are running in the cloud, TokenId contains instance_id.

For Alibaba, TokenId is of the form:

%alibaba_instance_id%

For Azure, TokenId is of the form:

%azure_vm_id%

For AWS, TokenId is of the form:

%aws_instance_id%

For GCP, TokenId is of the form:

%gce_instance_id%

For IBM, TokenId is of the form:

%instance_id%

For OCI, TokenId is of the form:

%ocid%

For virtual hosts that are running in the hypervisor, TokenId contains UUID.

For AHV, TokenId is of the form:

AHV-UUID:%uuid%

For Hyper-V, the UUID is only available on the physical machine, so TokenId is only set for virtual machines that have been successfully linked to their hosting physical machines:

HYPERV-ID:%vm_uuid%

For KVM (including RedHat Enterprise Virtualization), TokenId is of the form:

KVM-ID:%uuid%

For VMware, TokenId is of the form where each letter represents a hexadecimal digit:

VI-UUID:%uuid%

For Xen (including Oracle VM), TokenId is of the form:

XEN-ID:%uuid%

The following table shows how TokenId looks like for different Node Kinds:

Node Kind	CI	TokenId
AdminCollection	BMC_AdminDomain	key
Cluster (cloud)	BMC_Cluster	key
LoadBalancerService	BMC_LogicalSystemComponent	ADDM:%key%
LoadBalancerPool	BMC_ResourcePool	ADDM:%key%
CloudManagementGroup	BMC_AdminDomain	cloud_id
CloudProvider	BMC_CloudInstance	key
CloudRegion	BMC_CloudInstance	key
CloudService	BMC_CloudInstance	key
Cluster	BMC_Cluster	ADDM:%hashed_key%
Database (cloud)	BMC_DataBase	ADDM:%key%
Database	BMC_DataBase	%hosting_ci.TokenId%:%database_node.type%:%si_instance%:%database_node.instance%
Database	BMC_DataBase	%hosting_ci.Name%:%database_node.type%:%si_instance%:%database_node.instance%
HardwareComponent	BMC_HardwareSystemComponent	ADDM:%hashed_key%
HardwareContainer	BMC_ComputerSystem	ADDM:%hashed_key%
HostContainer	BMC_ComputerSystem	ADDM:%hashed_key%
Host	BMC_ComputerSystem	%host.hostname%:%host.dns_domain%
		%host.hostname%
		ALIBABA-ID:%alibaba_instance_id%
		AWS-ID:%aws_instance_id%
		GCP-ID:%gce_instance_id%
		IBM-ID:%instance_id%
		OCI-ID:%ocid%
		AZURE-ID:%azure_vm_id%
		HYPERV-ID:%vm_uuid%
		XEN-ID:%uuid%
		KVM-UUID:%uuid%
		AHV-UUID:%uuid%
		VI-UUID:%uuid%
LoadBalancerGroup	BMC_Cluster	ADDM:%key%
MFPart	BMC_ComputerSystem	key
Namespace	BMC_AdminDomain	key
Deployment	BMC_ConcreteCollection	key
NetworkService	BMC_LogicalSystemComponent	ADDM:%key%
FibreChannelPort	BMC_NetworkPort	WWN:%wwpn%
SoftwareCluster	BMC_Cluster	ADDM:%hashed_key%
SoftwareComponent	BMC_ApplicationService	ADDM:%hashed_key%
SoftwareInstance	BMC_ApplicationSystem	ADDM:%hashed_key%
SoftwareInstance	BMC_SoftwareServer	ADDM:%hashed_key%
VirtualMachine	BMC_VirtualSystemEnabler	ADDM:%hashed_key%
StorageDevice	BMC_Cluster	ADDM:%key%
StoragePool	BMC_ResourcePool	ADDM:%key%
StorageSystemGroup	BMC_Cluster	ADDM:%key%
StorageProcessor	BMC_HardwarePackage	ADDM:%key%
HardwareContainer	BMC_HardwareSystemComponent	ADDM:%hashed_key%

Relationship definition

Relationships are specified with functions in the sync.rel namespace:

sync.rel._BMC_RelName_(Source := _source_val_,
Destination := _dest_val_,
Name := "_RELNAME_" _[, ... ]_);

The first two parameters must be Source and Destination. Any other attributes can also be set; Name is not required, but it is conventionally always set.

The Impacted and ImpactWeight attributes can be used to create impact relationships. They specify impact direction and percentage respectively. For example, an ImpactWeight of 25 might be appropriate when representing an impact relationship between a BMC_ComputerSystem and BMC_Cluster, where there are four computers in a cluster. The value assigned to Impacted must be the Source or Destination CI appearing in the same definition.

sync.rel.BMC_Component(
   Source       := computersystem,
    Destination := cluster_ci,
    Name         := "CLUSTEREDSYSTEM",
    Impacted     := cluster_ci,
    ImpactWeight := cluster_rel.impact_weight
);

Note that prior to tpl 1.10 multiple relationship definitions were needed to represent a single impact relationship in the CMDB. This was because the way in which impact is represented in the CMDB depends on the data model in effect (see below). In tpl 1.10 and later, only one definition is required.

Traversal looping

One of the main activities performed in the body is to iterate over the nodes reached through the traversals specified in the mapping block. A for each loop is used to iterate over the named nodes:

*for* *each* _source_node_ *do*
...
*end* *for*

The nesting structure of for each loops in the body must match the nesting structure of the traverse expressions in the mapping block.

A for each loop is required even if the corresponding traversal is expected to reach just one node. There is no other way to access the state of the traversed-to node.

Group block

When the mapping block specifies a group, there must be a corresponding group block in the body. The group block will always be inside a for each block, either directly within a single syncmapping body or in an extended source syncmapping.

A group block takes the form:

*for* *each* _traversed_to_node_ *do*
  ...
ident := _group_identifier_;
*group* _group_name_ *with* ident *do*
    ...

   *for* *each* _expand_name_ *do*
      ...
   *end* *for*;
*end* *group*;
*end* *for*;

The grouping is evaluated in two phases. In the first phase, every iteration of the surrounding for each loop is executed. The nodes are grouped according to the identifier provided to the group expression. After all the iterations of the for each loop, the group block is executed once for each group. If the group declaration in the mapping block contains an expand declaration, there should be a corresponding for each loop in the body.

The group content is executed in a context based on an arbitrary member of the group. Any local variables from the surrounding loop will therefore be valid for a member of the group, but there is no guarantee that it will be the same group member each time a particular group is processed.

Data models

Different versions of the CMDB have subtly different data models. Syncmappings can support multiple data models with datamodel declarations. CMDB data models are assigned simple integer values:

Data model	CMDB versions	Effect
6	7.6.03 and later	HasImpact and ImpactDirection attributes are set as appropriate.
5	7.6.03 and later	Only to be used with legacy SIM version 7.4. BMC_Impact relationships with Name “ImpactOnly” are created.
4	7.6.03 and later	No impact details are set by BMC Discovery. They may be set by Impact Normalization in the CMDB.
3	7.6 before 7.6.03	BMC_Impact relationships with name “IMPACT” are created.
2	7.5	BMC_Impact relationships with name “IMPACT” are created.

A syncmapping can limit itself to a particular set of data models with a datamodel declaration in the overview:

*overview*
*tags* Some_tags;
*datamodel* 3, 4; // Only CMDB 7.6.x
*end* *overview*

The body of a syncmapping can further modify its behavior for different data models with a datamodel block. The datamodel block only executes if the data model in effect matches the declaration:

ci := sync.BMC_Thing(key := my_key, ...);

*datamodel* 2, 3 *do*
   sync.rel.BMC_Dependency(
   Source      := ci,
   Destination := other_ci,
    Name        := "DEPENDENCY_NAME"
   );
*end* *datamodel*;

The data model in effect is not chosen automatically. After you configure CMDB synchronization, the data model is selected. This is described in Setting-up-a-CMDB-synchronization-connection.

BMC_CloudInstance (Provider)

The CloudProvider node is mapped to a BMC_CloudInstance CI with the following attributes:

Attribute	Details
Name	Cloud provider name
ShortDescription	Cloud provider short_name, or name
Description	Cloud provider name
ManufacturerName	Publisher comes from the publishers attribute in the metadata of the related cloud pattern. If no publishers are set, the default publisher is used where a default is specified in CMDB_SyncConfig.tpl.
Model	Cloud provider code
TokenId	Cloud provider key See TokenId rules.
Company	Cloud provider company.
Category	"Cloud"
Type	"Cloud Provider"
Item	"Cloud Provider"

BMC_CloudInstance relationships

Relationship	Name	Source	Destination
BMC_Component	CLOUDREGIONFORPROVIDER	BMC_CloudInstance(Provider) Impacted	BMC_CloudInstance(Region)

BMC_CloudInstance (Region)

The CloudRegion node is also mapped to a BMC_CloudInstance CI. It has the following attributes:

Attribute	Details
Name	Cloud region name
ShortDescription	Cloud region short_name, or name
Description	A description of the form "Region name : Cloud account ID"
ManufacturerName	Publisher comes from the publishers attribute in the metadata of the related cloud pattern. If no publishers are set, the default publisher is used where a default is specified in CMDB_SyncConfig.tpl.
Model	Cloud region code
TokenId	Cloud region key See TokenId rules.
CloudId	Cloud region id
Company	Cloud region company.
Category	"Cloud"
Type	"Cloud Provider"
Item	"Cloud Region"

BMC_CloudInstance relationships

Relationship	Name	Source	Destination
BMC_Component	CLOUDSERVICEINREGION	BMC_CloudInstance (Region)	BMC_CloudInstance(Service) Impacted

BMC_CloudInstance (Service)

The CloudService node is also mapped to a BMC_CloudInstance CI. It has the following attributes:

Attribute	Details
Name	Cloud service name
ShortDescription	Cloud service short_name, or name
Description	A description of the form "Region name : Cloud account ID"
ConsumedService	Cloud service type
LastScanDate	Cloud service last_update_success
ManufacturerName	Publisher comes from the publishers attribute in the metadata of the related cloud pattern. If no publishers are set, the default publisher is used where a default is specified in CMDB_SyncConfig.tpl.
Model	Cloud service code
TokenId	Cloud service key See TokenId rules.
CloudId	Cloud service id
Category	"Cloud"
Type	"Cloud Provider"
Item	Cloud service type

BMC_CloudInstance (Provider)

BMC_Cluster

A cluster dependent on CloudService mapped to a BMC_Cluster CI. It has the following attributes:

Attribute	Details
TokenId	TokenId is of the form "ADDM:%lb_service.key%". See TokenId rules.
Name	Cluster name.
NameFormat	"ClusterName"
ManufacturerName	Publisher comes from the publishers attribute in the metadata of the related cloud pattern. If no publishers are set, the default publisher is used where a default value is specified in CMDB_SyncConfig.tpl.
Model	Cluster type.
Description	Cluster name.
ShortDescription	Cluster name.
isCloud	Yes if the service exists directly within a cloud; null if not.
ComponentAliases	Cluster aliases.
CloudID	Cluster unique cloud identifier (cloud_id).
Company	Cloud service Company.
Category	The Category, Type and Item values are set depending whether unknown_cti is set to true or false in CMDB_SyncConfig.tpl. True - "Unknown" False - "Cluster"
Type	True - "Unknown" False - "Cluster"
Item	True - "BMC Discovered" False - Cluster type

Relationship	Name	Source	Destination
BMC_Dependency	CLOUDSERVICECLUSTER	BMC_CloudInstance (Service)	BMC_Cluster Impacted

BMC_LogicalSystemComponent

The cloud LoadBalancerService is mapped to BMC_LogicalSystemComponent. It has the following attributes:

Attribute	Details
TokenId	TokenId is of the form "ADDM:%lb_service.key%". See TokenId rules.
Name	Load balancer service name or Load balancer service name : cloud service name if the target is Remedyforce.
ShortDescription	Load balancer service short_name, or name
Description	Load balancer service name
ManufacturerName	Publisher comes from the publishers attribute in the metadata of the related cloud pattern. If no publishers are set, the default publisher is used where a default is specified in CMDB_SyncConfig.tpl.
isCloud	Yes if the service exists directly within a cloud; null if not
Model	Load balancer service model
CloudID	Load balancer service unique cloud identifier (cloud_id).
Company	Cloud service Company
Category	"Network"
Type	"Service"
Item	"Load Balancer service"

BMC_LogicalSystemComponent relationships

Relationship	Name	Source	Destination
BMC_Dependency	LOADBALANCERSERVICE	BMC_CloudInstance(Service)	BMC_LogicalSystemComponentImpacted

BMC_ResourcePool

The cloud LoadBalancerPool is mapped to BMC_ResourcePool. It has the following attributes:

Attribute	Details
TokenId	TokenId is of the form "ADDM:%lb_pool.key%". See TokenId rules.
Name	Load balancer pool name or Load balancer pool name : cloud service name if the target is Remedyforce.
ShortDescription	Load balancer pool short.name
Description	Load balancer pool name
ResourceType	Other (0)
Company	Cloud service Company
Category	"Network"
Type	"Service"
Item	"Load Balancer pool"

BMC_ResourcePool relationships

Relationship	Name	Source	Destination
BMC_Component	HOSTEDRESOURCEPOOL	BMC_CloudInstance(Service)	BMC_ResourcePool
BMC_Dependency	LOADBALANCERSERVICE	BMC_ResourcePool (Service)	BMC_LogicalSystemComponentImpacted

BMC_AdminDomain (AdminCollection)

The cloud AdminCollection node is mapped to BMC_AdminDomain. It has the following attributes:

Attribute	Details
Name	Administrative collection name orAdministrative collection name : cloud service name if the target is Remedyforce.
ShortDescription	Administrative collection short_name, or name
Description	Administrative collection name
ManufacturerName	Publisher comes from the publishers attribute in the metadata of the related cloud pattern. If no publishers are set, the default publisher is used where a default is specified in CMDB_SyncConfig.tpl.
Model	Administrative collection type
TokenId	Administrative collection {{code language="none"}} key {{/code}} See TokenId rules.
CloudID	Administrative collection unique cloud identifier (cloud_id).
Company	Cloud service Company
Category	"Cloud"
Type	"Administrative Collection"
Item	Administrative collection name

BMC_AdminDomain (AdminCollection) relationships

Relationship	Name	Source	Destination
BMC_Dependency	CLOUDADMINCOLLECTION	BMC_CloudInstance(Service)	BMC_AdminDomain
BMC_Dependency	ADMINCOLLECTIONMEMBER	BMC_AdminDomain	BMC_BaseElement

BMC_AdminDomain (CloudManagementGroup, NestedCloudManagementGroup, OwnedManagementGroup)

The cloud CloudManagementGroup, NestedCloudManagementGroup, and OwnedManagementGroup nodes are each mapped to BMC_AdminDomain. This mapping was updated in the November 2020 TKU. It has the following attributes:

Attribute	Details
Name	Management Group name
ShortDescription	Management Group short_name or name
Description	Management Group name
ConsumedService	Management Group type
isCloud	Yes if the service exists directly within a cloud; null if not.
LastScanDate	Cloud service last_update_success
ManufacturerName	Publisher comes from the publishers attribute in the metadata of the related cloud pattern. If no publishers are set, the default publisher is used where a default is specified in CMDB_SyncConfig.tpl.
Model	Management Group type
SerialNumber	Management Group id
TokenId	Management Group cloud_id See TokenId rules.
CloudID	Management Group cloud_id
Company	Cloud service Company
Category	"Cloud"
Type	"Cloud Management Group"
Item	Management Group type

BMC_AdminDomain (CloudManagementGroup) relationships

Relationship	Name	Source	Destination
BMC_MemberOfCollection	CLOUDMANAGEMENTGROUPPROVIDER	BMC_CloudRegion	BMC_AdminDomain (CloudManagementGroup) impacted
BMC_Component	CLOUDMANAGEMENTGROUPHIERARCHY	BMC_AdminDomain (parent CloudManagementGroup)	BMC_CloudManagementGroup (child CloudManagementGroup)
BMC_MemberOfCollection	CLOUDMANAGEMENTGROUPOWNEDACCOUNT	BMC_AdminDomain(owning CloudManagementGroup)	BMC_AdminDomain (owned CloudManagementGroup)

BMC_ConcreteCollection

The cloud Deployment node is mapped to BMC_ConcreteCollection. It has the following attributes:

Attribute	Details
Name	Deployment name or Deployment name : cloud service name if the target is Remedyforce.
ShortDescription	Deployment short_name, or name
Description	Deployment name
Model	Deployment type
TokenId	Deployment {{code language="none"}} key {{/code}} See TokenId rules.
CloudID	Deployment unique cloud identifier (cloud_id).
Company	Cloud service Company
Category	"Cloud"
Type	"Deployment"
Item	Deployment name

BMC_ConcreteCollection relationships

Relationship	Name	Source	Destination
BMC_Dependency	CLOUDDEPLOYMENT	BMC_CloudInstance(Service)	BMC_ConcreteCollection
BMC_Dependency	CLOUDDEPLOYMENT	BMC_Cluster(Service)	BMC_ConcreteCollection
BMC_Dependency	CLOUDDEPLOYMENT	BMC_Cluster(Cloud)	BMC_ConcreteCollection
BMC_Dependency	MEMBERINDEPLOYMENT	BMC_ConcreteCollection	BMC_BaseElement

Mapping of VirtualMachine nodes, SoftwareInstance nodes, and contained Database nodes

Where VirtualMachine nodes, SoftwareInstance nodes, and contained Database nodes that are cloud-hosted are populated, it is done so using the same rules as for those on a Host node. The mapping rules are shown below:

BMC_VirtualSystemEnabler and virtualization

When a physical machine hosts one or more virtual machines, the BMC Discovery model represents it as a number of Virtual Machine nodes related to the physical Host (BMC_ComputerSystem ) or Management software (BMC_SoftwareServer ), one Virtual Machine node per virtual host. A BMC_VirtualSystemEnabler CI is created for each VirtualMachine node.

Attribute
Details
key	The SoftwareInstance key, or for RuntimeEnvironments, the host_key/SoftwareInstance product / SoftwareInstance version
Name	VirtualMachine name
ShortDescription	VirtualMachine short_name or name
Description	VirtualMachine name
BuildNumber	VirtualMachine build
EnablerType	Enumeration representing the type of virtualization technology
EndOfExtendedSupport	End of Extended Support date.
EndOfLife	End of Life date.
EndOfSecuritySupport	End of Security Support date.
EndOfSupport	End of Support date.
InstanceName	<type>:<hostname>:<DNS domain>:<instance name> where <type> is the value of the BMC Discovery type attribute from the corresponding SoftwareInstance or Database node, for example, “Microsoft SQL Server” or “Oracle Database”
isCloud	Yesif the virtual machine is known to be cloud hosted; null if not
ManufacturerName	Publisher.
MarketVersion	VirtualMachine product_version
Model	VirtualMachine type
PatchNumber	VirtualMachine patch
ServicePack	VirtualMachine service_pack
TokenID	TokenIdis of the form "ADDM:hashedkey", where hashedkey is a hash of Software Instance key. See TokenId rules.
VersionNumber	VirtualMachine version
ComponentAliases	VirtualMachine cdm_component_aliases
Company	Host Company
Category	"Software"
Type	"Operating System Software"
Item	"Virtualization OS"

Virtualization relationships

Relationship	Name	Source	Destination
BMC_HostedSystemComponents	HOSTEDSYSTEMCOMPONENTS	BMC_ComputerSystem(physical)	BMC_VirtualSystemEnablerImpacted
BMC_Dependency	HOSTEDVIRTUALMACHINE	BMC_CloudInstance	BMC_VirtualSystemEnablerImpacted
BMC_Dependency	VIRTUALSYSTEMOS	BMC_VirtualSystemEnabler	BMC_ComputerSystem(virtual host) BMC_ComputerSystem (virtual network device) BMC_ComputerSystem (virtual SNMP managed device) BMC_ComputerSystem (virtual storage system) Impacted
BMC_VirtualSystemEnabler	VIRTUALSYSTEMOS	BMC_VirtualSystemEnabler	BMC_ComputerSystem(virtual)

BMC_SoftwareServer and BMC_ApplicationSystem

Each SoftwareInstance in the BMC Discovery model is mapped to either a BMC_SoftwareServer CI or a BMC_ApplicationSystem CI:

SoftwareInstancenodes with DDD triggers are directly running on a single host, and are mapped to BMC_SoftwareServer
SoftwareInstancenodes composed of other SoftwareInstance nodes are mapped to BMC_ApplicationSystem.
SoftwareInstance nodes are also mapped (in an indirect manner) to
BMC_Product.
Except as noted, the attributes set are the same in BMC_SoftwareServer and BMC_ApplicationSystem.

Attribute	Details
key	The SoftwareInstance key, or for RuntimeEnvironments, the host_key/SoftwareInstance product / SoftwareInstance version
TokenId	TokenIdis of the form "ADDM:hashedkey", where hashedkey is a hash of Software Instance key. See TokenId rules.
Name	Software Instance name
ShortDescription	Software Instance short_name or Software Instance name
Description	Software Instance name
BuildNumber	Software Instance build
EndOfExtendedSupport	End of Extended Support date.
EndOfLife	End of Life date.
EndOfSecuritySupport	End of Security Support date.
EndOfSupport	End of Support date.
InstanceName	<type>:<hostname>:<DNS domain>:<instance name> where <type> is the value of the BMC Discovery type attribute from the corresponding SoftwareInstance or Database node, for example, “Microsoft SQL Server” or “Oracle Database”
isCloud	Yesif the software instance is known to be cloud hosted; null if not
ManufacturerName	Publisher specified in the maintaining Pattern or on the Software Instance
MarketVersion	Software Instance product_version
Model	Software Instance type
OtherSoftwareServerType	Software Instance type (Only in BMC_SoftwareServer)
PatchNumber	Software Instance patch
ServicePack	Software Instance service_pack
SoftwareServerType	Enumeration representing the type of SoftwareServer. Often 0 meaning "Other". (Only in BMC_SoftwareServer)
VersionNumber	Software Instance version
ComponentAliases	Software Instance cdm_component_aliases
CloudID	Software Instance unique cloud identifier (cloud_id).
Company	Software Instance Company.
Category	"Software"
Type	"Application"
Item	Product category from the maintaining Pattern

Note

The Item attribute is populated from the Pattern that is maintaining the Software Instance. To obtain a list of all the possible Item values, perform the following query in the Discovery Generic Query page:
search Pattern show categories processwith countUnique(0)

BMC_SoftwareServer and BMC_ApplicationSystem relationships

As shown in the table, BMC_SoftwareServer and BMC_ApplicationSystem CIs can be related to each other with a BMC_Dependency relationship. This is mapped from both Dependency and Communication relationships between the SoftwareInstance nodes in the BMC Discovery model.
BMC_SoftwareServer and BMC_ApplicationSystem CIs also have relationships to
BMC_Product, shown in the Product relationships table.

Relationship	Name	Source	Destination
BMC_Dependency	APPLICATIONSYSTEMCOMPUTER	BMC_ComputerSystem(Host) BMC_Cluster (Cluster) BMC_Cluster (Cloud Cluster) BMC_CloudInstance BMC_ComputerSystem (Network Device)	BMC_SoftwareServerImpacted
BMC_Component	APPLICATIONSYSTEMHIERARCHY	BMC_ApplicationSystem(containing) Impacted	BMC_SoftwareServer(contained)
BMC_Component	APPLICATIONSYSTEMHIERARCHY	BMC_SoftwareServer(containing)	BMC_SoftwareServer(contained)
BMC_Dependency	APPLICATIONSYSTEMDEPENDENCY	BMC_SoftwareServeror BMC_ApplicationSystem (depended upon) Impacted	BMC_SoftwareServeror BMC_ApplicationSystem (dependant)
BMC_Dependency	APPLICATIONSYSTEMDEPENDENCY	BMC_SoftwareServer(facet)	BMC_SoftwareServer(main facet) Impacted Communication relationships between nodes are mapped to a dependency between CIs.

Relationship	Name	Source	Destination
BMC_Dependency	APPLICATIONSYSTEMDEPENDENCY	Server (depended upon) BMC_SoftwareServer BMC_ApplicationSystem BMC_ApplicationService BMC_Cluster BMC_VirtualSystemEnabler BMC DataBase BMC DataBase (Cloud)	(dependant) BMC_SoftwareServer BMC_ApplicationSystem BMC_ApplicationService BMC_Cluster BMC_VirtualSystemEnabler BMC DataBase BMC DataBase (Cloud) Impacted
BMC_Dependency	APPLICATIONSYSTEMDEPENDENCY	Client (dependant) BMC_SoftwareServer BMC_ApplicationSystem BMC_ApplicationService BMC_Cluster BMC_VirtualSystemEnabler BMC DataBase BMC DataBase (Cloud) Impacted	Server (depended upon) BMC_SoftwareServer BMC_ApplicationSystem BMC_ApplicationService BMC_Cluster BMC_VirtualSystemEnabler BMC DataBase BMC DataBase (Cloud) Observed Communication relationships between nodes are mapped to Dependency between CIs. Due to the very high volume of Observed Communication relationships, only those that are part of application models are synchronized.

Relationship	Name	Source	Destination
BMC_Dependency	APPLICATIONSYSTEMDEPENDENCY	Listening BMC_SoftwareServer	BMC_SoftwareServer Impacted
BMC_Dependency	APPLICATIONSYSTEMDEPENDENCY	BMC_SoftwareServer	Connecting BMC_SoftwareServer Impacted Management relationships

Relationship	Name	Source	Destination
BMC_Dependency	SYSTEMMANAGER	BMC_Cluster BMC_SoftwareServer First-order SI.BMC_ApplicationSystem Second-order SI.	BMC_SoftwareServerFirst-order SI. BMC_ApplicationSystem Second-order SI. BMC_ComputerSystem BMC_Cluster
BMC_Dependency	SOFTWAREMANAGER	BMC_Cluster BMC_SoftwareServer First-order SI. Second-order SI.	BMC_SoftwareServerFirst-order SI. BMC_ApplicationSystem Second-order SI. BMC_ComputerSystem BMC_Cluster
BMC_HostedSystemComponents	HOSTEDSYSTEMCOMPONENTS	BMC_Cluster BMC_SoftwareServerFirst-order SI.BMC_ApplicationSystem Second-order SI. BMC_ComputerSystem	BMC_VirtualSystemEnabler(hosted) Although the manager impacts the CI it is managing, we do not mark the relationship as impactful, to avoid impact cycles.

BMC_Document

The synchronization mapping attribute DocumentType "TLS Certificate" is part of the BMC_Document CIs. When SoftwareInstance, LoadBalancerService, or CloudLoadBalancerService nodes represent web servers for which TLS/SSL certificates have been discovered, they have related Detail nodes with type "TLS Certificate". The BMC_Document mapping was introduced in Technology Knowledge Update TKU 2020-Sep-1. For more information, see TLS-Certificates-Discovery.
These Detail nodes are mapped to BMC_Document CIs with the following attributes:

Attribute	Details
Name	Detail name
ShortDescription	Detail short_name
Description	Detail common_name
Author	Detail issuer. The certificate issuer.
DocumentType	Amazon ACM Certificate, IPsec Certificate, TLS Certificate, or Windows Certificate.
EndDate	Detail expiry_date. The certificate end (valid to) date.
SerialNumber	Detail serial. The certificate serial number.
StartDate	Detail start_date. The certificate start (valid from) date.
Company	Host Company.
Category	"Software"
Type	"TLS Certificate"
Item	"BMC Discovered" BMC_Document relationships

Relationship	Name	Source	Destination
BMC_Dependency	CERTIFICATE	BMC_Document	BMC_SoftwareServer(SI, Load Balancer, Cloud Load Balancer, Management Controller, Cloud Service, or Host)

BMC_DataBase

Databasenodes (logical databases) are mapped to BMC_DataBase:

Attribute	Details
key	The SoftwareInstance key, or for RuntimeEnvironments, the host_key/SoftwareInstance product / SoftwareInstance version
TokenId	TokenIdis of the form "%hosting_ci.TokenId%:%database_node.type%:%si_instance%:%database_node.instance%" or "%hosting_ci.Name%:%database_node.type%:%si_instance%:%database_node.instance%" See TokenId rules.
Name	Database name or Database name : software cluster name" if the target is Remedyforce.
ShortDescription	Database instance
Description	Description is of the form "%database_node.name% in %si_instance% on %hosting_ci.Name%" or "%database_node.name% on %cloud_svc_ci.Name%"
InstanceName	<type>:<hostname>:<DNS domain>:<instance name> where <type> is the value of the BMC Discovery type attribute from the corresponding SoftwareInstance or Database node, for example, “Microsoft SQL Server” or “Oracle Database”
IsCloud	Yesif the database is known to be cloud hosted; null if not
Model	DatabaseDetail type
ComponentAliases	Database component aliases
CloudID	Database unique cloud identifier (cloud_id).
Company	Host Company.
Category	"Miscellaneous"
Type	"Instance"
Item	"Database"
ManufacturerName	Software Instance vendor
MarketVersion	Software Instance product_version
PatchNumber	Software Instance patch
ServicePack	Software Instance service_pack
VersionNumber	Software Instance version

BMC_DataBase relationships

Relationship	Name	Source	Destination
BMC_Dependency	MANAGEDDATABASE	BMC_SoftwareServer	BMC_DataBaseImpacted
BMC_Dependency	MANAGEDDATABASE	BMC_ApplicationSystem	BMC_DataBaseImpacted
BMC_Dependency	MANAGEDDATABASE	BMC_Cluster	BMC_DataBaseImpacted
BMC_Dependency	MANAGEDDATABASE	BMC_CloudInstance	BMC_DataBaseImpacted

TokenId rules

TokenId is an attribute that, in some circumstances, aids the reconciliation of CIs populated by multiple data sources. BMC Discovery sets TokenId depending on the Node kind.

For most Nodes, TokenId is one of the forms:

key

ADDM:%key%

ADDM:%hashed_key%

For databases, TokenId is a database host found as a result of all possible combinations of where the database might be running:

%hosting_ci.TokenId%:%database_node.type%:%si_instance%:%database_node.instance%

and

%hosting_ci.Name%:%database_node.type%:%si_instance%:%database_node.instance%

For the Fibre Channel Node, TokenId is of the form:

WWN:%wwpn%

For physical hosts, TokenId is of the form:

%host.hostname%:%host.dns_domain%

If the domain name is unavailable, then

%host.hostname%

For virtual hosts that are running in the cloud, TokenId contains instance_id.

For Alibaba, TokenId is of the form:

%alibaba_instance_id%

For Azure, TokenId is of the form:

%azure_vm_id%

For AWS, TokenId is of the form:

%aws_instance_id%

For GCP, TokenId is of the form:

%gce_instance_id%

For IBM, TokenId is of the form:

%instance_id%

For OCI, TokenId is of the form:

%ocid%

For virtual hosts that are running in the hypervisor, TokenId contains UUID.

For AHV, TokenId is of the form:

AHV-UUID:%uuid%

For Hyper-V, the UUID is only available on the physical machine, so TokenId is only set for virtual machines that have been successfully linked to their hosting physical machines:

HYPERV-ID:%vm_uuid%

For KVM (including RedHat Enterprise Virtualization), TokenId is of the form:

KVM-ID:%uuid%

For VMware, TokenId is of the form where each letter represents a hexadecimal digit:

VI-UUID:%uuid%

For Xen (including Oracle VM), TokenId is of the form:

XEN-ID:%uuid%

The following table shows how TokenId looks like for different Node Kinds:

Node Kind	CI	TokenId
AdminCollection	BMC_AdminDomain	key
Cluster (cloud)	BMC_Cluster	key
LoadBalancerService	BMC_LogicalSystemComponent	ADDM:%key%
LoadBalancerPool	BMC_ResourcePool	ADDM:%key%
CloudManagementGroup	BMC_AdminDomain	cloud_id
CloudProvider	BMC_CloudInstance	key
CloudRegion	BMC_CloudInstance	key
CloudService	BMC_CloudInstance	key
Cluster	BMC_Cluster	ADDM:%hashed_key%
Database (cloud)	BMC_DataBase	ADDM:%key%
Database	BMC_DataBase	%hosting_ci.TokenId%:%database_node.type%:%si_instance%:%database_node.instance%
Database	BMC_DataBase	%hosting_ci.Name%:%database_node.type%:%si_instance%:%database_node.instance%
HardwareComponent	BMC_HardwareSystemComponent	ADDM:%hashed_key%
HardwareContainer	BMC_ComputerSystem	ADDM:%hashed_key%
HostContainer	BMC_ComputerSystem	ADDM:%hashed_key%
Host	BMC_ComputerSystem	%host.hostname%:%host.dns_domain%
		%host.hostname%
		ALIBABA-ID:%alibaba_instance_id%
		AWS-ID:%aws_instance_id%
		GCP-ID:%gce_instance_id%
		IBM-ID:%instance_id%
		OCI-ID:%ocid%
		AZURE-ID:%azure_vm_id%
		HYPERV-ID:%vm_uuid%
		XEN-ID:%uuid%
		KVM-UUID:%uuid%
		AHV-UUID:%uuid%
		VI-UUID:%uuid%
LoadBalancerGroup	BMC_Cluster	ADDM:%key%
MFPart	BMC_ComputerSystem	key
Namespace	BMC_AdminDomain	key
Deployment	BMC_ConcreteCollection	key
NetworkService	BMC_LogicalSystemComponent	ADDM:%key%
FibreChannelPort	BMC_NetworkPort	WWN:%wwpn%
SoftwareCluster	BMC_Cluster	ADDM:%hashed_key%
SoftwareComponent	BMC_ApplicationService	ADDM:%hashed_key%
SoftwareInstance	BMC_ApplicationSystem	ADDM:%hashed_key%
SoftwareInstance	BMC_SoftwareServer	ADDM:%hashed_key%
VirtualMachine	BMC_VirtualSystemEnabler	ADDM:%hashed_key%
StorageDevice	BMC_Cluster	ADDM:%key%
StoragePool	BMC_ResourcePool	ADDM:%key%
StorageSystemGroup	BMC_Cluster	ADDM:%key%
StorageProcessor	BMC_HardwarePackage	ADDM:%key%
HardwareContainer	BMC_HardwareSystemComponent	ADDM:%hashed_key%

CDM Mapping for Cloud

Data models

Overview section

Mapping section

Mapping source

Multiple "From" expressions in the mappings block

Mapping traversals

Where clauses

Target CI declarations

Grouping

Syncmapping body

Body execution

CI definition

CI class namespaces

Shared CIs

External CIs

Cross-reference CIs

TokenId rules

Relationship definition

Traversal looping

Group block

Data models

BMC_CloudInstance (Provider)

BMC_CloudInstance relationships

BMC_CloudInstance (Region)

BMC_CloudInstance relationships

BMC_CloudInstance (Service)

BMC_Cluster

BMC_LogicalSystemComponent

BMC_LogicalSystemComponent relationships

BMC_ResourcePool

BMC_ResourcePool relationships

BMC_AdminDomain (AdminCollection)

BMC_AdminDomain (AdminCollection) relationships

BMC_AdminDomain (CloudManagementGroup, NestedCloudManagementGroup, OwnedManagementGroup)

BMC_AdminDomain (CloudManagementGroup) relationships

BMC_ConcreteCollection

BMC_ConcreteCollection relationships

Mapping of VirtualMachine nodes, SoftwareInstance nodes, and contained Database nodes

BMC_VirtualSystemEnabler and virtualization

Virtualization relationships

BMC_SoftwareServer and BMC_ApplicationSystem

BMC_SoftwareServer and BMC_ApplicationSystem relationships

BMC_Document

BMC_DataBase

BMC_DataBase relationships

TokenId rules

On this page