Comparer les ensembles de mises à jour locaux

Les administrateurs peuvent prévisualiser les ensembles de mises à jour locaux et distants (récupérés) et comparer les ensembles les uns avec les autres pour résoudre les changements conflictuels.

Pourquoi et quand exécuter cette tâche

Comparez les ensembles de mises à jour locaux pour identifier les collisions et vous assurer que les changements appropriés sont validés. Résolvez tous les conflits avant de déplacer un ensemble de mises à jour entre les instances.

Procédure

1. Accédez à la Tout > Ensembles de mises à jour système > Ensembles de mises à jour locaux.
2. Cochez les cases en regard des ensembles de mises à jour à comparer.
3. Dans la liste de choix Actions , sélectionnez Comparer les ensembles de mises à jour.
   L’écran de progression s’affiche au fur et à mesure que ServiceNow le rapport de collision est généré.

   Figure 1. Rapport de collision

   

4. Cliquez sur Accéder au rapport de collision lorsque le rapport est terminé.

   La liste des collisions d’ensembles de mises à jour s’affiche et affiche tous les changements effectués dans les ensembles sélectionnés.

5. Inspectez la liste des collisions en localisant les numéros de collision en double qui montrent le même changement dans des ensembles de mises à jour distincts.

   Figure 2. Collisions d’ensembles de mises à jour

   

6. Résolvez la collision en supprimant l’enregistrement de mise à jour indésirable de l’un des ensembles de mises à jour.
   1. Cliquez sur le lien dans la colonne Mise à jour système pour la mise à jour indésirable (sys_ui_list_incident_null dans l’exemple).
   2. Cliquez sur Supprimer.
      Remarque :

      Vous devez ouvrir l’enregistrement de mise à jour pour le supprimer. Vous ne pouvez pas supprimer la mise à jour en cochant la case de l’entrée dans la liste Collisions d’ensembles de mises à jour et en utilisant l’action Supprimer . Lorsque vous supprimez l’enregistrement de mise à jour, la personnalisation n’est pas retirée de l’instance. Seul l’enregistrement de la personnalisation est supprimé.

      Figure 3. Mises à jour du client

      

7. Exécutez à nouveau la comparaison pour vous assurer que toutes les collisions ont été résolues.

Résolution de collision de l’ensemble de mises à jour

Une collision est une mise à jour qui a une mise à jour locale plus récente.

La plateforme détecte les collisions en comparant les valeurs des champs Nom et Mis à jour de l’enregistrement de mise à jour du client de chaque ensemble de mises à jour. Si le nom correspond, mais que les valeurs de date de mise à jour sont différentes, il y a collision.

Lorsqu’une mise à jour du client est déplacée d’une instance à une autre, elle peut être réécrite pour correspondre à l’instance cible. La réécriture peut impliquer la modification du nom de la mise à jour du client et d’un ou plusieurs sys_iddans la mise à jour. Les réécritures sont effectuées lorsque l’enregistrement ou le champ de référence est pour une table qui utilise une stratégie de fusion. Cela garantit que la mise à jour du client sera appliquée à l’enregistrement correct. Par exemple, si l’enregistrement sys_dictionary pour nomtable.nomchamp a sys_id 123456789 sur l’instance A et sys_id 987654321 sur l’instance B, lorsqu’une mise à jour du client faisant référence à cet enregistrement est récupérée à partir de l’instance A et enregistrée dans la table sys_update_xml sur l’instance B, les références à 123456789 sont mises à jour pour lire 987654321.

Stratégies de fusion

Les ensembles de mises à jour peuvent détecter les collisions entre des enregistrements identiques que vous créez indépendamment sur des instances distinctes. Pour détecter de telles collisions, l’enregistrement doit avoir une stratégie de coalescence basée sur des colonnes de coalescence. Étant donné que la détection des collisions dépend de l’unicité des tables, celles-ci doivent être uniques lorsque les colonnes de coalescence sont combinées. Les enregistrements qui ne sont pas répertoriés ici n’entreront pas en collision si le même enregistrement est créé séparément sur différentes instances.

