Appendix: Mappings between ServiceNow and Third-party Applications

This appendix contains information about how SL1 and ServiceNow discover and model out different technologies, using VMware as an example. The VMware example explains how the differences between the systems requires rules be configured to bridge the gap between SL1 and ServiceNow.

This appendix includes the following topics:

Overview

In certain cases, SL1 and ServiceNow will not discover model other technologies and applications in the same way. As a result, you might need to configure the class rules to satisfy the Identification and Reconciliation Engine in ServiceNow.

One such example of where SL1 and ServiceNow differ in how they model other devices is when PowerFlow attempts to sync VMware devices from SL1 to ServiceNow. Because of these differences, the required configurations for VMware and a number of other technologies are packaged into an update set provided by SL1. This update set removes any manual effort for users.

However, there are many technologies where SL1 has not yet created an update set. For those situations, the following topics will cover how SL1 and ServiceNow differ, and what configuration steps are required in ServiceNow.

VMware Discovery

For more information about how the Identification and Reconciliation Engine works within ServiceNow, see this ServiceNow Knowledge Base article.

Conflicts

The vCenter Discovery process in ServiceNow creates Configuration Items, but does not send the payload data through Identification Engine. The sensors or probes process the payload and use scripts to insert records.

For more information about this situation, see this ServiceNow Knowledge Base article.

vCenter

The vCenter (cmdb_ci_vcenter) default relationship is to a hardware class table, and by default this relationship is a dependent class. The Identification Rule is derived using the Application Rule.

Conflicts

The instance UUID, which is a more unique field, is not collected. As a result, identification falls to the Name field alone, which is an unreliable source. You can perform the following edits to the name to match what ServiceNow does, although this practice leads to duplicates:

Set the name of the vCenter to the "vcenter@ip_address" of the device instead of the hostname. You can edit a modification of the name value being sent from SL1 through PowerFlow.
You can use the following Jinja2 template for name mapping:
```
"{{ 'vcenter@{}'.format(device.ip) if device.snow_ci_class == 'cmdb_ci_vcenter' else device.name }}": [
       "name"
     ],
```
This name setup has a high chance of causing multiple Device IDs to sync to one ServiceNow Configuration Item.

For more information about Jinja2 templates, see Using a Jinja2 Template.

The order in which SL1 loads data fails to make the specific relationships that ServiceNow populates, because Discovery does not appear to follow rules of the Identification Engine.

Working Solution

To address this situation, complete the following steps:

Replace the identification rule with a rule that applies specifically to a VMware vCenter Instance (cmdb_ci_vcenter):
Add an identifier to the Name field:

Datacenter

DataCenter (cmdb_ci_vcenter_datacenter) is a dependent class, and the identification is derived from the logical Datacenter table (cmdb_ci_logical_datacenter). The Identification rules are listed under Local Datacenter Rule.

Conflicts

The instance UUID (account ID) is not available to be pulled from SL1, and the unique_id field is not a reliable source for identification. As a result, you cannot generate the default relationship to the cloud service account with the values collected.

Working Solution

To address this situation, complete the following steps:

To enable SL1 to sync VMware vCenter Data Centers, an override dependency is required.

Relationship for vCenter > Datacenter is required:

Hosting Rule
Child type	cmdb_ci_vcenter
Is reverse	true
Parent type	cmdb_ci_vcenter_datacenter
Relation type (Parent::Child)	Managed by::Manages

Folders

VMware Folders (cmdb_ci_vcenter_folder) is a dependent class, with no mapped dependency by default.

Conflict

The ServiceNow Discovery Expected Relationship is different from the default identification of Hosted On.

ServiceNow Discovery

Hosting Rule
Child type	cmdb_ci_vcenter_folder
Is reverse	true
Parent type	cmdb_ci_logical_datacenter
Relation type (Parent::Child)	Contains::Contained by

Default

Hosting Rule
Child type	cmdb_ci_logical_datacenter
Is reverse	false
Parent type	cmdb_ci_vcenter_folder
Relation type (Parent::Child)	Hosted on::Hosts

Working Solution

To address this situation, use the following override set in PowerFlow to handle the default relationship:

"cmdb_ci_vcenter_folder": {
 "relations": [
   {
     "parent": "cmdb_ci_vcenter_datacenter",
     "rel_type": "Hosted on::Hosts",
     "reverse": true
   }
 ],
 "values": {
  
 }
}

For more information about setting overrides, see Configuring Customer CI Relation Overrides.

Cluster

