Préparation de votre instance ServiceNow

Avant d’installer le connecteur Snowflake pour ServiceNow, vous devez configurer votre instance ServiceNow.

Effectuez les étapes suivantes pour configurer votre instance ServiceNow :

  1. Assurez-vous que l’instance ServiceNow est accessible au public. Le connecteur ne fonctionne pas avec les instances cachées derrière un VPN.

  2. Identifiez les tables ServiceNow qui contiennent les données que vous prévoyez d’ingérer dans Snowflake.

  3. 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 champs name, super_class, sys_id), sys_glide_object (avec les champs name, scalar_type, sys_id) et sys_dictionary (avec les champs element, 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 champs name et sys_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 tables sys_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.

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

  5. (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 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, consultez Ajouter une propriété système dans la documentation de ServiceNow.

  6. (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ôle admin. 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.

  7. (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 :

      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 colonnes de chaînes nommées 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.

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.

Après avoir effectué ces procédures, suivez les étapes dans Installation et configuration du connecteur avec Snowsight ou Installation et configuration du connecteur à l’aide de commandes SQL.