Contents

• Overview
• General Troubleshooting Step - Viewing the SIM Data
• General Troubleshooting step - Viewing ServiceNow Upgrade logs
• Commonly Seen Issues
  • Invalid DataSource Sys Id ' '
  • Missing Records / Data
  • ESX Hosts Not In Table
  • A task was cancelled error 

Overview

This guide provides some guidance to follow when diagnosing ServiceNow Connector issues.  If you are setting up the connector please start by reviewing the Snow for ServiceNow connector product guide.

Below is an reference diagram showing the aggregation of ServiceNow data:


 

General Troubleshooting Step - Viewing the SIM Data

A useful troubleshooting step is to view the raw data that Snow Integration Manager (SIM) aggregates from Snow License Manager (SLM).

There are some options you can use to verify the data in ServiceNow 4.0+, but in contrast to previous versions the CSV files are removed from the instance after they have been processed.

Check the staging table in ServiceNow

• If the staging table has data, this means that the CSV files have been imported and processed correctly.
• The staging data should be a reflection of what is in the CSV files, so any data missing here means it is missing in the CSV. 

Check the CSV files

• The CSV files are processed in a queue system.
• While they are awaiting to get processed, they are available on data sources used by our apps.
• In the Import Status page you can simply click on each file as long as they are in the queue list.

How to extend your access to the CSV files

It may be useful when troubleshooting to extend the amount of time that the CSV files are available to download so you can view them. 

• To extend the amount of time where the CSV are available for download, you can simply temporarily deactivate the scheduled import in ServiceNow that processes the files.
• As long as this is disabled, the files will not be removed.
• Simply activate the scheduled import again when you have completed gathering the required CSV files.

General Troubleshooting Step - Viewing ServiceNow Upgrade logs

When upgrading or installing a Snow for ServiceNow application, ServiceNow may intentionally “skip” applying some of the application's changes. This is to avoid data being lost by apps (for example if an app drops a table).

After changing any of application files (script includes, transform maps, etc) there will be a local record of the change in your instance.   If your later upgrade the Snow for ServiceNow app the changes from our apps may be “skipped” during the upgrade. This allows you keep any custom changes but may create a problem if the changes from the Snow for ServiceNow app upgrade are not fully applied.

During the Guided Setup some scheduled data imports must be activated. The action of activating these creates a local change to these records that are from our app. For some versions, (for example v4. 0.11 and v4.0.9), changes have been made to these, therefore the upgrade history must be reviewed to apply these changes.  The upgrade history should also be reviewed to ensure other changes are applied properly as well.

To review the upgrade history, do the following steps for both apps:

• Navigate to the Upgrade History module.
• Find the Snow for ServiceNow apps and open one.
• Check for any changes that are under the “Skipped changes to review”.

• For each of the skipped changes, evaluate whether you have done any modifications that must be kept.
• If you are unsure you may be able to use the “Revert to Base system” option after checking the colliding data first by using “Resolve Conflicts”.

• When using the “Resolve Conflicts” option, you will see a side-by-side comparison of the record from the Base System or the local “customized” changes.
• Check these thoroughly (also checking any changes to scripts) and review whether to revert to the base system or apply the base system changes to their customized record.
  • Keep full records of any changes made.
  • In most instances, we would ordinarily recommend to revert to the base system and then reapply any customized changes afterwards.
  • If they apply custom changes to their system, make sure to document them fully to help with future upgrades.

After the skipped change has been reviewed and dealt with, they can then set a resolution for the item.



The goal is to then review them all and choose the correct action depending on the requirements but to also include any changes coming from the apps.

 

Commonly Seen Issues

Invalid DataSource Sys Id ' '

The error Invalid DataSource Sys ID'' may be seen in the SIM logs.  How to locate log files.

• In our app, we have a REST resource defined that SIM queries to get the data source sys id.
  • You can view this by going to (their service now domain)/api/x_snsab_snow_catal/app.
• The data source we need is called “Snow Software Data Staging” and to output this for SIM, we query the sys_data_source table for this exact name.
  • Additionally, the import_set_table_name column must begin with either x_snsab_snow_catal or x_snsab_snow_sam_i (our application scope names).
• By going to this table, you should see the following:

• The import set table name may have other tables listed, the important part is that they start with either of the application scope names (x_snsab_snow_catal or x_snsab_snow_sam_i).
• Additionally ensure that the the scheduled import job has been reactivated by following the steps in the Snow for ServiceNow guided setup for Product and Service Catalog Update.

Missing Records / Data

• If data is not showing in the correct tables, check the Identity & Reconciliation logs. 
  • For example a customer had previously added ‘IMEI’ as a mandatory field for the CI_Computer table. Snow does not include IMEI numbers in the computer data and so every computer errored.  The issue was found by looking in the Identity & Reconciliation logs.
• To check the Identity & Reconciliation logs:
  • Within ServiceNow use the search bar on the left.
  • Type "logs" then go to "System Logs" and look for "Identity and Reconciliation." or "Identification Engine."
• Another potential cause of missing records is that business rules have been created that run as part of the catalog connector only (as these do not go through the same IRE process as other data sets). This can cause issues if the business rules are not set to update or modify which means Snow for ServiceNow cannot populate data if the record already exists. You can see these issues in the ServiceNow transform map logs. Refer to ServiceNow help / support for further guidance.

ESX Hosts Not In Table

• This issue can be the result of missing some instructions within the Guided Setup steps.
• The Guided Setup includes instructions to configure an appropriate Reconciliation Rule for ESX hosts because this is not provided out of the box.
• Errors seen in the Identification Engine can include "In payload missing minimum set of input values for criterion (matching) attributes from identity rule for table...".  Example:

• By default, the reconciliation for ESX is configured in this way:

• To resolve this issue create a new rule with a higher priority (the lower the number, the higher the priority) with attributes name and serial number.
  • NOTE: Additional rules may be required depending on your environment.

A task was cancelled error

Please read about how to resolve this issue here .