Dépannage du connecteur¶

Le connecteur Snowflake pour ServiceNow® est soumis aux conditions de connecteur.

Ce chapitre fournit des lignes directrices pour la résolution des problèmes liés au Snowflake Connector for ServiceNow®.

Dans ce chapitre :

Note

Les sections suivantes décrivent les procédures stockées définies dans le schéma PUBLIC de la base de données qui du connecteur. Avant d’appeler ces procédures stockées, sélectionnez cette base de données comme base de données à utiliser pour la session.

Par exemple, si la base de données s’appelle my_connector_servicenow, exécutez la commande suivante :

USE DATABASE my_connector_servicenow;

Copy

Vérification de la connexion à l’instance ServiceNow¶

Pour vérifier que le Snowflake Connector for ServiceNow® peut accéder à l’instance ServiceNow, appelez la procédure stockée TEST_SN_CONNECTION qui est définie dans le schéma PUBLIC de la base de données du connecteur :

CALL TEST_SN_CONNECTION('<table_name>');

Copy

Où :

table_name: Spécifie le nom d’une table dans l’instance ServiceNow.

Si le connecteur est correctement configuré, la procédure stockée renvoie une ligne de la table spécifiée.

Par exemple, si la base de données de votre connecteur est nommée my_connector_servicenow, et que vous souhaitez vérifier la connexion en récupérant une ligne d’une table nommée my_table dans votre instance ServiceNow , exécutez les commandes suivantes :

USE DATABASE my_connector_servicenow;
CALL TEST_SN_CONNECTION('my_table');

Copy

Comparaison du nombre de lignes d’une table dans ServiceNow et Snowflake¶

Pour comparer le nombre de lignes d’une table dans ServiceNow et Snowflake, appelez la procédure CHECK_SN_ROW_COUNT :

CALL CHECK_SN_ROW_COUNT('<table_name>');

Copy

Où :

table_name: Spécifie le nom d’une table dans l’instance ServiceNow.

Si la procédure échoue, c’est qu’elle n’a pas pu utiliser l’API stats pour déterminer le nombre de lignes de la table dans ServiceNow. Cela peut signifier que le nombre de lignes de cette table est trop important pour être compté par cette API.

Note

Le nombre de lignes renvoyé peut varier. Une table ServiceNow peut contenir plus de lignes que la table Snowflake équivalente. Cela peut être dû aux règles de la liste de contrôle d’accès (ACLs) définies pour une table donnée dans ServiceNow.

Lorsqu’une heure de début de plage de données est configurée pour une table, les nombres de lignes renvoyés seront probablement différents. Le nombre de lignes ServiceNow représente toujours le nombre de toutes les lignes, alors que selon la configuration, seul un nombre limité de lignes a été ingéré dans Snowflake.

Le connecteur utilise différents points de terminaison pour récupérer des informations sur le nombre de lignes d’une table ServiceNow. Le connecteur utilise stats pour les informations relatives à une table, notamment le nombre de lignes. Il utilise table pour ingérer les données dans Snowflake.

Vérification du statut de l’ingestion d’une ligne¶

Pour vérifier le statut de l’ingestion d’une ligne à tous les endroits possibles dans ServiceNow et Snowflake, appelez la procédure CHECK_RECORD_HISTORY :

CALL CHECK_RECORD_HISTORY('<table_name>', '<sys_id>');

Copy

Où :

table_name: Spécifie le nom d’une table dans l’instance ServiceNow.
sys_id: Spécifie le sys_id de la ligne à vérifier.

La procédure renvoie un objet JSON contenant les propriétés suivantes :

Propriété	Description
`table_name`	Nom de la table.
`sys_id`	Identificateur unique pour la ligne dans ServiceNow.
`status`	Statut de l’ingestion de la ligne.
`is_present_in_servicenow`	`true` si la ligne est présente dans la table dans ServiceNow ; `false` dans le cas contraire.
`is_present_in_servicenow_audit_table`	`true` si la ligne est suivie dans la table d’audit dans ServiceNow ; `false` dans le cas contraire.
`is_present_in_snowflake_destination_table`	`true` si la ligne a déjà été ingérée et est disponible dans la base de données `dest_db` de Snowflake ; `false` dans le cas contraire.
`event_log_records`	Tableau d’objets JSON représentant les entrées dans le journal des événements pour la ligne avec ce `sys_id`. Chaque objet contient les propriétés suivantes, qui correspondent aux colonnes du tableau de journal des événements qui spécifient les horodatages et les types d’événements de la modification des données : `sys_updated_on` `event_date` `event_type`

