Préparation de votre instance ServiceNow®¶

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 champs name, super_class, sys_id),

  • sys_glide_object (avec les champs name, scalar_type, sys_id),

  • sys_dictionary (avec les champs element, 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 champs name et sys_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).

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 table oauth_credential dans sa liste de valeurs.

  Créez ou modifiez la propriété glide.security.snc_read_only_role.tables.exempt_create dans la table sys_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 :

    1. Définissez l’attribut dictionnaire no_audit_delete sur false.

    2. Assurez-vous que l’utilisateur ServiceNow® du connecteur a accès à la table sys_audit_delete et aux champs documentkey, tablename, sys_id et sys_created_on de cette table.

  • Pour utiliser une table de journal personnalisée :

    1. Créez une table de journal nommée snowflake_connector_journal avec des champs de chaîne nommés documentkey et tablename.

    2. Assurez-vous que l’utilisateur ServiceNow® du connecteur a accès à la table snowflake_connector_journal et aux champs u_documentkey, u_tablename, sys_id et sys_created_on de cette table.

    3. 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'
       };
       

       Copy

    4. 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);
       

       Copy

    5. 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.