Managing, Updating, and Uninstalling the Snowflake Connector for ServiceNow

These sections describe typical tasks you might need to perform after installing and configuring the connector.

Updating the Refresh Token Used by the Connector

If you set up the connector with OAuth authentication, you must update the refresh token regularly. Otherwise, once the token expires, the connector cannot access ServiceNow anymore. By default, the token expires 90 days after its generation.

If you configure email alerts for the connector, you get a reminder to update the refresh token on the first day of each month. If the token expires, you get an email once the connector encounters issues accessing ServiceNow.

Updating the Refresh Token for the Connector Installed Using Snowsight

To update the refresh token if the connector was installed using Snowsight, do the following:

  1. Sign in to Snowsight as a user with the ACCOUNTADMIN role.

  2. In the left navigation, select Marketplace.

  3. Search for the Snowflake Connector for ServiceNow, then select the tile for the connector.

  4. In Connections, select the ellipsis button, then select Refresh token.

    Note

    Make sure you are logged in to ServiceNow as the same user the connector was initially configured with. You can check the currently logged in user in the upper right corner of the dialog.

  5. To confirm that you allow the connector to connect to your ServiceNow account, select Allow in the dialog.

    The refresh token is now updated.

To learn how to update the refresh token using SQL commands, refer to Updating the Refresh Token Using SQL Commands.

Updating the Refresh Token Using SQL Commands

To update the refresh token using SQL commands do the following:

  1. Get a new OAuth refresh token. Make sure you use the same client_id, client_secret and user credentials that the connector is using at the moment.

  2. Find out the fully qualified name of the secret object by querying the GLOBAL_CONFIG view:

    SELECT value:secret FROM GLOBAL_CONFIG WHERE key = 'connection_config';
    
    Copy
  3. Update the secret object by running the ALTER SECRET commands, changing the following parameters:

    • Set OAUTH_REFRESH_TOKEN to the OAuth refresh token that you retrieved in the first step.

    • Set OAUTH_REFRESH_TOKEN_EXPIRY_TIME to the refresh token expiration timestamp in UTC timezone. You can calculate this by adding the refresh token lifespan from ServiceNow to the date when the token was issued. By default, the token expires in 100 days.

    For example, to update the secretsdb.apiauth.servicenow_creds_oauth_code secret, run the following command:

    ALTER SECRET secretsdb.apiauth.servicenow_creds_oauth_code SET OAUTH_REFRESH_TOKEN = '34n;vods4nQsdg09wee4qnfvadH', OAUTH_REFRESH_TOKEN_EXPIRY_TIME = '2022-01-06 20:00:00';
    
    Copy

    Note

    To update the secret, you must use the role with OWNERSHIP privilege.

Deleting Objects Created During the Installation Using Snowsight

Removing the connector database does not delete the ingested data that is stored in a separate database or the objects that were created during the installation performed using Snowsight.

To see objects created during the installation, do the following:

  1. Sign in to Snowsight as a user with the ACCOUNTADMIN role.

  2. In the left navigation, select Marketplace.

  3. Search for the Snowflake Connector for ServiceNow, then select it.

  4. In the page for the Snowflake Connector for ServiceNow, locate the Connector Objects area.

To delete those objects run the DROP <object> command.

For example, to delete the secret, run the DROP SECRET statement.

Uninstalling and Deleting Objects Created During the Installation Manually

Removing the connector database does not delete the ingested data that is stored in a separate database nor the objects that you created when installing the connector. These include:

To delete those objects run the DROP <object> statement. For example, to delete the secret, run the DROP SECRET statement.

To delete the Snowflake ServiceNow Connector, use DROP DATABASE:

DROP DATABASE <database_name>;
Copy

Where

database_name

Specifies the name of the database created during the connector installation.

For example, to delete a connector installed in database named my_connector_servicenow, run the following command:

DROP DATABASE my_connector_servicenow;
Copy

Deleting Tables

To delete a table (for example enabled unintentionally) and not display it in the views for monitoring the connector, use the following procedure:

CALL DELETE_TABLE('<table_name>');
Copy

Where:

table_name

Specifies the name of the table to be deleted. This table must be disabled and not in the process of reloading.

Note

The DELETE_TABLE procedure does not remove the objects created for this table in the database and schema that contain the ServiceNow data in Snowflake (raw data table, event logs table, and flattened views). You can drop these objects manually.

Upgrading the Connector

This section describes how to upgrade the connector from your Snowflake account.

Currently, the connector does not upgrade automatically. To upgrade your connector to newest version, call the procedure named RUN_UPGRADE:

CALL RUN_UPGRADE();
Copy

You can perform this upgrade at any time (provided that no one else is configuring the connector at the same time).

The upgrade should complete quickly. The upgrade temporarily disables the ingestion of the ServiceNow data. When the upgrade completes, the connector resumes the ingestion of data.

Note

When running the upgrade, make sure that no one is configuring the connector at the same time.

Reinstalling the Connector With the Same Database and Schema for ServiceNow Data

If you removed the connector but left the database and schema containing the ingested data intact, you can later reinstall the connector and resume data ingestion from the point where the connector was last running.

Note

To ensure data consistency, wait until the current ingestion completes and stop the connector before uninstalling the connector.:

  1. Query the TABLES_STATE view and verify that none of the tables is currently in RUNNING state:

    SELECT * FROM TABLES_STATE;
    
    Copy
  2. If the connector is ingesting data, wait for the ingestion to complete. This is important to ensure full data consistency.

  3. If no ingestion is currently in progress, stop the connector by calling the following stored procedure:

CALL STOP_CONNECTOR();
Copy

After removing the connector, you can reinstall the connector by:

During the installation process:

  • Provide the previously used database and schema.

  • Provide the same ServiceNow instance URL.

For the other arguments, you can reuse the objects that you created when installing the connector, or you can use new objects.

Note

You must also repeat the steps to configure the connector again, including the step to enable the ServiceNow tables for synchronization.

If you create new objects or if you create a new custom role for the connector, you must ensure that the role has the required privileges. For details, see the next sections:

Reusing the Same Custom Role for the New Connector

If you are using the same custom role for the connector that you used with the previous installation of the connector, you only need to grant the required privileges on any new objects that you created when initially installing the connector. The role should already have the required privileges on any other objects that you are reusing, including the tables and views in the database and schema containing the ingested data.

You must also grant the custom role to the connector as part of a new installation.

Note

If you run CREATE OR REPLACE ROLE on the custom role, the role is technically a new object with the same name. You must follow the steps in the section below.

Using a New Custom Role for the New Connector

If you plan to use a new custom role for the reinstalled connector, you must grant all the privileges listed under Creating a Custom Role for the Connector to that role, and you must ensure that the new role has the required privileges on the tables and views in the database and schema containing the ingested data.

To grant the required privileges, grant OWNERSHIP on the tables and views from this schema to the new custom role.