Déterminer si une table fait l’objet d’un audit de suppression¶

Le Snowflake Connector for ServiceNow® s’appuie sur l’audit pour propager la suppression des enregistrements à Snowflake.

Pour vérifier qu’une table donnée dans ServiceNow est configurée pour auditer la suppression des enregistrements, appelez la procédure stockée CHECK_IF_AUDIT_ENABLED :

CALL CHECK_IF_AUDIT_ENABLED('<table_name>');

Copy

Où :

table_name: Spécifie le nom d’une table dans l’instance ServiceNow.

Cette procédure stockée vérifie la configuration audit et no_audit_delete pour la table spécifiée et imprime les informations indiquant si l’audit est activé ou non.

Obtention des données de dépannage¶

Pour obtenir des données de dépannage, appelez la procédure stockée GET_TROUBLESHOOTING_DATA :

CALL GET_TROUBLESHOOTING_DATA(<number_of_days>);

Copy

Où :

number_of_days: Spécifie le nombre de jours écoulés depuis lesquels les données doivent être extraites.

Cette procédure stockée renvoie les données suivantes sous forme de tableau :

Informations sur la configuration
Erreurs rencontrées par le connecteur
Historique d’ingestion

L’exemple suivant montre comment appeler cette procédure stockée :

USE DATABASE my_connector_servicenow;
  CALL GET_TROUBLESHOOTING_DATA(1);

Copy

Vous pouvez enregistrer les données renvoyées au format CSV pour les envoyer à l’assistance de Snowflake.

Test de la connexion à ServiceNow¶

Pour vérifier si le connecteur peut accéder à une instance ServiceNow, appelez la procédure stockée GET_CONNECTION_STATUS.

Cette procédure stockée vérifie la connexion et les identifiants de connexion stockés dans le secret fourni lors de la configuration. Il renvoie une variante avec deux clés :

statut
details

L’exemple suivant montre comment appeler la procédure stockée GET_CONNECTION_STATUS :

USE DATABASE my_connector_servicenow;
CALL GET_CONNECTION_STATUS();

Copy

Récupération d’un objet inaccessible¶

Le connecteur requiert plusieurs objets de base de données qui sont externes à la base de données du connecteur. Si ces objets ne sont pas disponibles, le connecteur échouera ou cessera de fonctionner correctement. Les situations dans lesquelles les objets peuvent devenir indisponibles sont les suivantes :

Destruction d’un objet.
Recréation d’un objet sans conservation ou restauration des autorisations requises.
Révocation des autorisations nécessaires à l’utilisation de ces objets par le connecteur.

Dans la plupart des cas, vous pouvez restaurer ces objets manuellement en les recréant et en leur accordant les privilèges nécessaires. Les sections suivantes décrivent comment restaurer différents objets.

Restauration de l’entrepôt de connecteurs¶

Si le connecteur perd l’accès à son entrepôt, configurez-en un nouveau en appelant la procédure stockée CONFIGURE_WAREHOUSE.

Restauration de l’objet secret du connecteur¶

Si l’objet secret utilisé par le connecteur est supprimé, vous devez recréer le secret en utilisant le même nom dans la même base de données et le même schéma.

Pour vérifier le nom pleinement qualifié du secret, exécutez la commande suivante :

SELECT value:secret FROM GLOBAL_CONFIG WHERE key = 'connection_config';

Copy

En outre, vous devez accorder le privilège USAGE sur le secret recréé au rôle personnalisé utilisé par le connecteur.

Si la base de données ou le schéma de l’objet secret est supprimé, une récupération est possible en exécutant la commande UNDROP. Cette commande permet également de récupérer l’objet secret.

Si vous ne pouvez pas utiliser la commande UNDROP , vous devez recréer la base de données et le schéma en utilisant les mêmes noms. Vous devez également accorder le privilège USAGE sur la base de données et le schéma au rôle personnalisé utilisé par le connecteur.

