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

The "ServiceNow CMDB SyncPack" version 3.5.1 includes new configuration options for the File System Sync, Interface Sync, Installed Software Sync, and CI Attribute Sync, a new configuration toggle for all applications with REST interactions with ServiceNow, and also addresses multiple issues and support defects.

This SyncPack is available as part of an SL1 Standard solution. To upgrade, contact ScienceLogic Customer Support. For more information, see https://sciencelogic.com/pricing.

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

Features Included in this Release

This section covers the features that were included in this version of the ServiceNow CMDB SyncPack.

  • Added the verify_snow_ssl toggle to allow verification of the SSL certification on all applications with REST interactions with ServiceNow. Previously, this value was hard-coded to true. (Support Case: 00321733)

Installed Software Sync

  • Updated the API endpoints used by the "Sync Installed Software from SL1 to ServiceNow" application to POST and GET installed software to and from ServiceNow.

  • Add the following fields to the Configuration pane for the "Sync Installed Software from SL1 to ServiceNow" application:

    • snow_request_limit. Specify the number of CI objects fetched from ServiceNow in each request. The default is 500 objects per chunk.
    • snow_chunk_size. Specify the number of CI objects to send in each chunk. The default is 150 objects per chunk.

CI Attribute Sync

  • Added the following fields to the Configuration pane of the "Sync CI Attributes from ServiceNow to SL1" application:

    • snow_request_limit. Specify the number of CI objects fetched from ServiceNow in each request. The default is 500 objects per chunk.

Interface Sync

  • Added the following fields to the Configuration pane of the "Sync Interfaces from SL1 to ServiceNow" application:

    • change_interface_organizations. Toggle on (blue) this option to allow interfaces to change companies with an Interface Sync if the companies are within the same domain in ServiceNow. If you change the Organization/Company and another field, but do not enable this parameter, PowerFlow will not apply any changes to the interface.

    • drop_company. Toggle on (blue) this option to remove the sys_id in existing companies from the sync. This will prevent the "Company" field from sending to ServiceNow. This option has no effect if the domain_separation parameter is enabled for this application.

File System Sync

  • Added the following field to the Configuration pane of the "Sync File Systems from SL1 to ServiceNow" application:

    • sl1_org_filter_only. Toggle on (blue) this option to apply the organization filter to only the SL1 side of the data pull.

    • change_fs_organizations. Toggle on (blue) this option to allow file systems to change companies with an Interface Sync if the companies are within the same domain in ServiceNow. If you change the Organization/Company and another field, but do not enable this parameter, PowerFlow will not apply any changes to the file system.

    • drop_company. Toggle on (blue) this option to remove the sys_id in existing companies from the sync. This will prevent the "Company" field from sending to ServiceNow. This option has no effect if the domain_separation parameter is enabled for this application.

    Enabling this toggle will only apply organization filtering to the SL1 side of the data pulls, while all file systems for the provided region in ServiceNow will be returned. Be cautious using this option, as enabling it may cause unwanted disconnects in ServiceNow.

To view release notes and manuals for all versions of the SL1 PowerFlow Platform, see SL1 PowerFlow Platform Documentation. To view release notes and manuals for PowerFlow SyncPacks, see SL1 PowerFlow SyncPack Documentation.

Issues Addressed in this Release

The following issues were addressed in this release:

  • 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.
  • Due to a change in GraphQL in SL1 version 11.1.0, some PowerFlow applications will fail to sync if you upgrade to that version of SL1. This issue was addressed in SL1 version 11.1.2.
  • 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]}}}}

  • In version 3.5.0 of this SyncPack, the "cmdb_ci_vcenter_object": ["VMware | Virtual App"] was removed from the default mappings because ServiceNow has not implemented a default dependency that differs from previous behavior. This change might lead to orphaned devices being sent to ServiceNow.

  • Added info level logging when using the batch endpoint to send information to ServiceNow. The log displays the payloads being sent in each sub-batch to help support debugging.

  • If you upgrade from a previous version of the ServiceNow CMDB SyncPack where name was not in either side of the organization sync mapping, the name field will now be sent to either SL1 or ServiceNow to avoid creating organizations or companies without names. (Case: 00329966)

  • Version 3.5.1 of the ServiceNow CMDB SyncPack supports having the full country or state name in ServiceNow. PowerFlow will attempt to convert the country and state fields, along with any custom fields containing the words state or country to the required abbreviations. If the value is unable to be converted, a debug log will be provided.

Known Issues

This release contains the following known issues:

  • SL1 only supports the state field as a US state.
  • 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.
  • Due to a change in GraphQL in SL1 version 11.1.0, some PowerFlow applications will fail to sync if you upgrade to that version of SL1. This issue was addressed in SL1 version 11.1.2.
  • 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, the "cmdb_ci_vcenter_object": ["VMware | Virtual App"] was removed from the default mappings because ServiceNow has not implemented a default dependency that differs from previous behavior. This change might lead to orphaned devices being sent to ServiceNow.

System Requirements

The "ServiceNow CMDB SyncPack" version 3.5.1requires:

  • SL1 PowerFlow platform version: 2.3.0 or later.

  • Base Steps SyncPack version: 1.5.0 or later.

  • ServiceNow Base SyncPack version: 3.6.1 or later.

  • The "ScienceLogic SL1: CMDB & Incident Automation" application version: 1.0.81.

  • SL1 version: 11.1.0 or later. For details on upgrading SL1, see the appropriate SL1 Release Notes.

  • ServiceNow version: Quebec or later, with Web Services enabled.

    If your ServiceNow instance is domain-separated, install the latest "ScienceLogic Domain Seperation (Global)" update set in ServiceNow. You can access this update set from the additional_materials.zip file included in the main .zip file for this SyncPack, which you can find by searching for the ServiceNow CMDB SyncPack page at https://support.sciencelogic.com/s/powerpacks. For more information, see ServiceNow CMDB SyncPack manual.

    Due to a change in GraphQL in SL1 version 11.1.x, some PowerFlow applications will fail to sync if you upgrade to that version of SL1. As a workaround, use SL1 version 10.2.0 or earlier. This issue will be addressed in SL1 version 11.2.1.

    Interface Sync requires SL1 version 11.2.0 or later due to a GQL issues that prevented the interface type from being returned correctly.

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 Installing the ServiceNow CMDB SyncPack.