Type	Colonnes de coalescence
sys_db_object	nom
sys_dictionary	nom, élément
sys_choice_set	nom, élément, langue
sys_documentation	nom, élément, langue
sys_properties	nom
sys_report_chart_color	nom, élément, valeur
sys_ui_form	nom, vue, sys_domain
sys_ui_message	DocumentKey, langue
sys_ui_list	nom, vue, sys_domain, élément, relation, parent
sys_ui_section	nom, vue, légende sys_domain
sys_ui_related_list	nom, vue, related_list, sys_domain
sys_ui_view	nom
sys_user_role	nom
sys_user_group	nom
sys_wizard	nom

La façon dont les noms d’enregistrement de mise à jour du client affectent les collisions

Pour comprendre la coalescence, il est utile de comprendre comment fonctionnent les enregistrements qui ne fusionnent pas. Pour la plupart des types d’enregistrement, lorsqu’une mise à jour du client est déplacée vers une nouvelle instance, le système ne détecte pas les collisions pour la raison suivante :

• Lorsque vous créez un enregistrement, il reçoit un sys_id unique. Pour la plupart des types d’enregistrement, le sys_id fait partie du nom de l’enregistrement de mise à jour du client. Par exemple : sysevent_email_template_9e1998c078b71100a92ecacd80df1d39.
• La création d’un enregistrement identique dans la même table sur une autre instance produit un nom d’enregistrement de mise à jour du client avec un sys_id différent. Par exemple : sysevent_email_template_10b958c8653311005840134572f8e020

Par conséquent, même si les enregistrements peuvent être identiques, les enregistrements ont des noms différents, de sorte que le système ne détecte pas la collision.

Les enregistrements de coalescence, en revanche, utilisent l’approche suivante pour nommer les enregistrements et déterminer les collisions : Les types d’enregistrement de mise à jour du client suivants utilisent tout ou partie de leurs colonnes de coalescence au lieu de la sys_id de leurs noms.

• sys_dictionary
• sys_documentation
• sys_choice_set
• sys_ui_list
• sys_ui_related_list

Le nom d’enregistrement identique qui en résulte dans chaque instance aide le système à identifier les collisions, même si les enregistrements ont des sys_ids différents.

Lorsqu’une mise à jour du client est déplacée d’une instance à une autre, elle peut être réécrite pour correspondre à l’instance cible. La réécriture peut impliquer la modification du nom de la mise à jour du client et d’un ou plusieurs sys_ids dans la mise à jour. Les réécritures sont effectuées lorsque l’enregistrement ou le champ de référence est pour une table qui utilise une stratégie de fusion. Cela garantit que la mise à jour du client sera appliquée à l’enregistrement correct. Par exemple, si l’enregistrement sys_dictionary pour nomtable.nomchamp a sys_id « 123456789 » sur l’instance A et sys_id « 987654321 » sur l’instance B, lorsqu’une mise à jour du client faisant référence à cet enregistrement est récupérée à partir de l’instance A et enregistrée dans la table sys_update_xml sur l’instance B, les références à « 123456789 » sont mises à jour pour lire « 987654321 ».

Empêcher les enregistrements en double

• Transférez les données avec des ensembles de mises à jour plutôt que de les recréer sur des instances distinctes pour garantir que les enregistrements ont les mêmes sys_id.
• Exportez et importez des enregistrements sous forme de fichiers XML pour vous assurer que les enregistrements ont la même sys_id. Reportez-vous à la section Exporter et importer des fichiers XML.
• Activer un index unique pour la table à partir du dictionnaire système. Reportez-vous à la section Administration des tables.

Remarque :

Les enregistrements par défaut inclus dans le système de base de référence auront toujours le même ID système, car l’instance importe les enregistrements sous forme de fichiers XML pendant la mise en service de l’instance.