Preparing your ServiceNow® instance¶

Prerequisites¶

Complete the following steps to set up your ServiceNow instance:

1. Ensure the ServiceNow instance is publicly available. The connector does not work with instances hidden behind a VPN.

2. Identify the ServiceNow tables that contain the data that you plan to ingest into Snowflake.

3. Identify or create the ServiceNow user for the connector.

   To connect to the ServiceNow instance, the connector must authenticate to the instance as a ServiceNow user. Choose a ServiceNow user that meets the following requirements:

   • The username cannot contain a colon (:).

   • The user must have read access to all records in the ServiceNow tables that you plan to ingest. Access control lists (ACLs) should not hide any records in these tables from this user.

   • The user must have read access to all rows in the sys_db_object (with the fields name, super_class, sys_id), sys_glide_object (with the fields name, scalar_type, sys_id), and sys_dictionary (with the fields element, internal_type, name, sys_id) tables to enable schema detection.

   • The user must have read access to all rows in the sys_table_rotation table (with the name and sys_id fields), so that the connector can use the proper ingestion strategy.

   • The user must have access to the sys_updated_on field in the sys_db_object, sys_glide_object, sys_dictionary, sys_table_rotation and journal tables. Otherwise, the tables are loaded using less cost-effective truncate and load ingestion mode.

     Note

     Configuring the connection in Snowsight using the OAuth authentication to ServiceNow is possible only with interactive user. The ServiceNow user is interactive if the Web service access only setting is disabled for the user.

     You can use the OAuth authentication with non-interactive users only if you configure the connection with SQL commands. In this case, you cannot log in to ServiceNow or get the OAuth refresh token using Snowsight.

4. If you plan to ingest and synchronize a ServiceNow table that has a sys_updated_on column, set up an index on that column. For information on setting up the indexes, see the Create a Table Index in the ServiceNow documentation.

   After you create the index through the user interface, it may take time for the index to be constructed. The indexing process runs as a background task.

   If your instance has large tables, Snowflake recommends contacting ServiceNow customer support to ask about the best approach to indexing large tables.

5. (Optional) If you plan to use the OAuth authentication method, and you have the read-only role assigned to your ServiceNow user, make sure the glide.security.snc_read_only_role.tables.exempt_create system property has the oauth_credential table in its value list.

   Create or edit the glide.security.snc_read_only_role.tables.exempt_create property in the sys_properties table. For more details on editing this property, see ServiceNow Knowledge Base.

   To learn how to add a new system property, see Add a system property in the ServiceNow documentation.

6. (Optional) Some connector procedures that are not essential to core functionality use the ServiceNow endpoint <service_now_instance>/<table_name>.do?SCHEMA to retrieve table schemas. This endpoint requires the admin role. For more information about this role see Base system roles in the ServiceNow documentation. Configuring the connector with a user without this role will prevent the execution of procedures based on this endpoint. Affected procedures have appropriate notes regarding this requirement.

7. (Optional) To enable deleted records to be propagated, either use the sys_audit_delete table or a custom journal table as the source of information about deleted records.

   Note

   Please note that the connector must have access to all journal table records or the installation may fail. Otherwise record deletions in other tables may not be correct.

   If journal table rows are hidden by ACLs, connector behavior is unpredictable. Even if the installation is successful, some deletions may not be correctly synchronized at later points in the process.

   • To use sys_audit_delete:

     1. Set the no_audit_delete dictionary attribute to false.

     2. Make sure that the ServiceNow user for the connector has access to the sys_audit_delete table and the documentkey, tablename, sys_id, and sys_created_on fields in this table.

   • To use a custom journal table:

     1. Create a journal table named snowflake_connector_journal with string columns named documentkey and tablename.

     2. Make sure that the ServiceNow user for the connector has access to the snowflake_connector_journal table and the u_documentkey, u_tablename, sys_id, sys_created_on fields in this table.

     3. Create a script include named RecordChange with the following code:

        var RecordChange = Class.create();
        
        RecordChange.prototype= {
          initialize :function() {},
          captureChange :function(tableName, docID) {
            var changeCapture = new GlideRecord('u_snowflake_connector_journal');
            changeCapture.initialize();
            changeCapture.setValue('u_documentkey', docID);
            changeCapture.setValue('u_tablename', tableName);
            changeCapture.insert();
          },
          type :'RecordChange'
        };
        

        Copy

     4. Define a business rule to capture the deletion of the record:

        (function executeRule(current, previous /*null when async*/) {
            new RecordChange().captureChange(current.getTableName(), current.getUniqueValue());
        })(current, previous);
        

        Copy

     5. For each table for which you want to propagate deleted records, configure this business rule to be run after a record is deleted.

Next steps¶

After completing these procedures, follow the steps in Installing and configuring the connector with Snowsight or Installing and configuring the connector Using SQL Commands.