Managing, updating, and uninstalling the Snowflake Connector for ServiceNow®¶

Pausing and resuming the Snowflake Connector for ServiceNow®¶

The following sections describe how to pause and resume the connector.

CALL PAUSE_CONNECTOR();

CALL RESUME_CONNECTOR();

Changing the warehouse used by the connector¶

If you want to change the warehouse used by the connector or add a dedicated warehouse, do this by calling:

CALL UPDATE_WAREHOUSE('<warehouse_name>');

Copy

Where:

warehouse_name

Specifies the name of the warehouse that the connector should use.

Deleting tables¶

To delete table state data (including configuration, statistics, internal connector data, related tasks) and not display the table in the views for monitoring the connector, use the following procedure:

CALL DELETE_TABLE('<table_name>', <drop_related_objects>);

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.

drop_related_objects (optional)

Specifies whether to drop the related objects. If set to true, the procedure also drops all objects created for this table in the destination database, including views, raw data and event log tables. If set to false, the table state is dropped, but the related objects remain intact.

USE ROLE ACCOUNTADMIN;
GRANT OWNERSHIP ON TABLE <destination_database>.<destination_schema>.<table_name> TO ROLE ACCOUNTADMIN REVOKE CURRENT GRANTS;
DROP TABLE <destination_database>.<destination_schema>.<table_name>;

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 ServiceNow® password for basic authentication¶

To update the password you need to find an existing secret and modify it using the ALTER SECRET command.

1. Determine the fully qualified name of the secret object using either Snowsight or SQL command.

   1. To get a secret using Snowsight, do the following:

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

      2. In the left navigation, select Data Products » Apps.

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

      4. In the top navigation menu select Settings » Authentication.

         The Authentication section shows the secret object, for example: CONNECTORS_UI.SERVICENOW_GZSTZTP0KHD.SECRET.

   2. To get the fully qualified name of the secret object using SQL command, query the CONNECTOR_CONFIGURATION view:

      SELECT value FROM connector_configuration WHERE config_key = 'secret';
      

      Copy

2. Pause the connector.

3. Update the secret object by running the ALTER SECRET command, changing the PASSWORD parameter.

4. Resume the connector.

   The password is now updated and used by the connector.

Updating the connection to ServiceNow® instance¶

It’s possible to update the connection to ServiceNow® instance. It allows to change External Access Integration and Secret used by the connector. It also allows to fix the issue when the Secret was detached from the External Access UDF in the connector.

The connection configuration can be updated with the following procedure:

CALL UPDATE_CONNECTION_CONFIGURATION({
  'service_now_url': '<servicenow_base_url>',
  'secret': '<secret_name>',
  'external_access_integration': '<external_access_integration_name>'
});

Where:

servicenow_base_url

Specifies the URL of the ServiceNow® instance that the connector should use. The URL must be set to the same value as during connector installation and should be in the following format:

https://<servicenow_instance_name>.service-now.com

Copy

Change of the ServiceNow® instance URL is not supported.

secret_name

Specifies the fully qualified name of the secret object containing the credentials for authenticating to ServiceNow®.

You must specify the fully qualified name of the secret object in the following format:

<database_name>.<schema_name>.<secret_name>

Copy

The names of the database, schema, and secret must be valid object identifiers.

external_access_integration_name

Specifies the name of the external access integration for ServiceNow®.

The name of the integration must be a valid object identifier.

For example, to update the connection to a ServiceNow® instance that:

• Has the URL https://myinstance.service-now.com.

• Uses the secret stored in secretsdb.apiauth.servicenow_creds_oauth_code.

• Uses the external access integration named servicenow_external_access_integration.

Run the following command:

CALL UPDATE_CONNECTION_CONFIGURATION({
  'service_now_url': 'https://myinstance.service-now.com',
  'secret': 'SECRETSDB.APIAUTH.SERVICENOW_CREDS_OAUTH_CODE',
  'external_access_integration': 'SERVICENOW_API_INTEGRATION'
});

The update of the configuration can be performed only by a user with a grant to the ADMIN application role. Additionally, to run the procedure the connector has to be in the paused state. See pausing the connector.

Exporting the connector state¶

It’s possible to export a snapshot of the current connector state and configuration. The snapshot with the exported connector state is useful when reinstalling the connector to preserve already enabled tables and the ingestion state, or when replication of the destination schema to the failover region is configured to aid with disaster recovery.

The state can be exported with the following procedure:

CALL EXPORT_CONNECTOR_STATE();

Copy

The procedure creates a new __CONNECTOR_STATE_EXPORT table in the destination schema with an exported state. To perform an export the following conditions must be met:

• The export can be performed only by a user with a grant to the ADMIN application role.

• There is no ongoing table reload.

Configuration is also exported automatically each time the connector triggers the ingestion according to configured schedule, provided the following conditions are met:

• At least one table is enabled for ingestion.

• There is no ongoing table reload.

Uninstalling the application¶

This section explains how to uninstall the application with Snowsight and with worksheets and how to remove the objects created by the connector, but which need to be intentionally removed by the user.

Upgrading the connector¶

The connector is upgraded automatically meaning that the user does not need to perform any action in order to have an up to date application.

Scaling the connector¶

If there’s many ServiceNow® tables to be ingested and you want to increase the number of concurrently ingested tables, you can change the parameter by:

CALL CONFIGURE_CONCURRENCY(<number>);

Copy

Where:

number

Specifies the maximum number of workers able to ingest tables concurrently. By default this value is set to 10.

Tables with continuous schedule use separate pool of dedicated workers and are not counted towards the concurrency limit.

Increasing the concurrency should be considered along with changing the size of the warehouse used for data ingestion. If you are experiencing any slowdowns, try resizing the warehouse. See Working with warehouses for more information.

Reinstalling the connector with the same database and schema for ServiceNow® data¶

To reinstall the connector, follow the process below:

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

   SELECT TABLE_NAME FROM TABLES_STATE WHERE STATUS = 'RELOADING';
   

   Copy

2. If any tables are currently reloading, wait for reloads to complete or cancel them.

3. Stop the connector by calling the following stored procedure:

   CALL PAUSE_CONNECTOR();
   

   Copy

4. Export connector’s state and configuration. See this section for details.

   Important

   It’s recommended to export a connector’s state and configuration before dropping the connector application. This will allow the preservation of all custom options (for example, tables enabled for synchronization and their schedules) and state with their most fresh changes in the new installation.

   If you have already removed the connector but left the database and schema containing the ingested data intact, you can still reinstall the connector relying on the automatically exported state but the reinstalled connector might repeat ingestion of some records.

5. Remove the connector, transferring the ownership of tables and views in the destination schema.

6. Reinstall the connector by:

   • reinstalling the connector using Snowsight (preferred).

   • reinstalling the connector using SQL.

During the installation process:

• Provide the previously used database and schema.

  After installation the connector will detect that database and schema contain ingested data and will continue the ingestion from the place it was left before reinstallation. If you exported connector state and it’s successfully imported during installation, previously ingested tables will be automatically enabled with the same schedules and configuration. Otherwise, you will have to manually enable all tables and e.g. configure their schedules to restore the ingestion.

  When reinstalling with SQL commands, remember to transfer the ownership of views and tables in the destination schema to the connector, as described in the SQL installation guide. Otherwise the connector will not have access to these tables and views, preventing it from resuming the ingestion.

• Provide the same ServiceNow® instance name.

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