VMware vCenter Cluster (cmdb_ci_vcenter_cluster) is a dependent class, and the identification is derived from the Host Cluster (cmdb_ci_host_cluster). The Identification rules are listed under Host Cluster Rule.

Conflicts

The order in which PowerFlow loads data is not compatible with making the specific relationships that ServiceNow populates. This issue occurs because Discovery does not appear to follow the rules of the Identification Engine.

Working Solution

To address this situation, use the following override set in PowerFlow to handle the default relationship:

Additional relationships are also listed but not shown below. This data is specific to the identification of the device.

"cmdb_ci_vcenter_cluster": {
 "relations": [
   {
     "parent": "cmdb_ci_vcenter_datacenter",
     "rel_type": "Contains::Contained by",
     "reverse": false
   }
 ],
 "values": {
  
 }
}

For more information about setting overrides, see Configuring Customer CI Relation Overrides.

Network

VMware vCenter Network (cmdb_ci_vcenter_network) is a dependent class, and the identification is derived from the Network Rule (cmdb_ci_network). The Identification rules are listed under the Host Cluster Rule.

The derived relationship is a Hosted On relationship type, and the expected relationship would be Contains. You will need to create a new metadata rule to get the expected relationship, if the rule does not already exist.

Conflicts

The default relationship in ServiceNow is Hosted On, and ServiceNow Discovery is expecting a relationship of Contains instead of Hosted. This situation requires a change to the Dependent Relationships:

The relationship for VMware vCenter Network > VMware vCenter Datacenter is required.

Hosting Rule
Child type	cmdb_ci_vcenter_network
Is reverse	true
Parent type	cmdb_ci_vcenter_datacenter
Relation type (Parent::Child)	Contains::Contained by

The order in which PowerFlow loads data is not compatible with making the specific relationships that ServiceNow populates. This issue occurs because Discovery does not appear to follow the rules of the Identification Engine.

Working Solution

To address this situation, use the following override set in PowerFlow to handle the default relationship:

Additional relationships are also listed but not shown below. This data is specific to the identification of the device.

"cmdb_ci_vcenter_network": {
 "relations": [
   {
     "parent": "cmdb_ci_vcenter_datacenter",
     "rel_type": "Hosted on::Hosts",
     "reverse": true
   }
 ],
 "values": {
  
 }
}

For more information about setting overrides, see Configuring Customer CI Relation Overrides.

Switch

VMware Distributed Virtual Switch (cmdb_ci_vcenter_dvs) is a dependent class, and the identification is derived from the Cloud Network (cmdb_ci_network). The Identification rules are listed under Network Rule.

Conflicts

The derived relationship is a Hosted On relationship type, and the expected relationship would be Contains for ServiceNow Discovery. You will need to create a new metadata rule to get the expected relationship, if the rule does not already exist.

The relationship for VMware vCenter Network > VMware vCenter Datacenter is required.

Hosting Rule
Child type	cmdb_ci_vcenter_dvs
Is reverse	true
Parent type	cmdb_ci_vcenter_datacenter
Relation type (Parent::Child)	Contains::Contained by

The order in which PowerFlow loads data is not compatible with making the specific relationships that ServiceNow populates. This issue occurs because Discovery does not appear to follow the rules of the Identification Engine.

Working Solution

To address this situation, use the following override set in PowerFlow to handle the default relationship:

Additional relationships are also listed but not shown below. This data is specific to the identification of the device.

"cmdb_ci_vcenter_dvs": {
 "relations": [
   {
     "parent": "cmdb_ci_vcenter_datacenter",
     "rel_type": "Hosted on::Hosts",
     "reverse": true
   }
 ],
 "values": {
  
 }
}

For more information about setting overrides, see Configuring Customer CI Relation Overrides.

Virtual Port Group

VMware Distributed Virtual Port Group (cmdb_ci_vcenter_dv_port_group) is a dependent class and the identification is derived from the Port Group (cmdb_ci_port_group). The Identification rules are listed under Port Group Rule.

Conflicts

The relationship for VVMware Distributed Virtual Port Group > VMware vCenter Datacenter is required.

Hosting Rule
Child type	cmdb_ci_vcenter_dv_port_group
Is reverse	true
Parent type	cmdb_ci_vcenter_datacenter
Relation type (Parent::Child)	Contains::Contained by

The order in which PowerFlow loads data is not compatible with making the specific relationships that ServiceNow populates. This issue occurs because Discovery does not appear to follow the rules of the Identification Engine.

Working Solution

To address this situation, use the following override set in PowerFlow to handle the default relationship:

Additional relationships are also listed but not shown below. This data is specific to the identification of the device.

