Troubleshooting – ServiceNow Integration Using Enhanced Generic Adapter

This section describes troubleshooting for the UCMDB-ServiceNow integration using the enhanced generic adapter.

When troubleshooting UCMDB-ServiceNow integration issues, make sure that the corresponding log severities are set for the Data Flow Probe. Change the content of the files in folder <Data flow probe>\conf\log in order to configure the logging correctly. The log files containing helpful information are these:

• <Data flow probe>\runtime\log\servicenow.generic.adapter.log – this one contains the log entries specific only to the adapter itself. See adapter.logger for information on how to enable this. It is recommended to set the log to TRACE level.
• <Data flow probe>\runtime\log\WrapperProbeGw.log – this one contains the log entries for everything happening on the Data Flow Probe itself.
• <Data flow probe>\runtime\log\fcmdb.adapters.log and <Data flow probe>\runtime\log\fcmdb.adapters.<integration_point_name>.log – these contain the log entries specific to the integration points themselves.

These are the common failures and ways how to resolve them:

1. PROBLEM: “Test connection” in the “Edit Integration Point” dialog brings up an error dialog

   Workaround: To resolve the issue, do the following:

   1. Make sure the Adapter Properties are set up correctly.
   2. Make sure the ServiceNow instance is accessible from the Data Flow Probe.
   3. Make sure the connector.class property in the adapter.properties file is set to REST connector.
   4. Check the adapter logs that the UCMDB request for connection test got to the adapter. If the request came through then in the logs, there should be an INFO entry "Testing ServiceNow connection". If the test was successful in the adapter itself, then in the logs there should also be an INFO entry "Test successful".

2. PROBLEM: Bringing up the mapping tool editor displays an empty “External Class Model”.

   Workaround: To resolve the issue, do the following:

   1. Check step 1.a through step 1.c.
   2. Check that the integration is activated in the Edit Integration Point dialog box.
   3. Check that the request came to the adapter from UCMDB. In the adapter log there should be an INFO entry "Getting class model" and later on the DEBUG entries "Populating ServiceNow schema", "Building CI types" and "Class model created". In case of an error on the adapter side, the adapter log will clearly show it.
   4. Check that the integration user has the required ServiceNow ACLs in order to read the required tables (see External Class Model Flow ).

3. PROBLEM: Some tables are missing from external class model.

   Workaround: To resolve the issue, do the following:

   1. Ensure the tables exist in ServiceNow.
   2. Ensure the tables are configured as part of the external class model in the adapter.properties file. The property you should check for this is class.model.table.prefixes. If this is not the case then the adapter disregards these tables. In order to display them you need to include the referenced tables in the external class model also. After this is done, restart the adapter in order to display these fields.
   3. In the adapter.properties file set the property class.model.incremental.update to false and see if this solves the problem.

4. PROBLEM: Some table fields are not displayed in external class model.

   Workaround: To resolve the issue, do the following:

   1. Ensure that the fields exist in ServiceNow for the tables and that the integration user has the required ACLs to retrieve these fields.
   2. Check if these fields are references to the tables that are not a part of the external class model (see the workaround for issue 3). If so, the adapter disregards these fields. In order to display them, you need to include the referenced tables in the external class model also. After this is done, restart the adapter in order to display these fields.
   3. In the adapter.properties file set the property class.model.incremental.update to false and see if this solves the problem.

5. PROBLEM: While executing the push job some or all of the UCMDB CIs are ignored.

   Workaround: To resolve the issue, do the following:

   1. Make sure the Adapter Properties are set up correctly.
   2. Make sure the ServiceNow instance is accessible from the Data Flow Probe.
   3. Check that the integration is activated in the Edit Integration Point dialog box.
   4. Make sure the connector.class property in the adapter.properties file is set to either SOAP or REST connector.
   5. Check that the request came to the adapter from UCMDB. If the request came from UCMDB to the adapter, then in the adapter log there should be an entry like "Executing pushTreeNodes ...”.
   6. In the mapping files, ensure that the CIs are properly mapped (see Push Integration Mechanism).
   7. In case of an error on the adapter side, all the logs mentioned above should clearly show the error.

   8. In case one of the HTTP requests to ServiceNow timed out, then do one of the following:

      • Lower the value of push chunk size in UCMDB, or
      • In case you are using SOAP connector, try to increase the glide.soap.request_processing_timeout property value in ServiceNow, or
      • In case you are using REST connector, then try to change the REST Request Timeout transaction quota. If this is not possible, then use the SOAP connector instead.

6. PROBLEM: While executing the push job duplicates are created in ServiceNow side for the UCMDB CIs.

   Workaround: In the mapping file, ensure that the push goes through import set tables and the correlation_id (or custom) fields are properly mapped to UCMDB global_id fields (see Push Integration Mechanism).

7. PROBLEM: While executing the push job, deleted CIs in UCMDB are not deleted from ServiceNow.

   Workaround: To resolve the issue, do the following:

   1. In ServiceNowConfig.xml configuration, make sure that a valid ServiceNow staging table to target table mapping is specified in CI/Relation Type Mappings (see Push Integration Mechanism).
   2. In case of an error on the adapter side, all the logs mentioned above should clearly show the error.

8. PROBLEM: While executing population, the CIs are not inserted into UCMDB.

   Workaround: To resolve the issue, do the following:

   1. Make sure the Adapter Properties are set up correctly.
   2. Make sure the ServiceNow instance is accessible from the Data Flow Probe.
   3. Check that the integration is activated in the Edit Integration Point dialog box.
   4. Make sure the connector.class property in the adapter.properties file is set to REST connector. Only REST is supported at the moment.
   5. Check that the request came to the adapter from UCMDB. If the request came from UCMDB to the adapter, then in the adapter log there should be an entry like "Executing populate ...”.
   6. In case of an error on the adapter side, all the logs mentioned above should clearly show the error.

9. PROBLEM: While executing the population job, the ServiceNow CI correlation_id (or custom) fields are not updated by the adapter.

   Workaround: To resolve the issue, do the following:

   1. Check if the population.return.global_id property in the adapter.properties file is set to false. If so, the adapter will not update the ServiceNow. Set this parameter to true.
   2. Ensure that the ServiceNow sys_id field is mapped to UCMDB CI sys_id property in the mapping file (see Population Flow).

10. PROBLEM: External class model takes a lot of time to load or refresh.

    Workaround: This is a common case. The ServiceNow class model is large, so a lot of time is spent in communication between the adapter and ServiceNow as well as between the adapter and the UCMDB. See Incremental Update for information about how to get around this issue.