Dépannage du connecteur¶

Erreurs d’étape d’authentification¶

Des problèmes peuvent survenir lors de la connexion à ServiceNow dans l’assistant d’installation ou lors de l’exécution manuelle de la procédure SET_CONNECTION_CONFIGURATION. Si vous rencontrez des erreurs lors de cette étape, assurez-vous que l’utilisateur employé pour installer le connecteur a accès à la table sys_db_object.

Les codes de statut d’erreur susceptibles d’être associés à des problèmes d’ACL dans l’objet JSON renvoyé par la procédure SET_CONNECTION_CONFIGURATION sont les suivants :

• REQUEST_FAILED

Vous pouvez effectuer la requête ci-dessous similaire à celle du connecteur pour vérifier l’accès. Tant que la requête ne renvoie pas le résultat prévu, il ne sera pas possible d’installer le connecteur. Par exemple, si vous utilisez curl pour envoyer la requête HTTP :

# checking access to the sys_db_object table
curl -u '<username>:<password>' "https://<servicenow_instance>.service-now.com/api/now/table/sys_db_object?sysparm_limit=1"

Où :

servicenow_instance

Spécifie le nom de votre instance ServiceNow®.

username et password

Spécifiez les identifiants de connexion de votre instance ServiceNow®.

Exemples de réponse :

• Au moins certains champs sont renvoyés - l’utilisateur dispose des autorisations nécessaires pour accéder à la table.

• La réponse est vide - l’utilisateur est autorisé à accéder à la table, mais pas à l’enregistrement traité. Cela pourrait causer des problèmes ultérieurement.

• La réponse contient une erreur - l’utilisateur n’a pas les autorisations nécessaires pour accéder à la table.

Valider les erreurs d’étapes associées à la source¶

Des problèmes peuvent survenir lors de la validation de la source dans l’assistant d’installation ou lors de l’exécution manuelle de la procédure FINALIZE_CONNECTOR_CONFIGURATION. Si vous rencontrez des erreurs lors de cette étape, assurez-vous que l’utilisateur employé pour installer le connecteur dispose des autorisations nécessaires pour accéder aux tables de métadonnées.

Les codes de statut d’erreur susceptibles d’être associés à des problèmes d’ACL dans l’objet JSON renvoyé par la procédure FINALIZE_CONNECTOR_CONFIGURATION sont les suivants :

• METADATA_TABLE_ACCESS_VALIDATION_ERROR

• JOURNAL_TABLE_ACCESS_VALIDATION_ERROR

Vous pouvez effectuer les requêtes ci-dessous similaires à celles du connecteur pour vérifier l’accès. Tant que les requêtes ne renvoient pas les résultats prévus, il ne sera pas possible d’installer le connecteur. Par exemple, si vous utilisez curl pour envoyer la requête HTTP :

# checking access to the sys_db_object table
# expected fields in the result object: sys_id, super_class, name
curl -u '<username>:<password>' "https://<servicenow_instance>.service-now.com/api/now/table/sys_db_object?sysparm_fields=sys_id,super_class,name&sysparm_limit=1&sysparm_query=name=sys_db_object"

# checking access to the sys_dictionary table
# expected fields in the result object: sys_id, name, element, internal_type
curl -u '<username>:<password>' "https://<servicenow_instance>.service-now.com/api/now/table/sys_dictionary?sysparm_fields=sys_id,name,element,internal_type&sysparm_limit=1&sysparm_query=name=sys_dictionary"

# checking access to the sys_glide_object table
# expected fields in the result object: sys_id, name, scalar_type
curl -u '<username>:<password>' "https://<servicenow_instance>.service-now.com/api/now/table/sys_glide_object?sysparm_fields=sys_id,name,scalar_type&sysparm_limit=1&sysparm_query=name=datetime"

# checking access to the sys_table_rotation table
# expected fields in the result object: sys_id, name
curl -u '<username>:<password>' "https://<servicenow_instance>.service-now.com/api/now/table/sys_table_rotation?sysparm_fields=sys_id,name&sysparm_limit=1&sysparm_query=name=syslog"

# (optional) - check only if deletions auditing is going to be used
# checking access to the journal table
# if known, "&sysparm_query=tablename=<table_name>" or "&sysparm_query=documentkey=<sys_id>" can be appended to the request
# expected fields in the result object: sys_id, sys_created_on, documentkey, tablename
curl -u '<username>:<password>' "https://<servicenow_instance>.service-now.com/api/now/table/<journal_table>?sysparm_fields=sys_id,sys_created_on,documentkey,tablename&sysparm_limit=1"

Où :

servicenow_instance

Spécifie le nom de votre instance ServiceNow®.

username et password

Spécifiez les identifiants de connexion de votre instance ServiceNow®.

journal_table

Spécifie le nom de votre table ServiceNow® utilisée pour l’audit des suppressions. La valeur est généralement sys_audit_delete.

Exemples de réponse :

• Tous les champs prévus sont présents dans la réponse - l’utilisateur dispose des autorisations nécessaires.

