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 les comparer les uns aux autres pour résoudre les changements conflictuels.

Avant de commencer

Rôle requis : admin.

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 Tous > 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 s’affiche et ServiceNow génère le rapport de collision.

   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 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 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 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 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 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’entrent pas en collision si le même enregistrement est créé séparément sur différentes instances.

Type	Colonnes de coalescence
atf_input_variable	nom, élément
atf_output_variable	nom, élément
dp_data_pattern	source_sys_id
dynamic_attribute	namespaced_name
dynamic_category	namespaced_name
dynamic_category_member	catégorie, attribut
dynamic_choice_override	Choix, catégorie, attribut
dynamic_namespace	nom
sys_analytics_bucket	sys_scope, bucket_document_id bucket_table_name
sys_attachment	(utilise une logique de correspondance personnalisée)
sys_choice_set	nom, élément
sys_collection	collection, nom join_field
sys_db_object	nom
sys_df_data_dictionary	nom, élément
sys_dictionary	nom, élément
sys_documentation	nom, élément, langue
sys_index	logical_table_name, col_name_string
sys_module	chemin d'accès
sys_notification_category	nom
sys_package	source
sys_package_dependency_m2m	dépendance, sys_package
sys_properties	nom
sys_report_chart_color	nom, élément, valeur
sys_scope_script_access	source_scope, target_scope script_name
sys_scope_table_access	source_scope, target_scope table_name
sys_script_validator	internal_type, ui_type
sys_translated	nom, élément, valeur, langue
sys_translated_text	tablename, fieldname, documentkey, language
sys_ui_form	nom, vue sys_domain
sys_ui_list	nom, vue, sys_domain, élément, relation, parent
sys_ui_message	Clé, langue, code
sys_ui_related_list	nom, vue, related_list sys_domain
sys_ui_section	nom, vue, légende sys_domain
sys_ui_view	nom
sys_user_group	nom
sys_user_role	nom
sys_wizard	nom
ua_table_licensing_config	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 se 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 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 une sys_id différente. Par exemple : sysevent_email_template_10b958c8653311005840134572f8e020

Par conséquent, même si les enregistrements sont par ailleurs identiques, ils portent des noms différents afin 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’enregistrements de mise à jour de client 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 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’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 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 de 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 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 Exporter et importer des 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.