Skip to Content

Default language.

Information
Important This documentation space contains information about the SaaS version of BMC Helix Discovery. If you are using the on-premises version of BMC Helix Discovery, see BMC Helix Discovery 25.2 (On-Premises).

Default ServiceNow Mapping

Root node kind mappings

Each root node kind in the Discovery model is mapped to ServiceNow as follows:

Warning

Note

If possible, you should make modification to class definitions in the CMDB before setting up the CMDB sync connection. Changes made to the class definitions in the CMDB are only read by BMC Helix Discovery when the CMDB sync connection is set up, or when the services are restarted. You cannot restart services through the BMC Helix Discovery UI, so you should raise a case with Customer Support.

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 relationships, reference fields, 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.

Mapping tables

Tables in ServiceNow do not have a correlation_id column. The correlation_id column is used to store the BMC Helix Discovery node key, which provides a way to determine whether the node has been synchronized. For tables, you must specify columns from the table to make a key in the pattern metadata section. 

For example, the following metadata defines the key for table1 to be column1/column2 and for table2 to be column3/column4.

metadata
        table_identifiers := "table1:column1/column2",
                             "table2:column3/column4";
end metadata;

BMC Helix Discovery cannot retrieve dependencies between tables. In the pattern metadata section, you define any required dependent relationships between tables. Dependencies are not mandatory.

For example, the following metadata adds a dependency between table1 and table2: 

metadata
        table_dependency  := "table1:table2";
        ...
end metadata;

which are linked with a 'dependency' relationship:

sync.rel.dependency(
      parent := table1,
      child  := table2);

If there is a business rule on a table, for example on cmdb_model_lifecycle which prevents the creation of a record if the model (the sys_id of the cmdb_model) is empty. In this case, the two records must be created as Dependent Nodes.

Relationships and Reference fields

The default mappings makes use of relationships and references between CIs.

Relationships have a relationship type, for example, "Runs on::Runs" (converted in TPL as "Runs_on__Runs") and are shown in the Related Items section on the CI form and in the Dependency Viewer in ServiceNow. Relationships between two CIs are stored in a separate relationship table in ServiceNow and allow many to many relationships.

A reference is a field in the CI record itself (that is, a foreign key). A reference to another CI can only be defined if a reference field has been designed in the ServiceNow CMDB table. For example,  the table cmdb_ci_ip_address (IP Address) has a reference field “nic” which can be used to link to a record in the cmdb_ci_network_adapter table.

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*

BMC Helix Discovery (SaaS)