ServiceNow Configuration Management Database (CMDB) SyncPack Release Notes, version 3.6.0

The "ServiceNow CMDB" SyncPack version 3.6.1 updates the configuration of the Device and Interface syncs, and addresses multiple issues with the Device and Interface syncs.

This SyncPack requires the "ServiceNow Base" SyncPack version 3.8.1 or later and the "Base Steps" SyncPack version 1.5.5 or later. You can download these SyncPacks from the ScienceLogic Support Site.

Enhancements and Issues Addressed in this Release

The following issues were addressed in this release:

  • Added "cmdb_ci_wap_network" to the customer_ci_relations_overrides configuration option on the "Sync Devices from SL1 to ServiceNow" application.

  • Addressed an issue that caused Device sync mappings to pull directly from the configuration object in PowerFlow. (Case ID: 00447321)

  • Addressed an issue with the "Sync Interfaces from SL1 to ServiceNow" application that caused constant updates if the interface type was included in the mappings. As part of this fix, "type_id" was added to the default mappings, which will not be sent to the "cmdb_ci_network_adapter" or "cmdb_ci_lb_vlan" tables since the field does not exist on those tables in ServiceNow. (Case: 00464089)

  • Made a series of updates to the "Sync Interfaces from SL1 to ServiceNow" application:

    • Made an update to ensure that the interface "object_source_id" matches the CI table destination. For example, an interface which is sent to the "dscy_switchport" table will always have a native key contatining "IFSWPort".

    • The enable_advanced_topology toggle is now false by default, which means interface to interface relations are not sent by default.

    • Added a new JSON mapping parameter, interface_advanced_mappings, which allows you to define the mappings for the combination of interface IANA type and parent device type to a specific ServiceNow table. This configuration option is blank by default, and must be configured to define the mappings you want to use. For more information about using this parameter, see the Configuring Additional Syncs for the ServiceNow CMDB SyncPack chapter in the ServiceNow CMDB SyncPack manual.

    • Added a new JSON mapping parameter, interface_relation_mappings, which operates similarly to the relationship overrides in the Device Sync. This parameter allows you to define which interface relationships to send to ServiceNow. This configuration option is blank by default, and must be configured to define the relationships you want to send directly. (Case ID: 00446274)

An example value for the interface_relation_mappings field is as follows: { "cmdb_ci_network_adapter": { "relations": [ { "parent": "cmdb_ci_network_adapter", "rel_type": "Connects to::Connected by", "create_to_duplicate": False, "create_from_duplicate": False } ] } } . In this example, the sync creates relationships between interfaces where the child interface is on the "cmdb_ci_network_adapter" table and the parent interface is on the "cmdb_ci_network_adaptor" table, and neither is a "duplicate". The "create_to_duplicate" parameter being false means that relationships where the child interface is a duplicate will not be created. The "create _from_duplicate" parameter being false means that relationships where the parent interface is a duplicate will not be created. Determining if an interface is a "duplicate" depends on the number of destination tables in the hard-coded or user provided mappings. For example, in the hard-coded mappings, if the IANA type of the interface is "ethernetcsmacd" and the parent device type is "network.switches", the interface is sent to two tables: "dscy_switchport" and "cmdb_ci_network_adapter". Even if one of the interfaces is discarded due to missing required fields for creation, both interfaces are tagged as "duplicates".

Known Issues

This release has the following known issues:

  • SL1 only supports US-based states in the state field.
  • For the "Sync Business Services from SL1 to ServiceNow" application, creating a business service relationship in SL1 where the bottom service is a device service without any devices in it will send the empty device service to ServiceNow. This behavior is different from the "Sync Business Services from ServiceNow to SL1" application, which does not send any service in the tree if the bottom device service is empty.
  • Merging devices in the middle of a component tree could cause relationships in ServiceNow to be incorrect.
  • An issue exists with syncing VMware resource pools if the resource pool has a direct link to the VMware cluster. In SL1, if you have a VMware resource pool that does not belong to a VMware host, that resource pool will not be synced to ServiceNow. The children devices underneath the resource pool will continue to be synced to ServiceNow.
  • When syncing VMware virtual devices from SL1 to ServiceNow, any virtual apps are synced by default to the VMware object table in ServiceNow, because ServiceNow does not have a virtual app class. To work around this issue, you can either use the default setting to sync to the VMware object table or you can create a custom virtual app class and modify the mappings.
  • In version 3.5.0 of this SyncPack, filtering by SL1 org_id requires the use of companies in ServiceNow. The org filter works by including the corresponding company_sys_id in the payload when posting to ServiceNow to gather the CIs. ServiceNow then filters the CIs based on this value, and returns the CIs. To avoid undesired disconnects, the org filter needs to be applied on both the SL1 side as well as the ServiceNow side. Starting in 3.5.0, this SyncPack supports a multi-stack set up, which can lead to a scenario where the same company sys_id in ServiceNow is aligned to multiple organizations across different SL1 systems. The ServiceNow company sys_id is required when filtering by org (as opposed to just the SL1 org_id) because the organizations with the matching crm_id may have different SL1 org IDs. (Case: 00318963) As a workaround, to sync only devices of certain SL1 organizations to ServiceNow, use a GraphQL filter. For example, to filter devices by SL1 org_id 0, add the following JSON code to the gql_filter on the Configuration pane of the "Sync Devices from SL1 to ServiceNow" application: {"organization": {"has": {"id": {"in": [0]}}}}

System Requirements

This release requires the following components:

  • SL1 PowerFlow platform version 2.6.0 or later.
  • SL1 version 12.1 or later. For details on upgrading SL1, see the relevant SL1 Platform Release Notes.
  • "Base Steps" SyncPack version 1.5.5 or later.
  • "ServiceNow Base" SyncPack version 3.8.1 or later.
  • ServiceNow version Tokyo or later, with Web Services enabled.
  • "ScienceLogic SL1: CMDB & Incident Automation" certified application version 1.0.81. This version includes the following updates:
    • Addressed an issue where the Organization Sync to Company was not being handled correctly.
    • Addressed an issue where the Change Request API was returning incorrect results and not taking advantage of the sys_object_source_info table.
    • Addressed an issue where the Installed Software API was returning incorrect results and not taking advantage of the sys_object_source_info' table.

You should always use the most recent version of a SyncPack and its certified application.

If your ServiceNow instance is domain-separated, install the latest "ScienceLogic Domain Separation (Global)" update set in ServiceNow. Ask your ScienceLogic contact for access to this update set.

The following table lists the port access required by PowerFlow for this SyncPack:

Source Port Purpose

SL1 API

443

SL1 API Access

ServiceNow API

443

ServiceNow API Access

SL1 Database

7706

SL1 Database Access

Prerequisites for the SyncPack

To install this SyncPack, you must have administrator access to both SL1 and ServiceNow. Specifically, you will need:

  • ScienceLogic root SSH access
  • ScienceLogic administrator access to the Administration Portal
  • ServiceNow administrator access

ScienceLogic highly recommends that you disable all firewall session-limiting policies. Firewalls will drop HTTPS requests, which results in data loss.

Installing or Upgrading the SyncPack

For detailed steps about installing or upgrading to this version of the "ServiceNow CMDB" SyncPack, see the Installing the ServiceNow CMDB SyncPack chapter in the ServiceNow CMDB SyncPack manual.