"cmdb_ci_vcenter_dv_port_group": {
 "relations": [
   {
     "parent": "cmdb_ci_vcenter_datacenter",
     "rel_type": "Hosted on::Hosts",
     "reverse": true
   }
 ],
 "values": {
  
 }
}

For more information about setting overrides, see Configuring Customer CI Relation Overrides.

ESX Server

VMware vCenter Network (cmdb_ci_esx_server) is an independent class, and the Identification rules are listed under ESX Server Rule.

Conflicts

Because no GUID is being collected, the Identification attributes need to be updated. The ability to correlate values in both systems to identify might case issues with some integrations.

Working Solution

Add an Identifier Entry to the ESX Server rule in addition to the current Correlation ID entry:

ESX Resource Pool

ESX Resource Pool (cmdb_ci_esx_server) is a dependent class, and the identification is derived from the VM Object (cmdb_ci_vcenter_object). The Identification rules are listed under Port Group Rule.

Conflicts

No derived relationship or any relationship type is defined within ServiceNow by default (ServiceNow Base + Discovery). You will need to create a new metadata rule to get the expected relationship, if the rule does not already exist.
The order in which PowerFlow loads data is not compatible with making the specific relationships that ServiceNow populates. This issue occurs because Discovery does not appear to follow the rules of the Identification Engine.
No DCM+R relationships exist on vCenter Resource Pools, which causes issues when trying to create matching relations from that ServiceNow Discovery.

Working Solution

To address this situation, use the following override set in PowerFlow to handle the default relationship:

Additional relationships are also listed but not shown below. This data is specific to the identification of the device.

"cmdb_ci_esx_resource_pool": {
  "relations": [
    {
      "parent": "cmdb_ci_esx_server",
      "rel_type": "Defines resources for::Gets resources from",
      "reverse": true
    }
  ],
  "values": {
    
  }
}

For more information about setting overrides, see Configuring Customer CI Relation Overrides.

Datastore

VMware vCenter Datastore (cmdb_ci_vcenter_datastore) is a dependent class, and the identification is derived from the VM Object (cmdb_ci_vm_object). The Identification rules are listed under VM Object.

Default Identification:

Object ID
Name
Correlation ID

Conflicts

Identification by defaulting to name does not appear to be unique enough, and it results in false matching. You will need to change the priority identification.
The relationship that ServiceNow Discovery sends does not line up with the defined dependent relationships.
The order in which PowerFlow loads data is not compatible with making the specific relationships that ServiceNow populates. This issue occurs because Discovery does not appear to follow the rules of the Identification Engine.
No derived relationship or any relationship type is defined within ServiceNow by default (ServiceNow Base + Discovery). You will need to create a new metadata rule to get the expected relationship, if the rule does not already exist.

Working Solution

To address this situation:

Use the following override set in PowerFlow to handle the default relationship:

Additional relationships are also listed but not shown below. This data is specific to the identification of the device.
```
"cmdb_ci_vcenter_datastore": {
  "relations": [
    {
      "parent": "cmdb_ci_vcenter_datacenter",
      "rel_type": "Contains::Contained by",
      "reverse": false
    }
  ],
  "values": {
    
  }
}
```
For more information about setting overrides, see Configuring Customer CI Relation Overrides.
Add an Identifier Entry to the VM Object Rule in addition to the current entries:
- Object ID
- Name
- Correlation ID

Virtual Machine Instance

VMware Virtual Machine Instance (cmdb_ci_vmware_instance) is a dependent class, and the identification is derived from the Virtual Machine Instance (cmdb_ci_vm_instance). The Identification rules are listed under VM Instance.

Conflicts

The VC-VM Iinstance UUID, which is a more unique field, is not collected. As a result, identification falls to the Name field alone, which is an unreliable source.
The relationship that ServiceNow Discovery sends does not line up with the defined dependent relationships. The default relationship Hosted On or Runs for dependency, but the relationships that Discovery updates do not line up.
The order in which PowerFlow loads data is not compatible with making the specific relationships that ServiceNow populates. This issue occurs because Discovery does not appear to follow the rules of the Identification Engine.

Working Solution

To address this situation, use the following override set in PowerFlow to handle the default relationship:

Additional relationships are also listed but not shown below. This data is specific to the identification of the device.

"cmdb_ci_vmware_instance": {
  "relations": [
    {
      "parent": "cmdb_ci_vcenter_datacenter",
      "rel_type": "Hosted on::Hosts",
      "reverse": true
    }
  ],
  "values": {
    
  }
}

For more information about setting overrides, see Configuring Customer CI Relation Overrides.