Installing the ServiceNow CMDB SyncPack

Download this manual as a PDF file 

This section explains how to install and configure the various applications used by the "ServiceNow CMDB" SyncPack.

The following workflow covers how to install and configure this SyncPack:

  1. Review the prerequisites and background information for this SyncPack.
  2. In PowerFlow, download, import, and install the "ServiceNow CMDB" SyncPack.
  3. In ServiceNow, enable cross-scoped access (if needed).
  4. In ServiceNow, install the "ScienceLogic SL1: CMDB & Incident Automation" application (also called the "Scoped Application").
  5. In ServiceNow, create a ServiceNow Group and then create a ServiceNow User .
  6. In ServiceNow, install and activate the relevant plugins.
  7. In ServiceNow, enable the ServiceNow Identification and Reconciliation Module.
  8. In ServiceNow, install the "ScienceLogic Domain Separation (Global)" update set (for domain-separated ServiceNow instances only).

Prerequisites for the ServiceNow CMDB SyncPack

This section describes the prerequisites for the ServiceNow SyncPacks. For more information about the specific software versions required by a ServiceNow SyncPack, see the release notes for that SyncPack.

Administrator Access

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.

Port Access

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

Source Port Requirement
SL1 API 443 SL1 API Access
ServiceNow API 443 ServiceNow API Access
SL1 Database 7706 SL1Database Access

Architecture Overview for ServiceNow SyncPacks SL1

The following diagram details the various elements that are contained in SL1 and the PowerFlow system, and how PowerFlow sits between the core SL1 platform and an external data platform:

The following diagram provides an example of the high-level architecture of a PowerFlow system with High Availability, Disaster Recovery, and a proxy configured:

SL1 and ServiceNow Terminology

The following table lists the different names for the shared elements in SL1 and ServiceNow:

SL1 ServiceNow

Asset, Custom Attribute

Asset (ITAM)

Device

CI (Configuration Item)

Discovery Session

Service Request, Catalog Request

Event

Incident, Event, or Case (depending on the SyncPack you are using)

Alert

Event

Organization

Company, Domain

Schedule, Maintenance Schedule

Change Request, Change Schedule

Topology, Relationships, Dynamic Component Mapping and Relationships (DCM+R)

Dependency View, Affected CIs

Dependency Map for ServiceNow SyncPacks

The following graphic describes which SyncPacks depend on other SyncPacks:

For more information about the "Base Steps" SyncPack, see Default SyncPacks.

Downloading, Importing, and Installing the SyncPack

A SyncPack file has the .whl file extension type. You can download the SyncPack file from the ScienceLogic Support site.

If you are planning to upgrade from an older version of this SyncPack to version 3.5.x, see Upgrading to Version 3.5.x.

Downloading the SyncPack

If you are installing or upgrading to the latest version of this SyncPack in an offline deployment, see Installing or Upgrading in an Offline Environment to ensure you install any external dependencies.

To locate and download the SyncPack:

  1. Go to the ScienceLogic Support Site at https://support.sciencelogic.com/s/.
  2. Click the Product Downloads tab and select PowerPacks & SyncPacks.
  3. In the Search field, search for the SyncPack and select it from the search results. The Release Version page appears.
  4. On the Files tab, click the down arrow next to the SyncPack version that you want to install, and select Show File Details. The Release File Details page appears.
  5. Click the Download File button to download the SyncPack.

After you download the SyncPack, you can import it to your PowerFlow system using the PowerFlow user interface.

Importing the SyncPack

You must import and install the "ServiceNow Base" SyncPack before uploading and installing any of the other ServiceNow SyncPacks.

If you are upgrading to version 3.5.0 or later of this SyncPack, be sure to install and activate version 1.5.0 or later of the "Base Steps" SyncPack. Older versions of the "Base Steps" SyncPack might cause installation errors for this SyncPack.

To import a SyncPack in the PowerFlow user interface:

  1. On the SyncPacks page () of the PowerFlow user interface, click Import SyncPack. The Import SyncPack page appears.
  2. Click Browse and select the .whl file for the SyncPack you want to install. You can also drag and drop a .whl file to the Import SyncPack page.
  3. Click Import. PowerFlow registers and uploads the SyncPack. The SyncPack is added to the SyncPacks page.
  4. You will need to activate and install the SyncPack in PowerFlow. For more information, see the following topic.