Restauration de l’intégration API¶

Si l’intégration API utilisée par le connecteur est supprimée, vous devez la recréer en utilisant le même nom. Pour vérifier le nom de l’intégration API attendue par le connecteur, exécutez la commande suivante :

SELECT value:apiIntegrationName FROM GLOBAL_CONFIG WHERE key = 'connection_config';

Copy

Lorsque vous recréez l’intégration API, n’oubliez pas d’utiliser le même nom de secret pleinement qualifié et la même URL d’instance ServiceNow que ceux utilisés précédemment.

Pour déterminer le nom pleinement qualifié du secret, exécutez la commande suivante :

SELECT value:secret FROM GLOBAL_CONFIG WHERE key = 'connection_config';

Copy

Pour déterminer l’URL d’instance ServiceNow, exécutez la commande suivante :

SELECT value:serviceNowUrl FROM GLOBAL_CONFIG WHERE key = 'connection_config';

Copy

Vous devez également accorder le privilège USAGE sur l’intégration API recréée au rôle personnalisé utilisé par le connecteur.

Restauration de la base de données et du schéma pour les données ServiceNow¶

Si la base de données ou le schéma des données ServiceNow est détruit, la seule façon de récupérer cet élément est d’exécuter la commande UNDROP. Si cette commande n’est pas disponible, vous devez réinstaller le connecteur et ingérer à nouveau les données ServiceNow.

Si une vue contenant les données ServiceNow est détruite, elle devrait être recréée automatiquement lors de la prochaine exécution de la tâche d’arrière-plan responsable de leur création.

Si l’une des tables contenant les données ServiceNow (soit les tables de journaux d’événements ou de données brutes) est supprimée et que vous ne pouvez pas utiliser la commande UNDROP TABLE pour la récupérer, procédez comme suit pour démarrer à nouveau l’ingestion de table ServiceNow :

Assurez-vous que les journaux d’événements et les tables de données brutes de cette table ServiceNow sont supprimés.
Désactivez la table ServiceNow.
Utilisez la procédure DELETE_TABLE.
Activez la table ServiceNow.

Restauration du rôle personnalisé du connecteur¶

Si le rôle personnalisé utilisé par le connecteur est supprimé, vous devez le recréer en utilisant le même nom. Pour déterminer le nom du rôle attendu par le connecteur, exécutez la requête suivante :

SELECT value FROM GLOBAL_CONFIG WHERE key = 'data_owner_role';

Copy

Vous devez également restaurer les privilèges énumérés pour le rôle. Vous pouvez déterminer les noms des objets correspondants à l’aide de la vue GLOBAL_CONFIG.

En outre, le rôle doit être propriétaire de toutes les tables et vues contenant des données ServiceNow du schéma correspondant.

Si aucune table ou vue supplémentaire n’a été créée manuellement dans ce schéma, vous pouvez restaurer les rôles en exécutant les commandes GRANT OWNERSHIP ON ALL TABLES/VIEWS IN SCHEMA ... TO ROLE ....

Par exemple, si les données ServiceNow sont stockées dans la base de données dest_db et le schéma dest_schema, pour restaurer un rôle nommé connector_resources_provider , exécutez les commandes suivantes :

GRANT OWNERSHIP ON ALL TABLES IN SCHEMA dest_db.dest_schema TO ROLE connector_resources_provider;
GRANT OWNERSHIP ON ALL VIEWS IN SCHEMA dest_db.dest_schema TO ROLE connector_resources_provider;

Copy

Le rôle recréé doit également être accordé à la base de données des connecteurs. Par exemple, pour accorder le rôle nommé connector_resources_provider à la base de données my_connector_servicenow, exécutez la commande suivante :

GRANT ROLE connector_resources_provider TO DATABASE my_connector_servicenow;

Copy

Restauration de l’intégration des notifications pour le connecteur¶

Si le connecteur perd l’accès à l’objet d’intégration de notification, effectuez à nouveau les procédures de configuration des alertes en recréant l’objet d’intégration de notification si nécessaire.

Si les notifications par e-mail sont configurées via Snowsight il suffit de les désactiver et de les réactiver pour restaurer les objets externes nécessaires.