Préparation de votre instance ServiceNow®¶
Snowflake Connector pour ServiceNow® V2 est soumis aux Conditions de Snowflake Connector.
Avant d’installer Snowflake Connector for ServiceNow®V2, vous devez configurer votre instance ServiceNow®. Procédez comme suit :
Accès à l’instance ServiceNow® - assurez-vous que votre instance ServiceNow® est prête à l’emploi
Utilisateur ServiceNow® - assurez-vous que l’utilisateur requis est correctement configuré
Configurer les index de colonne pour optimiser les performances - configurez les index de colonne pour obtenir des performances optimales
Étapes facultatives - passez en revue et effectuez la configuration facultative, le cas échéant
Accès à l’instance ServiceNow®¶
Assurez-vous que l’instance ServiceNow® est publiquement disponible. Le connecteur ne fonctionne pas avec les instances cachées derrière un VPN.
Si vous utilisez Contrôle d’accès de l’adresse IP pour votre instance ServiceNow®, vous ne pourrez pas installer correctement le connecteur. Pour plus d’informations, voir l’article de la communauté.
Utilisateur ServiceNow®¶
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®. Sélectionnez un utilisateur ServiceNow® qui remplit les conditions 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 suivantes afin de pouvoir activer la détection de schéma :
sys_db_object
(avec les champsname
,super_class
,sys_id
),sys_glide_object
(avec les champsname
,scalar_type
,sys_id
),sys_dictionary
(avec les champselement
,internal_type
,name
,sys_id
).
L’utilisateur doit avoir un accès en lecture à toutes les lignes de la table suivante afin de pouvoir utiliser la stratégie d’ingestion appropriée :
sys_table_rotation
(avec les champsname
etsys_id
).
L’utilisateur doit disposer d’un accès en lecture sur le champ
sys_updated_on
dans les tableaux ci-dessous afin de ne pas utiliser de mode d’ingestion « tronquer et charger » moins rentable :sys_db_object
,sys_glide_object
,sys_dictionary
,sys_table_rotation
,la table de journal (généralement
sys_audit_delete
).
Note
La configuration de la connexion dans Snowsight via l’authentification OAuth auprès de 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® ni obtenir le jeton d’actualisation OAuth via Snowsight.
Configurer des index de colonne pour optimiser les performances¶
Si vous prévoyez d’ingérer et de synchroniser une table ServiceNow® comportant un champ sys_updated_on
, nous recommandons de configurer 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®.
Une fois l’index créé via 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 comporte 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.
Étapes facultatives¶
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, voir Ajouter une propriété système dans la documentation ServiceNow®.
Pour permettre la propagation des enregistrements supprimés, utilisez la table
sys_audit_delete
ou une table de journal personnalisée comme source d’informations 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 champs de chaîne nommésdocumentkey
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.Voir 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. Voir 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.