You cannot edit the content package in a SyncPack published by ScienceLogic. You must make a copy of a ScienceLogic SyncPack and save your changes to the new SyncPack to prevent overwriting any information in the original SyncPack when upgrading.

Installing the SyncPack

If you are upgrading to this version of the SyncPack from a previous version, make a note of any settings you made on the Configuration pane of the various PowerFlow applications in this SyncPack, as these settings are not retained when you upgrade. However, any mappings you added to the attribute_mappings section for the "Sync Devices from SL1 to ServiceNow" application are retained when you upgrade.

To activate and install a SyncPack in the PowerFlow user interface:

  1. On the SyncPacks page of the PowerFlow user interface, click the Actions button () for the SyncPack you want to install and select Activate & Install. The Activate & Install SyncPack modal appears.

    If you try to activate and install a SyncPack that is already activated and installed, you can choose to "force" installation across all the nodes in the PowerFlow system.

    If you do not see the PowerPack that you want to install, click the Filter icon () on the SyncPacks page and select Toggle Inactive SyncPacks to see a list of the imported PowerPacks.

  1. Click Yes to confirm the activation and installation. When the SyncPack is activated, the SyncPacks page displays a green check mark icon () for that SyncPack. If the activation or installation failed, then a red exclamation mark icon () appears.
  2. For more information about the activation and installation process, click the check mark icon () or the exclamation mark icon () in the Activated column for that SyncPack. For a successful installation, the "Activate & Install SyncPack" application appears, and you can view the Step Log for the steps. For a failed installation, the Error Logs window appears.
  3. If you have other versions of the same SyncPack on your PowerFlow system, you can click the Actions button () for that SyncPack and select Change active version to activate a different version other than the version that is currently running.

Installing or Upgrading in an Offline Deployment

Use the following procedure if you are installing or upgrading this SyncPack in an offline deployment.

This release of the SyncPack requires the following external files for an offline deployment:

  • Jinja2-2.11.1-py2.py3-none-any.whl, available at this location at pypi.org.
  • MarkupSafe-1.1.1-cp37-cp37m-manylinux1_x86_64.whl, available at this location at pypi.org.

To upload the required external files:

  1. After downloading the two required external files, SCP the files to the master node.

  2. Run the following commands on the host:

    devpi use 'https://<is_username>:<is_password>@<is_hostip>:3141/isadmin/dependencies'

    devpi login <is_username> --password=<is_password>

    cd /tmp/

    devpi upload Jinja2-2.11.1-py2.py3-none-any.whl

    devpi upload MarkupSafe-1.1.1-cp37-cp37m-manylinux1_x86_64.whl –force

    If you cannot run these commands on the host, you can instead run them on the pypiserver container.

  3. Perform a docker copy to both files (if you are running commands in the pypiserver container):

    docker cp <file1-location> $(docker ps -q -f name=iservices_pypiserver):/tmp

    docker cp <file2-location> $(docker ps -q -f name=iservices_pypiserver):/tmp

  1. Follow the steps in Installing the Synchronization PowerPack to install and activate this SyncPack.

Allowing Cross-Scoped Access in ServiceNow

When using custom tables, you might need to configure cross-scope access for the ScienceLogic plugin. The following examples contain errors that might occur when cross-scope access is required.

Example of an API response:

{"results":[{"error":{"message":"com.glide.script.fencing.access.ScopeAccessNotGrantedException: read access to ui_test_hardware not granted","detail":""},"status":"failure"}

Example of navigating to a URL directly from a web browser when cross-scope access is required:

In this example, the table requires that you grant access to the ScienceLogic Scope to allow the API call to run correctly. In the above example, the target table is u_test_hardware.

A ServiceNow account with System Administrator is required.

To grant access to the ScienceLogic Scope in ServiceNow:

  1. Log in to your ServiceNow instance.
  2. For newer releases of ServiceNow, click the globe icon () to change the scope. On older releases, click the Settings icon () and select the Developer tab. The Developer System Settings window appears.
  3. From the Application drop-down list, select ScienceLogic ServiceNow Integration.
  4. Close the Developer System Settings window and navigate to the Cross scope privileges page (System Applications > Application Cross-Scope Access). Make sure you are in the "ScienceLogic ServiceNow Application" scope and track these updates in an update set.
  5. Click the New button to create a new record on the Cross scope privileges page:
  6. Verify that the Source Scope and Application fields are set to ScienceLogic ServiceNow Integration. If they are not, repeats steps 2-3.
  7. Complete the following fields:
  • Target Scope. Specify the scope of the target table, such as Global. Be sure to verify the application to which the table belongs, and use that value as the target scope in this field.
  • Operation. Select Read.
  • Target Name. Specify the name of the target table.
  • Status. Select Allowed.
  • Target Type. Select Table.
  1. Click the Submit button.

For more information, see the Cross-scope privilege record topic in the ServiceNow documentation.

Installing the "ScienceLogic SL1: CMDB & Incident Automation" Application in ServiceNow

You must install the "ScienceLogic SL1: CMDB & Incident Automation" application on the ServiceNow instance to enable this SyncPack. The "ScienceLogic SL1: CMDB & Incident Automation" application is also known as the "Certified" or "Scoped" application.

Version 1.0.76 and later of the "ScienceLogic SL1: CMDB & Incident Automation" certified application includes updates to the ServiceNow Identification & Reconciliation Engine (IRE). As a result, the latest "ScienceLogic Domain Separation (Global)" update set is required if your ServiceNow instance is domain-separated.

Ask your ScienceLogic contact for access to this update set.

In version 1.0.76 and later of the "ScienceLogic SL1: CMDB & Incident Automation" application, the Incident portion of the application was turned off by default as part of an ongoing effort to make each individual application easier to support. Please note that the none of the Incident content was removed, but it is no longer enabled by default.

  • For users of the "ServiceNow CMDB" SyncPack, there will be no impact, as the Incident portion is turned off by default in version 1.0.76 of the "ScienceLogic SL1: CMDB & Incident Automation" application. For more information about turning Incident features on and off, see below.
  • ScienceLogic strongly recommends that users of the "ServiceNow Incident" SyncPack migrate to the "ScienceLogic SL1: Incident Automation" application. You can download this application from the ServiceNow Store at https://store.servicenow.com.
  • In future releases of the "ServiceNow Incident" SyncPack, you will need to download and install the "ScienceLogic SL1: Incident Automation" application to get any updates to the Incident module. The two SyncPacks and their corresponding applications will be completely separate going forward.

Requesting and Installing the Certified Application

You must first request the "ScienceLogic SL1: CMDB & Incident Automation" application from the ServiceNow Store, and then you can install it. You must have a ServiceNow HI Service Account to request this application and download it onto your ServiceNow instance.

To request and install the certified application:

  1. Go to the ServiceNow Store at https://store.servicenow.com and search for "ScienceLogic SL1".
  2. Select the "ScienceLogic SL1: CMDB & Incident Automation" application. The detail page for the application appears.
  3. Click the Get button and log in with your HI credentials.
  4. After the request is approved, log in to ServiceNow as an administrator and navigate to Application Manager (System Applications > Applications or My Company Applications).
  5. Click Downloads in the menu header or search for "ScienceLogic".
  6. Click the version drop-down for the "ScienceLogic SL1: CMDB & Incident Automation" application listing to make sure you are using the correct version of the application that is compatible with your version of this SyncPack.
  7. Click the Install button for the application. The installation is complete when the button changes to Installed.
  8. In the filter navigator, search for "ScienceLogic" and locate the application in the left-hand navigation menu to verify that the application was installed. You might need to log out of ServiceNow and log in again to see the updated left-hand navigation menu.

Incident Features Turned Off in Version 1.0.76 of the Certified Application

The following elements in version 1.0.76 of the "ScienceLogic SL1: CMDB & Incident Automation" application were turned off by default.

Table Transform Maps

To reactivate the following transforms:

  1. In ServiceNow, go to Systems Import Sets > Administration > Transform Maps.
  2. Search for ScienceLogic Incident or ScienceLogic Event.
  3. For ScienceLogic Incident and ScienceLogic Event, the Active field was unchecked. To continue to use one or both of these transforms, check the Active box.

Application Modules

To reactivate the following application modules so they display again in the Application Menu:

  1. In ServiceNow, go to System Definition > Application Menus.
  2. Search for ScienceLogic with filter Application = ScienceLogic ServiceNow Integration.
  3. You can reactivate the following application modules in the module Related Lists section:
  • Event: To continue to use the Module, check the Active box.
  • Event Properties: To continue to use the Module, check the Active box.
  • Events: To continue to use the Module, check the Active box.
  • Severity Lookup Rules: To continue to use the Module, check the Active box.

Creating a ServiceNow Group

For best practice and security, create a dedicated ServiceNow account that has restricted access to only the groups, access control lists (ACLs), and roles needed for ScienceLogic integration.

To create a ServiceNow Account for ScienceLogic Incident management:

  1. In ServiceNow, go to the Groups page (System Security > Users and Groups > Groups) and click New. A New record page appears.
  2. In the New record page, type the group name and any additional information. Name is the only required field.
  3. Click Submit.
  4. Select the new group from the Groups page, and at the bottom of the Group record, select the Roles tab and click Edit.
  5. Search for x_sclo_scilogic.Admin and move it to the Roles List column using the arrow buttons.
  6. Click Save. Your ServiceNow Group now has an assigned Role.
  7. Next, create a ServiceNow user to use with this Group. See the following procedure for the details.

Creating a ServiceNow User

The ServiceNow user you create in this procedure will not be able to log into the ServiceNow user interface with the username and password you give this user. However, you will use the username and password in the relevant configuration objects in the PowerFlow user interface to run applications. For more information about configuration objects, see Creating and Aligning a Configuration Object.

To create a ServiceNow Account:

  1. In ServiceNow, go to the Users page (System Security > Users and Groups >  Users) and click New. A New record page appears.
  2. Complete the following fields:

  • User ID. Type a user ID. Required.
  • First Name. Type the user's first name.
  • Last Name. Type the user's last name.
  • Password. Type a password. Required.
  • Active. Select this checkbox. Required.
  • Web Service Access Only. Select this checkbox. Required.
  • Time Zone. Select GMT. Required.
  • Date Format. Select System (yyyy-MM-dd).
  1. Right-click the gray header and click Save to save the user.
  2. Select the Groups tab at the bottom of the record and click the Edit button.
  3. Find the group you created previously and move the group to the right-hand column using the arrow buttons.
  4. Click Save. After the user has been added to the group, you can see their Roles and Groups at bottom of the record.

NOTE: As a best practice, you should use a non-administrator ServiceNow user for the PowerFlow configuration object.

Installing and Activating ServiceNow Plugins

This SyncPack requires the "ServiceNow Configuration Management for Scoped Apps (CMDB)" plugin (com.snc.cmdb.scoped), which gives the ScienceLogic scoped application access to the Identification Engine APIs. You will need to install this plugin on your ServiceNow instance.

In addition, ScienceLogic strongly recommends that you install the "CMDB CI Class Models " plugin (sn_cmdb_ci_class). This plugin contains all new class models provided by ServiceNow.

To install and activate plugins in ServiceNow, you must have ServiceNow Instance administrator rights.

To install one or both of the plugins in ServiceNow:

  1. In ServiceNow, log in and navigate to Plugins (System Definition > Plugins). This page is only available with administrative rights.

  2. Search for a plugin by its name or its ID (such as sn_cmdb_ci_class) and select the plugin. The options to Install or Update appear, depending on the status of the plugin:

  • Install. Installs the plugin in ServiceNow if it has not been installed before. After you install the plugin, the button is grayed out and the text changed to Installed.
  • Update. Shows that newer versions of the plugin are available.

  1. Click Install or Update to complete the installation.

Enabling the ServiceNow Identification and Reconciliation Module

This SyncPack uses the "ServiceNow Identification and Reconciliation" module to create and de-duplicate CI records. PowerFlow builds a JSON-formatted string that is sent to the "ServiceNow Identification and Reconciliation" module. The following link provides additional detail about the formatting of the JSON-formatted string: IdentificationEngineScriptableApi.

Version 3.5.0 and later of this SyncPack uses enhanced versions of the IdentificationEngine API: createOrUpdateCIEnhanced and identifyCIEnhanced.

The JSON-formatted string is sent directly to a custom-scripted API endpoint and run through the IdentificationEngineScriptable API. Identification (Insert or Update) of Configuration Items (CIs) is handled by the ServiceNow Identification and Reconciliation module.

For more information about how SL1 and ServiceNow work with the ServiceNow Identification and Reconciliation module to discover and module other applications, such as VMware, see Mappings between SL1, ServiceNow, and Other Applications.

For more information about the "ServiceNow Identification and Reconciliation" module, see CMDB Identify and Reconcile. See also Reconciliation Rules, CMDB Identification Rules, and Identification engine error messages.

As a best practice, do not use information for identification that is specific to only ScienceLogic. An example is the device ID (DID) | SL1 ID, which is a number that SL1 automatically assigns and is only unique to that specific SL1 system.

Configuring Service Rules for Device Sync

The default device relationships are based on ServiceNow defaults. Hardware defaults to SNMP OID Classifications (discovery_snmp_oid). vCenter, File systems and network adapters are all matched against ServiceNow Discovery.

The ServiceNow CMDB SyncPack utilizes class hierarchies to build relationships in ServiceNow. This requires building service rules (containment rules and hosting rules) in ServiceNow to correctly identify dependent CIs during the business discovery process and service mapping. Containment rules describe which CIs are contained by a given CI. Hosting rules describe the environment on which a CI runs.

ScienceLogic recommends packaging all of the service rules into a ServiceNow update set so that you can be easily package and deploy these changes across environments. For more information, see Creating a ServiceNow Update Set.

These rules or "mappings" are defined in the "Sync Devices from SL1 to ServiceNow" application in the PowerFlow user interface. These mappings connect an SL1 device class to a ServiceNow CI class, which determines the CI class that ServiceNow uses when creating the CI in ServiceNow.

For more information about the "ServiceNow Identification and Reconciliation" module, see CMDB dependent relationship rules and CMDB Identification Rules at the ServiceNow website.

For example, if you experience error messages about missing relationships in ServiceNow when you run the "Sync Devices from SL1 to ServiceNow" application in the PowerFlow user interface, you might be missing certain containment rules or mappings that are needed to complete the export process:

Containment Rules

Containment rules are chained to each other in a group, with a CI type that is the top-level (root) parent of the group.

To create containment rules:

  1. In ServiceNow, type "cmdb_metadata_containment.list" in the filter navigator to access the CMDB Metadata Containment Rules page.
  2. Click New. A new CMDB Metadata Containment Rules record appears.
  3. Complete the following fields:
  • Configuration item class. Specify the child CI class.
  • Relation type. Specify the relationship type. The common relationship types used by the ServiceNow integration are "contained" or "contained by", depending on your CMDB. Click the magnifying glass icon to select the correct value.
  • Parent. Specify the parent CI class.

  1. Click Submit.
  2. In the PowerFlow user interface, go to the Applications page and manually run the "Cache ServiceNow CIs and SL1 Device Classes" application.
  3. Run the "Sync Devices from SL1 to ServiceNow" application and make sure that no errors exist due to missing CI relationships.

Hosting Rules

Hosting rules can only be one level, and they always involve resources such as physical or virtual hardware.

  1. In the ServiceNow filter navigator, type "cmdb_metadata_hosting.list" to view the CMDB Metadata Hosting Rules page.
  2. Click New. A new CMDB Metadata Hosting Rules record appears.
  3. In the New Metadata Hosting Rules record, complete the following fields:
  • Parent type. Specify the parent CI class.
  • Child type. Specify the child CI class.
  • Relation type. Specify the relationship type. The common relationship types used by the ServiceNow integration are "Hosts" or "Hosted on", depending on your CMDB. Click the magnifying glass icon to select the correct value.
  1. Click Submit.
  2. Add any additional containment and hosting rules that are needed to build the CI relationships in ServiceNow.
  3. In the PowerFlow user interface, go to the Applications page and manually run the "Cache ServiceNow CIs and SL1 Device Classes" application.
  4. Run the "Sync Devices from SL1 to ServiceNow" application and make sure that no errors exist due to missing CI relationships.

Creating a ServiceNow Update Set

ScienceLogic recommends packaging the service rules into a standalone ServiceNow update set that you can export if needed. An update set is an XML file containing a group of customizations that can be moved from one ServiceNow instance to another, similar to the way you can use a PowerPack in SL1 to move content from one SL1 system to another.

This update set should include any changes or configurations to the service rules for the ServiceNow Identification and Reconciliation Module.

To create a standalone update set in ServiceNow:

  1. In ServiceNow, go to the Update Sets page (System Update Sets > Local Update Sets) and click New. A new Update Set record appears.
  2. Complete the following fields:

  • Name. Specify a name that describes the rules of this update set.
  • State. Set to In Progress.
  • Application. Set the application scope to Global.
  • Complete the remaining fields as needed.

  1. Click Submit or Submit and Make Current.
  2. If you selected Submit and Make Current, go to step 6.
  3. If you clicked Submit, you can select the update set in the picker in the header or navigate to the update set and select Make This My Current Set in the Related links section. You are now ready to make changes in your ServiceNow Instances.
  4. When you are done with all updates in the update set, change the update set State field to Complete.

Adding Service Rules to an Update Set

If you submitted your new update set and made it "Current" in Creating a ServiceNow Update Set, skip this step and go to Exporting an Update Set.

If you did not make your update set current, you will need to identify your current update set and move all of the service rules you need into your update set. You can find this information by clicking the globe icon () on the ServiceNow navigation bar and reviewing the contents of the drop-down.

All of the service rules that you defined are tracked in the update set record under the Customer Updates tab.

To add all created service rules to your update set:

  1. In ServiceNow, go to the Update Sets page (System Update Sets > Local Update Sets) to view a list of update sets on the ServiceNow instance.
  2. Identify your current update set, which should have all of the created service rules tracked.
  3. Identify the self-created update set that you want to contain all the service rules. This is the update set that you want to export.
  4. Select the current update set that has all of the already-created service rules.
  5. On the Customer Updates tab, identify all of the records with a Type of either CMDB Metadata Containment Rules or CMDB Metadata Hosting Rules.
  6. Select each of the relevant service rule records and set the Update set field to match the update set you want to export. Click the magnifying glass icon to select the correct value.
  7. Click Update.
  8. Repeat steps 6-7 until all relevant containment and hosting rules are in the new update set, and then go to Exporting an Update Set.

Exporting an Update Set

After you have created your update set and defined the service rules, mark your update set as Complete and export it to an XML file.

To export an update set:

  1. In ServiceNow, go to the Update Sets page (System Update Sets > Local Update Sets) to view a list of update sets on the ServiceNow instance.
  2. Select your update set from the list.
  3. Set the State to Complete and click [Update].
  4. From the Update Sets page, select your completed update set from the list.
  5. Under the Related Links section, click Export to XML.
  6. Save the downloaded XML file.

Installing the ScienceLogic Domain Separation (Global) Update Set in ServiceNow

If your ServiceNow environment is domain-separated, where the data, processes, and administrative tasks have been organized into logical groupings called domains, you will need to install the latest version of the "ScienceLogic Domain Separation (Global)" update set in ServiceNow. This update set is not included in the "ScienceLogic SL1: CMDB & Incident Automation" application (also called the Certified application).

Ask your ScienceLogic contact for access to this update set.

For more information about ServiceNow domain separation, see Using ServiceNow Domain Separation with PowerFlow.

If your ServiceNow environment does not use domain separation, you can skip this topic.

Overview of the Update Set

The "ScienceLogic Domain Separation (Global)" update set contains the following items:

  • Scripted REST API
  • Scripted REST Resource
  • Scripted REST Query Parameter
  • Scripted REST Query Parameter Association
  • Script Include

This update set completely separates the ServiceNow Identification Engine REST resource that is used in the "ScienceLogic ServiceNow Integration" application and all of the required resources and duplicates it in the Global scope.

A Scripted REST Service in the Global application is a direct copy of the application endpoint with a new name: api/10693/sciencelogic_domain_separation. This REST Service includes only one Resource: Device IdentificationEngine POST. This resource works exactly like the application version, but it points to the new Script Include "SciLoDomainSepUtil". This version of the REST resource takes the same formatted JSON as the Certified application.

The Script Include "SciLoDomainSepUtil" includes all of the functionality needed to run the ServiceNow Identification Engine API.

Additional resources for the ServiceNow API:

The only resource shared with this update set and the Certified application is the Device Properties page. These properties are located in the Certified application at ScienceLogic > Device > Device Properties.

Limitations of the Identification Engine

For more information about how the Identification Engine handles incoming payloads in domain-separated systems, see the following ServiceNow Knowledge Base article: KB0695949.

The payload and the user domain must match, or the ServiceNow Identification Engine (IDE) will by default insert the CMDB record. Safeguards within the PowerFlow Device Sync application were put in place for payloads that have relationships. The application will drop the payload if all Configuration Items do not share the same domain.

Installing the Update Set

To install the "ScienceLogic Domain Separation (Global)" update set:

  1. Ask your ScienceLogic contact for access to this update set.
  2. In ServiceNow, navigate to the Retrieved Update Sets page (System Update Sets > Retrieved Update Sets).
  3. Click the Import Update Set from XML link under Related Links.
  4. Click Browseand navigate to the update set XML file you downloaded. Select the XML file and click Upload.
  5. After the file is uploaded, the Retrieved Update Sets page appears. Click the link for the "ScienceLogic Domain Separation (Global)" update set. The Retrieved Update Set page appears.
  6. Click Preview Update Set . After the preview set runs, a status page appears.
  7. Ensure that "Success" appears in the Completion code field. If "Success" does not appear in the Completion code field, contact ScienceLogic Support to assist with reviewing any conflicts that might exist. Do not proceed until those conflicts are resolved and "Success" appears in the Completion code field.
  8. Click Commit to commit the fix script after running the preview set.
  9. Before you start to sync devices, you must select the Domain Separation option on the Configuration pane in the "Sync Devices from SL1 to ServiceNow" application. This option ensures that PowerFlow gets re-pointed to the API endpoint after you install the "ScienceLogic Domain Separation (Global)" update set. For more information, see Running a Device Sync.

Configuring Domain Separation without Using the Update Set

You can sync to a domain-separated ServiceNow CMDB without installing "ScienceLogic Domain Separation (Global)" update set, but you will need to manage multiple configuration objects and schedules in PowerFlow. You will need to create multiple schedules, and each schedule will reference a unique configuration object that is specific to a specific domain in ServiceNow.

Creating the Configuration Objects for the ServiceNow Domains

To create a configuration object for each ServiceNow domain:

  1. In the PowerFlow user interface, go to the Configurations page and click Create Configuration:

  2. Click Toggle JSON Editor to open the JSON viewer.

  3. In the Configuration Data section, make sure that this object is configured with a ServiceNow domain-specific user. For example:

     {
    "encrypted": false,
    "name": "snow_user",
    "value": "domainA_user"
  },
  {
    "encrypted": false,
    "name": "snow_password",
    "value": "domainA_password"
  },

  4. Update the include_orgs value with a list of organizations that map to the domain to which you are syncing. 

      {
    "encrypted": false,
    "name": "include_orgs",
    "value": [1,2,3]
  },

  5. Define the class mapping for the configuration object. For example: 

     {
    "encrypted": false,
    "name": "mapping",
    "value": {
              "cmdb_ci_computer": [
                "IBM | IBM OS/400 V5R1M0",
                "IBM | Main Frame",
                "IBM | AIX RS/6000"
              ],
              "cmdb_ci_esx_resource_pool": [
                "VMware | Resource Pool"
              ]
            }
  },

  6. The region value should be unique to SL1 stack that is being synced. For example: 

      {
    "encrypted": false,
    "name": "region",
    "value": "StackA"
  }
  7. Repeat steps 1-6 for each ServiceNow domain you want to use.

Example JSON Code for a Configuration Object

The following JSON code is for an example configuration object:

[
  {
    "encrypted": false,
    "name": "sl1_host",
    "value": "SL1_StackA"
  },
  {
    "encrypted": false,
    "name": "sl1_db_host",
    "value": "${config.sl1_host}"
  },
  {
    "encrypted": false,
    "name": "sl1_password",
    "value": "password"
  },
  {
    "encrypted": false,
    "name": "sl1_user",
    "value": "StackA_user"
  },
  {
    "encrypted": false,
    "name": "sl1_db_user",
    "value": "root"
  },
  {
    "encrypted": false,
    "name": "sl1_db_password",
    "value": "StackA_password"
  },
  {
    "encrypted": false,
    "name": "snow_host",
    "value": "example.service-now.com"
  },
  {
    "encrypted": false,
    "name": "snow_user",
    "value": "domainA_user"
  },
  {
    "encrypted": false,
    "name": "snow_password",
    "value": "domainA_password"
  },
  {
    "encrypted": false,
    "name": "include_orgs",
    "value": [1,2,3]
  },
  {
    "encrypted": false,
    "name": "mapping",
    "value": {
              "cmdb_ci_computer": [
                "IBM | IBM OS/400 V5R1M0",
                "IBM | Main Frame",
                "IBM | AIX RS/6000"
              ],
              "cmdb_ci_esx_resource_pool": [
                "VMware | Resource Pool"
              ]
            }
  },
  {
    "encrypted": false,
    "name": "region",
    "value": "StackA"
  }
  
]

Aligning a Schedule with a ServiceNow Domain

After you have created the configuration objects, you can define multiple schedules, one schedule for each domain. When scheduling the application, you will need to create multiple schedules, where each schedule uses a domain-specific configuration object.

When specifying a configuration object to use in the custom parameters, use the ID of the configuration object.

The following image shows how you can create a schedule that uses a specific configuration object using the Custom Parameters field in the PowerFlow Scheduler:

The following image shows how you could schedule Device Syncs for multiple ServiceNow domains:

Using ServiceNow Domain Separation with PowerFlow

The following topics provide more information about ServiceNow domain separation and how it relates to PowerFlow. For more information, see Domain separation in the ServiceNow Documentation.

When either multiple SL1 stacks or multiple ServiceNow systems are involved with PowerFlow, you should create an individual configuration object for each SL1 stack or ServiceNow system. Next, create an individual schedule for each configuration object. Each schedule should use a configuration object that is specific to that single SL1 stack or ServiceNow system. Creating copies of a PowerFlow application from a SyncPack for the purpose of distinguishing between domains is not supported, and will result in issues on upgrades.

If you get an error message stating that a device or CI has no domain_sys_id value, that means that the company for that CI has no domain.

User Setup

Company and domain setup is critical for the domain separation integration to work using the Identification Engine provided by ServiceNow. This solution requires only one user and will require proper setup depending on where the user is located within the domain tree.

Example 1

In the following example, ScienceLogic (1) is both the domain and the company. The ScienceLogic user service account is associated with ScienceLogic (2) company, and it will have access to all child domains. You do not need to set visibility to any domain. This is the best way to set up this user, because placing it in the top domain ensures that it always has access to all children:

Example 2

In the following example, Delos Inc. (1) is the company within the Delos Inc. domain. The PowerFlow service account is associated with the Delos Inc. (1) company. The Delos Inc. domain has no children domains, and if domain visibility is not assigned, PowerFlow will not properly update the CMDB. This setup works, but it requires that proper domain visibility is set up for the service account to work correctly.

Assigning visibility to MSP (3) will grant the service account access to all child domains. Assigning visibility to Weyland Corporation (4) will only allow access to the Delos Inc. domain and the Weyland domain; all other domains will not work.

Workflow

The API endpoint is based on the API query parameter “test” being true or not, which determines which Identification Engine API resource should be used. There are two primary avenues supplied with this REST resource: "createOrUpdateCI" or "identifyCI", and the only difference is that "identifyCI" does not commit the results:

The "getCreateOrUpdateCI" function uses the following workflow:

  1. Retrieves the current session Domain ID (sys_id).
  2. Sets the user Domain ID by creating an array of domain sys_id values and returning only the unique domains, or setting the domain if the array has only one unique domain.
  3. Submits the JSON formatted string to "createOrUpdateCI()" or "identifyCI()" API.
  4. Sets the user's Domain ID back to the original session ID.

The following image shows this workflow: