ローカルな更新セットの比較

アドミニストレーターは、ローカルおよびリモートの(取得した)更新セットをプレビューし、それらのセットを互いに比較して、競合する変更を解決するできます。

このタスクについて

ローカルの更新セットを比較して、競合を特定し、適切な変更が収容されていることを確認します。インスタンス間で更新セットを移動する前に、すべての競合を解決します。

手順

1. 移動先 すべて > システムアップデートセット > ローカル更新セット.
2. 比較する更新セットの横にあるチェックボックスをオンにします。
3. アクション選択リストで 更新セットを比較を選択します。
   ServiceNowが競合レポートを生成すると進捗画面が現れます。

   図 : 1. 競合レポート

   

4. レポートが完了したとき競合レポートに行くをクリックします。

   更新セット競合リストが表示され、選択したセットのすべての変更が表示されます。

5. リストを調べ、別々の更新セットで同じ変更を示している重複した競合番号を探すこと競合を見つけます。

   図 : 2. 更新セット競合

   

6. いずれかの更新セットから不要な更新レコードを削除して競合を解決します。
   1. 不要な更新に対する システム更新列にあるリンクをクリックします(この例では sys_ui_list_incident_null )。
   2. [削除] をクリックします。
      注:

      レコードを削除するには、更新レコードを開く必要があります。更新セット競合リストの項目のチェックボックスをオンにして削除アクションを用いることで更新を削除することはできません。更新レコードを削除すると、カスタマイズはインスタンスから取り消しされません。カスタマイズのレコードのみが削除されます。

      図 : 3. カスタマーアップデート

      

7. 比較をもう一度実行して、すべての競合が解決されていることを確認する。

更新セット競合の解決

競合は新しいローカル更新を持つ更新です。

プラットフォームは各更新セットからのカスタマーアップデートレコードの名と更新済みフィールドの値を比較することで競合を検知します。名前が一致しても更新日の値が異なる場合は、競合が存在します。

カスタマーアップデートがあるインスタンスから別のインスタンスに移動されると、そのインスタンスはターゲットインスタンスと一致するように書き直される可能性があります。書き換えには、顧客の更新の名前の更新とその更新中の1つまたは複数の sys_id 変更が絡むことがあります。レコードまたは参照フィールドが合体戦略を使用するテーブルに対するものの場合再書き込みが行われます。これによりカスタマーアップデートが正しいレコードに確実に適用されます。たとえば、 sys_dictionary 〜のためのレコード tablename.fieldname がインスタンスAで sys_id 123456789 を持ちインスタンスBで sys_id 987654321 持つと、そのレコードを参照する顧客の更新がインスタンスAから取得され、インスタンスBのsys_update_xmlテーブルに記録されると、 123456789 への参照は 987654321 に更新されます。

合体戦略

更新セットは、別々のインスタンスで独立に作成する同一のレコード間の競合を検知できます。このような競合を検知するには、レコードは合体する列に基づく合体戦略が必要です。競合の検出は表の一意性に依存するため、テーブルの合体する列を結合するときそのテーブルは一意でなければなりません。同じレコードが異なるインスタンスで別々に作成されている場合、ここにリストされていないレコードは競合しません。

タイプ	列の合体
sys_db_object	name
sys_dictionary	名前、要素
sys_choice_set	名前、要素、言語
sys_documentation	名前、要素、言語
sys_properties	name
sys_report_chart_color	名前、要素、値
sys_ui_form	名前、表示、sys_domain
sys_ui_message	documentkey, language
sys_ui_list	名前、ビュー、sys_domain、要素、関係、親
sys_ui_section	名前、表示、キャプション、sys_domain
sys_ui_related_list	名前、表示、関連リスト、sys_domain
sys_ui_view	name
sys_user_role	name
sys_user_group	name
sys_wizard	name

カスタマーアップデートレコード名が競合にどのように影響するか

合体を理解するには、合併しないレコードがどのように機能するかを理解することが役立ちます。ほとんどのレコードタイプでは、カスタマーアップデートを新しいインスタンスに移動すると、システムは次の理由で競合を検知しません：

• レコードを作成すると、一意のsys_idを受け取ります。ほとんどのレコードタイプでは、sys_idは顧客更新レコード名の一部になります。例えば： sysevent_email_template_9e1998c078b71100a92ecacd80df1d39 。
• 別のインスタンスの同じテーブルに同じレコードを作成すると、異なるsys_idを持つ顧客更新レコード名が生成されます。例えば： sysevent_email_template_10b958c8653311005840134572f8e020

その結果、たとえレコードがそうでなければ同一かもしれませんが、レコードは異なる名前になり、システムは競合を検知しません。

対照的に、レコードの合体は、レコードの命名と競合の判定に次の方法を使用します：次の顧客更新レコードタイプは、名前にsys_idの代わりに合体列の一部またはすべてを使用します。

• sys_dictionary
• sys_documentation
• sys_choice_set
• sys_ui_list
• sys_ui_related_list

各インスタンスで結果として同一のレコード名を使用すると、レコードに異なる sys_id があってもシステムが衝突を識別するのに役立ちます。

カスタマーアップデートがあるインスタンスから別のインスタンスに移動されると、そのインスタンスはターゲットインスタンスと一致するように書き直される可能性があります。書き換えには、顧客更新の名前の更新とその更新中の1つまたは複数の sys_id 変更が絡むことがあります。レコードまたは参照フィールドが合体戦略を使用するテーブルに対するものの場合再書き込みが行われます。これによりカスタマーアップデートが正しいレコードに確実に適用されます。たとえば、tablename.fieldname の sys_dictionary レコードのインスタンス A に sys_id「123456789」、インスタンス B に sys_id「987654321」がある場合、そのレコードを参照する顧客の更新がインスタンス A から取得され、インスタンス B の sys_update_xml テーブルに記録されると、「123456789」への参照が更新されて「987654321」を読み取ります。

重複レコードの防止

• 別々のインスタンスで再作成するのではなく、更新セット を使ってデータを転送することで、レコードが同じ sys_id を持つようにします。
• レコードを XML ファイルとしてエクスポートおよびインポートし、レコードが同じ sys_id を持つようにします。「XML ファイルのエクスポートとインポート」を参照してください。
• システムディクショナリーからテーブルへのユニークなインデックスを有効にします。「テーブルアドミニストレーション」を参照してください。

注:

ベースラインシステムに含まれるデフォルトレコードは、インスタンスのプロビジョニングの際にインスタンスが XML ファイルとしてレコードをインポートするため、常に同じ Sys ID を持ちます。