• Il manque certains des champs prévus - l’utilisateur ne dispose pas des autorisations nécessaires sur toutes les colonnes.

• La réponse est vide - l’utilisateur ne dispose pas des autorisations nécessaires sur toutes les lignes.

• La réponse contient une erreur - l’utilisateur ne dispose pas des autorisations nécessaires sur la table.

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(<from_timestamp>, <to_timestamp>);

Où :

from_timestamp

Spécifie le début de la plage de dates (dans le fuseau horaire UTC) pour laquelle les données doivent être extraites.

to_timestamp

Spécifie la fin de la plage de dates (dans le fuseau horaire UTC) pour laquelle 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 :

CALL GET_TROUBLESHOOTING_DATA('2024-02-05 10:00:00', '2024-02-10 22:30:00');

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

Restauration de l’entrepôt de connecteur¶

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

Restauration de la base de données et du schéma des données ServiceNow®¶

Si la base de données ou le schéma des données ServiceNow® est supprimé, 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 de nouveau les données ServiceNow®.

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

Si l’une des tables contenant les données ServiceNow® (soit les tables de journaux d’événements, soit les tables 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 redémarrer l’ingestion de la table ServiceNow® :

• Assurez-vous que les tables de journaux d’événements et les tables de données brutes de cette table ServiceNow® sont supprimées.

• Désactivez la table ServiceNow®.

• Utilisez la procédure DELETE_TABLE.

• Activez la table ServiceNow®.

Restauration de l’intégration de notification du 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.

Vérification de la présence de métadonnées de colonne dans Snowflake¶

Pour vérifier si les métadonnées de colonne sont présentes dans la table sys_dictionary sur Snowflake, exécutez la requête suivante :

SELECT * FROM <dest_db>.<dest_schema>.sys_dictionary__view WHERE name = '<table_name>' AND element = '<column_name>';

Si la table que vous étudiez a des tables parentes (héritées d’une autre table dans ServiceNow®) et que la colonne que vous recherchez a été ajoutée à la table parente, vous devez utiliser le nom de la table parente à la place.

Pour obtenir la liste de toutes les tables dont hérite la table qui vous intéresse, utilisez la requête suivante :

SELECT
    sys_id,
    name,
    PARSE_JSON(super_class):value::string AS super_class_sys_id
FROM <dest_db>.<dest_schema>.sys_db_object__view
START WITH name = '<table_name>'
CONNECT BY sys_id = PRIOR super_class_sys_id;

Si des lignes sont renvoyées, cela signifie que les métadonnées de la colonne ont été correctement ingérées dans Snowflake, mais que la vue n’a pas encore été actualisée. Vérifiez le statut et si :

• la vue a été actualisée récemment, mais que la colonne n’est toujours pas présente, contactez l’assistance.

• la vue n’a pas encore été actualisée, attendez la planification d’ingestion suivante.

Si un résultat vide est renvoyé, cela signifie que le connecteur n’a pas encore ingéré de métadonnées pour cette colonne. Vous devez valider côté ServiceNow® que l’enregistrement est visible par le connecteur et que son horodatage est correct.

Afficher le statut d’actualisation¶

Pour savoir quand les vues d’une table donnée ont été actualisées pour la dernière fois et si l’opération s’est effectuée correctement, exécutez la requête suivante :

SELECT flattened_views_status, flattened_views_last_updated FROM tables_state WHERE table_name = '<table_name>';

Si la dernière actualisation a échoué, il peut être souhaitable d’interroger la table d’événements et de rechercher les erreurs signalées par le connecteur.

Afficher la disponibilité des métadonnées des colonnes ServiceNow®¶

Il est possible que l’absence de certaines colonnes dans la vue aplatie s’explique par le fait que les métadonnées des colonnes ne peuvent pas être ingérées par le connecteur. Cela peut être dû au fait que les ACLs empêchent le renvoi de la ligne de la table sys_dictionary par l’API Table. Une autre raison possible est une valeur d’horodatage passée dans la colonne sys_updated_on. Il peut également arriver que la définition de la colonne/table ait été importée d’une autre instance de ServiceNow®. Pour déterminer si le connecteur peut accéder aux métadonnées des colonnes, exécutez la requête GET au point de terminaison suivant :

https://<servicenow_instance>.service-now.com/api/now/table/sys_dictionary?sysparm_query=name=<table_name>^element=<column_name>

Si un résultat vide est renvoyé, cela signifie que le connecteur ne peut pas accéder à la colonne. La colonne peut être protégée par une ACL ou ne pas être présente.

Si une définition de colonne a été renvoyée, examinez la valeur du champ sys_updated_on. Confirmez que la date correspond à l’heure prévue de l’ajout de la colonne à la table. Si elle a été importée d’une autre instance, elle peut indiquer le moment où la colonne a été créée. Le mécanisme CDC (mises à jour incrémentielles) du connecteur peut ne pas remarquer que l’enregistrement daté dans le passé a été ajouté. Dans ce cas, déclenchez un rechargement de la table sys_dictionary.