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 d’actions , sélectionnez Comparer les ensembles de mises à jour.
   L’écran de progression apparaît au fur et à mesure de ServiceNow la génération du rapport de collision.

   Figure 1. Rapport de collision

   

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

   La liste Collisions d’ensembles de mises à jour s’affiche, affichant tous les changements dans les ensembles sélectionnés.

5. Inspectez la liste des collisions en localisant les numéros de collision en double qui affichent 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 des collisions d’ensembles de mises à jour

Une collision est une mise à jour dont la mise à jour locale est 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’une ou plusieurs sys_iddans la mise à jour. Les réécritures sont effectuées lorsque l’enregistrement ou le champ de référence se trouve pour une table qui utilise une stratégie de coalescence. Cela garantit que la mise à jour du client sera appliquée au bon enregistrement. Par exemple, si l’enregistrement sys_dictionary pour tablename.fieldname a sys_id 123456789 sur l’instance A et sys_id 987654321 sur l’instance B, lorsqu’une mise à jour du client qui fait 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 se 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 la coalescence de colonnes. É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	Fusions de colonnes
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

Comment 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 une sys_id unique. Pour la plupart des types d’enregistrement, le sys_id fait partie du nom d’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 une sys_id différente. Par exemple : sysevent_email_template_10b958c8653311005840134572f8e020

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

Les enregistrements de fusion, en revanche, utilisent l’approche suivante pour nommer les enregistrements et déterminer les collisions : Les types d’enregistrements de mise à jour des clients suivants utilisent tout ou partie de leurs colonnes de coalescence au lieu du sys_id dans leur nom.

• 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’une ou plusieurs sys_ids dans la mise à jour. Les réécritures sont effectuées lorsque l’enregistrement ou le champ de référence se trouve pour une table qui utilise une stratégie de coalescence. Cela garantit que la mise à jour du client sera appliquée au bon enregistrement. Par exemple, si l’enregistrement sys_dictionary pour tablename.fieldname a sys_id « 123456789 » sur l’instance A et sys_id « 987654321 » sur l’instance B, lorsqu’une mise à jour du client qui fait 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 des données avec des ensembles de mises à jour plutôt que de les recréer sur des instances distinctes pour vous assurer que les enregistrements ont le même sys_id.
• Exportez et importez des enregistrements sous forme de fichiers XML pour vous assurer que les enregistrements ont le même sys_id. Voir Exportation et importation de fichiers XML.
• Activez un index unique pour la table à partir du dictionnaire système. Voir 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 lors de la mise en service de l’instance.