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 des instances.

Procédure

1. Accédez à la Tous > Ensembles de mises à jour système > Ensembles de mises à jour locaux.
2. Cochez les cases situées 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 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 recherchant 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 de 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 pour 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 sauvegardée sur 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 dotée d’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 qu’il existe différentes valeurs de date de mise à jour, 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 mise à jour 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 destiné à 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 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 coalescence

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 disposer d’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, les tables 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 conflit 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

Comment les noms d’enregistrement de mise à jour du client affectent les collisions

Pour comprendre la coalescence, il est utile de comprendre le fonctionnement des enregistrements qui ne sont pas fusionnés. 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, celui-ci 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.

En revanche, les enregistrements fusionnels utilisent l’approche suivante pour nommer les enregistrements et déterminer les collisions : Les types d’enregistrements de mise à jour client suivants utilisent une partie ou la totalité de leurs colonnes de coalescence au lieu de la sys_id dans 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 destiné à 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 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 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 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 en tant que fichiers XML pendant la mise en service de l’instance.