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

The "ServiceNow CMDB" SyncPack version 3.6.0 adds OAuth2 support for the SyncPack, adds new configuration options to multiple applications, adjusts how interfaces are handled in ServiceNow tables, and addresses an issue that caused an interface to be deleted and rediscovered in SL1 when there were no changes to the parent device.

This SyncPack requires the "ServiceNow Base" SyncPack version 3.6.5 or later and the "Base Steps" SyncPack version 1.5.3 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:

• Removed duplicate sync mappings from the "Sync Devices from SL1 to ServiceNow" application. (Case: 00418286)

• Updated the "Sync Devices from SL1 to ServiceNow" application to allow "modelNumber" to be synced. (Case: 00434086)

• Added info level logs to the "Query and Cache EM7 Device Classes" and "Query and Cache ServiceNow CI List" steps of the "Cache ServiceNow CIs And SL1 Device Classes" application to show the data that is put into the cache. (Case: 00422846)

• Addressed an issue that caused an interface to be deleted and rediscovered in SL1 when there were no changes to the parent device. (Case: 00421656)

• Added the new sync_unsupported_file_systems toggle to the "Sync File Systems from SL1 to ServiceNow" application. Toggling this on will allow file systems which have a parent device class of Network.Switch or Network.Router to sync when the application is run.

• Removed the interface_snow_default toggle from the "Sync Interfaces from SL1 to ServiceNow" application.

• Added a override_snow_mappings toggle (toggled off by default) to the "Sync Interfaces from SL1 to ServiceNow" application. When toggled on, all interfaces are sent to the cmdb_ci_network_adapter table in ServiceNow, ignoring the user-entered IANA type mappings and skipping the hardcoded mappings. However, the interface will be ignored if it is missing the required fields to be correctly created and identified in ServiceNow on the cmdb_ci_network_adapter table. The required fields are "ip", "macAddress", and "hardwareDescription".

• Added the snow_api_version option to configuration objects. This option lets you specify the version of the IRE endpoint to which you want PowerFlow to send CI payloads. , If no value is entered, PowerFlow will use "v2" by default. For proper interface handling, ScienceLogic recommends entering "v3". The only possible values are "v2" or "v3".

In order to use "v3" for the snow_api_version, you must install the latest version of the "ScienceLogic ServiceNow Integration (v1.0.81)+ Interface Hotfix" update set in ServiceNow. Ask your ScienceLogic contact for access to this update set.

• Added the following configuration options to the Device, Interface, File System, CI Attribute, and Installed Software syncs:

  • retry_max. The maximum number of times PowerFlow will retry to execute the step before it stops retrying and logs a step failure. For example, if retry_max is 3, PowerFlow will retry after 1 second, then 2 seconds, then 4 seconds, and stop if the last retry fails. The default is 0.

  • retry_jitter. When selected, instead of using a defined interval between retries, PowerFlow will retry the step execution at random intervals. The default is unselected.

  • retry_backoff. When selected, instead of using a defined interval between retries, PowerFlow will incrementally increase the interval between retries. The default is unselected.

  • retry_backoff_max. The maximum time interval for the retry_backoff option, in seconds. For example, if you have retry_max set to 15, the delays will be 1, 2, 4, 8, 16, 32, 64, 120, 240, 480, 600, 600, 600, 600, and 600. The default is 600.

• Added OAuth2 support to the SyncPack. There are four required parameters you can add to a configuration object to facilitate OAuth2 connection to ServiceNow:

  • snow_oauth_client_id. OAuth2 Client ID from ServiceNow
  • snow_oauth_client_secret. OAuth2 Client secret from ServiceNow
  • snow_oauth_token_url. Full authentication URL, including host and protocol from ServiceNow. For example, "https://<test-instance-name>.service-now.com/oauth_token.do"
  • snow_auth_method. You can enter 'oauth' or 'http_basic' as the value. If no value is provided, 'http_basic' will be used for connection.

The configuration options listed above are only required in the configuration object if you plan to use OAuth2 to authenticate. If the values are not present in the configuration object, normal "http_basic" authentication will be used.

Known Issues

This release has the following known issues:

• SL1 only supports US 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]}}}}

• 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

This release requires the following components:

• SL1 PowerFlow platform version 2.4.0 or later.
• SL1 version 11.2.0 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.0 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.