Preparing your ServiceNow® instance¶

ServiceNow® instance access¶

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

• If you are using IP Address Access Control for your ServiceNow® instance, you won’t be able to successfully install the connector. For more information see the community article.

ServiceNow® user¶

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 following tables in order to enable schema detection:

  • sys_db_object (with the fields name, super_class, sys_id),

  • sys_glide_object (with the fields name, scalar_type, sys_id),

  • sys_dictionary (with the fields element, internal_type, name, sys_id).

• The user must have read access to all rows in the following table in order to use the proper ingestion strategy:

  • sys_table_rotation (with the name and sys_id fields).

• The user must have read access to the sys_updated_on field in the below tables in order to not to use less cost-effective “truncate and load” ingestion mode:

  • sys_db_object,

  • sys_glide_object,

  • sys_dictionary,

  • sys_table_rotation,

  • journal table (usually sys_audit_delete).

Set up column indexes for optimized performance¶

If you plan to ingest and synchronize a ServiceNow® table that has a sys_updated_on field, we recommend setting 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 some 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.

Optional steps¶

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

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

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.