Preparing Your ServiceNow Instance

Before installing the Snowflake Connector for ServiceNow, you must set up your ServiceNow instance.

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) 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.

    • 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.

Note

The connector is only able to synchronize deleted records if they are audited. Delete operations that do not call DBDelete.setWorkflow() are not ingested in Snowflake.

Refer to your ServiceNow product documentation for more information on using DBDelete.setWorkflow().

Also, note the following about deleted records:

  • Record deletions are not tracked for tables with the no_audit_delete=true dictionary attribute.

  • Record deletions from tables with a sys prefix are not tracked by default.

  • The connector can only ingest records deleted with cascade record deletion if the reference field is on an audited table. Refer to your ServiceNow product documentation for more information on cascade record deletion.

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