Préparation de votre instance ServiceNow®¶
Le connecteur Snowflake pour ServiceNow® est soumis aux conditions de connecteur.
Avant d’installer le Snowflake Connector for ServiceNow®, vous devez configurer votre instance ServiceNow.
Conditions préalables¶
Effectuez les étapes suivantes pour configurer votre instance ServiceNow :
Assurez-vous que l’instance ServiceNow est accessible au public. Le connecteur ne fonctionne pas avec les instances cachées derrière un VPN.
Identifiez les tables ServiceNow qui contiennent les données que vous prévoyez d’ingérer dans Snowflake.
Identifiez ou créez l’utilisateur ServiceNow pour le connecteur.
Pour se connecter à l’instance ServiceNow, le connecteur doit s’authentifier auprès de l’instance en tant qu’utilisateur ServiceNow. Choisissez un utilisateur ServiceNow qui répond aux exigences suivantes :
Le nom d’utilisateur ne peut pas contenir de deux-points (
:
).L’utilisateur doit avoir un accès en lecture à tous les enregistrements des tables ServiceNow que vous prévoyez d’ingérer. Les listes de contrôle d’accès (ACLs) ne doivent cacher aucun enregistrement de ces tables à cet utilisateur.
L’utilisateur doit avoir un accès en lecture à toutes les lignes des tables
sys_db_object
(avec les champsname
,super_class
,sys_id
),sys_glide_object
(avec les champsname
,scalar_type
,sys_id
) etsys_dictionary
(avec les champselement
,internal_type
,name
,sys_id
) pour permettre la détection du schéma.L’utilisateur doit avoir un accès en lecture à toutes les lignes de la table
sys_table_rotation
(avec les champsname
etsys_id
) pour que le connecteur puisse utiliser la stratégie d’ingestion appropriée.L’utilisateur doit avoir accès au champ
sys_updated_on
dans les tablessys_db_object
,sys_glide_object
,sys_dictionary
,sys_table_rotation
et de journal. Dans le cas contraire, les tables sont chargées en utilisant le mode d’ingestion « tronquer et charger », moins rentable.Note
La configuration de la connexion dans Snowsight à l’aide de l’authentification OAuth à ServiceNow n’est possible qu’avec un utilisateur interactif. L’utilisateur ServiceNow est interactif si le paramètre Web service access only est désactivé pour l’utilisateur.
Vous ne pouvez utiliser l’authentification OAuth avec des utilisateurs non interactifs que si vous configurez la connexion avec des commandes SQL. Dans ce cas, vous ne pouvez pas vous connecter à ServiceNow ou obtenir le jeton d’actualisation de OAuth à l’aide de Snowsight.
Si vous prévoyez d’ingérer et de synchroniser une table ServiceNow comportant une colonne
sys_updated_on
, créez un index sur cette colonne. Pour plus d’informations sur la configuration des index, voir Créer un index de table dans la documentation ServiceNow.Après avoir créé l’index par l’intermédiaire de l’interface utilisateur, la construction de l’index peut prendre un certain temps. Le processus d’indexation s’exécute en tâche de fond.
Si votre instance possède des tables volumineuses, Snowflake recommande de contacter le support client de ServiceNow pour demander quelle est la meilleure approche pour indexer ce type de tables.
(Facultatif) Si vous prévoyez d’utiliser la méthode d’authentification OAuth et que le rôle en lecture seule a été attribué à votre utilisateur ServiceNow, assurez-vous que la propriété système
glide.security.snc_read_only_role.tables.exempt_create
contient la tableoauth_credential
dans sa liste de valeurs.Créez ou modifiez la propriété
glide.security.snc_read_only_role.tables.exempt_create
dans la tablesys_properties
. Pour plus de détails sur la modification de cette propriété, consultez la base de connaissances ServiceNow.Pour savoir comment ajouter une nouvelle propriété système, consultez Ajouter une propriété système dans la documentation de ServiceNow.
(Facultatif) Certaines procédures de connecteur qui ne sont pas essentielles à la fonctionnalité de base utilisent le point de terminaison ServiceNow
<service_now_instance>/<table_name>.do?SCHEMA
pour récupérer les schémas de table. Ce point de terminaison nécessite le rôleadmin
. Pour plus d’informations sur ce rôle, voir Rôles du système de base dans la documentation ServiceNow. La configuration du connecteur avec un utilisateur n’ayant pas ce rôle empêchera l’exécution des procédures basées sur ce point de terminaison. Les procédures concernées comportent des notes appropriées concernant cette exigence.(Facultatif) Pour permettre la propagation des enregistrements supprimés, utilisez la table
sys_audit_delete
ou une table de journal personnalisée comme source d’information sur les enregistrements supprimés.Note
Veuillez noter que le connecteur doit avoir accès à tous les enregistrements de la table du journal, sinon l’installation risque d’échouer. Dans le cas contraire, les suppressions d’enregistrements dans d’autres tables risquent d’être incorrectes.
Si les lignes de la table de journal sont masquées par ACLs, le comportement du connecteur est imprévisible. Même si l’installation est réussie, certaines suppressions peuvent ne pas être correctement synchronisées à un stade ultérieur du processus.
Pour utiliser
sys_audit_delete
:Définissez l’attribut dictionnaire
no_audit_delete
surfalse
.Assurez-vous que l’utilisateur ServiceNow du connecteur a accès à la table
sys_audit_delete
et aux champsdocumentkey
,tablename
,sys_id
, etsys_created_on
de cette table.
Pour utiliser une table de journal personnalisée :
Créez une table de journal nommée
snowflake_connector_journal
avec des colonnes de chaînes nomméesdocumentkey
ettablename
.Assurez-vous que l’utilisateur ServiceNow du connecteur a accès à la table
snowflake_connector_journal
et aux champsu_documentkey
,u_tablename
,sys_id
, etsys_created_on
de cette table.Créez un script include nommé
RecordChange
avec le code suivant :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' };
Définir une règle de gestion pour capturer la suppression de l’enregistrement :
(function executeRule(current, previous /*null when async*/) { new RecordChange().captureChange(current.getTableName(), current.getUniqueValue()); })(current, previous);
Pour chaque table pour laquelle vous souhaitez propager les enregistrements supprimés, configurez cette règle de gestion pour qu’elle soit exécutée après la suppression d’un enregistrement.
Note
Le connecteur ne peut synchroniser les enregistrements supprimés que s’ils sont audités. Les opérations de suppression qui n’appellent pas DBDelete.setWorkflow()
ne sont pas ingérées dans Snowflake.
Reportez-vous à la documentation de votre produit ServiceNow pour plus d’informations sur l’utilisation de DBDelete.setWorkflow()
.
Il convient également de noter ce qui suit à propos des enregistrements supprimés :
Les suppressions d’enregistrements ne sont pas suivies pour les tables ayant l’attribut de dictionnaire
no_audit_delete=true
.Les suppressions d’enregistrements dans les tables ayant un préfixe
sys
ne sont pas suivies par défaut.Le connecteur ne peut ingérer des enregistrements supprimés en cascade que si le champ de référence se trouve dans une table auditée. Reportez-vous à la documentation de votre produit ServiceNow pour plus d’informations sur la suppression d’enregistrements en cascade.
Prochaines étapes¶
Après avoir effectué ces procédures, suivez les étapes dans Installation et configuration du connecteur avec Snowsight ou Installation et configuration du connecteur via des commandes SQL.