ローカルな更新セットの比較
アドミニストレーターは、ローカルおよびリモートの(取得した)更新セットをプレビューし、それらのセットを互いに比較して、競合する変更を解決するできます。
始める前に
このタスクについて
ローカルの更新セットを比較して、競合を特定し、適切な変更が収容されていることを確認します。インスタンス間で更新セットを移動する前に、すべての競合を解決します。
手順
-
アクション選択リストで 更新セットを比較を選択します。
ServiceNowが競合レポートを生成すると進捗画面が現れます。
図 : 1. 競合レポート -
リストを調べ、別々の更新セットで同じ変更を示している重複した競合番号を探すこと競合を見つけます。
図 : 2. 更新セット競合 -
いずれかの更新セットから不要な更新レコードを削除して競合を解決します。
- 不要な更新に対する システム更新列にあるリンクをクリックします(この例では
sys_ui_list_incident_null)。 - [削除] をクリックします。注:レコードを削除するには、更新レコードを開く必要があります。更新セット競合リストの項目のチェックボックスをオンにして削除アクションを用いることで更新を削除することはできません。更新レコードを削除すると、カスタマイズはインスタンスから取り消しされません。カスタマイズのレコードのみが削除されます。
図 : 3. カスタマーアップデート
- 不要な更新に対する システム更新列にあるリンクをクリックします(この例では
更新セット競合の解決
競合は新しいローカル更新を持つ更新です。
プラットフォームは各更新セットからのカスタマーアップデートレコードの名と更新済みフィールドの値を比較することで競合を検知します。名前が一致しても更新日の値が異なる場合は、競合が存在します。
カスタマーアップデートがあるインスタンスから別のインスタンスに移動されると、そのインスタンスはターゲットインスタンスと一致するように書き直される可能性があります。書き換えには、顧客の更新の名前の更新とその更新中の1つまたは複数の sys_id 変更が絡むことがあります。レコードまたは参照フィールドが合体戦略を使用するテーブルに対するものの場合再書き込みが行われます。これによりカスタマーアップデートが正しいレコードに確実に適用されます。たとえば、 sys_dictionary 〜のためのレコード tablename.fieldname がインスタンスAで sys_id 123456789 を持ちインスタンスBで sys_id 987654321 持つと、そのレコードを参照する顧客の更新がインスタンスAから取得され、インスタンスBのsys_update_xmlテーブルに記録されると、 123456789 への参照は 987654321 に更新されます。
合体戦略
更新セットは、別々のインスタンスで独立に作成する同一のレコード間の競合を検知できます。このような競合を検知するには、レコードは合体する列に基づく合体戦略が必要です。競合の検出は表の一意性に依存するため、テーブルの合体する列を結合するときそのテーブルは一意でなければなりません。同じレコードが異なるインスタンスで別々に作成されている場合、ここにリストされていないレコードは競合しません。
| タイプ | 列の合体 |
|---|---|
| atf_input_variable | 名前、要素 |
| atf_output_variable | 名前、要素 |
| dp_data_pattern | source_sys_id |
| dynamic_attribute | namespaced_name |
| dynamic_category | namespaced_name |
| dynamic_category_member | カテゴリ、属性 |
| dynamic_choice_override | choice、category、attribute |
| dynamic_namespace | 名前 |
| sys_analytics_bucket | sys_scope、bucket_document_id、bucket_table_name |
| sys_attachment | (カスタム一致ロジックを使用) |
| sys_choice_set | 名前、要素 |
| sys_collection | collection、name、join_field |
| sys_db_object | 名前 |
| sys_df_data_dictionary | 名前、要素 |
| sys_dictionary | 名前、要素 |
| sys_documentation | 名前、要素、言語 |
| sys_index | logical_table_name、col_name_string |
| sys_module | パス |
| sys_notification_category | 名前 |
| sys_package | ソース |
| sys_package_dependency_m2m | 依存関係、sys_package |
| sys_properties | name |
| sys_report_chart_color | 名前、要素、値 |
| 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 | 名前、要素、値、言語 |
| sys_translated_text | tablename、fieldname、documentkey、language |
| sys_ui_form | 名前、表示、sys_domain |
| sys_ui_list | 名前、ビュー、sys_domain、要素、関係、親 |
| sys_ui_message | キー、言語、コード |
| sys_ui_related_list | 名前、表示、関連リスト、sys_domain |
| sys_ui_section | 名前、表示、キャプション、sys_domain |
| sys_ui_view | 名前 |
| sys_user_group | 名前 |
| sys_user_role | 名前 |
| sys_wizard | 名前 |
| ua_table_licensing_config | 名前 |
カスタマーアップデートレコード名が競合にどのように影響するか
- レコードを作成すると、一意のsys_idを受け取ります。ほとんどのレコードタイプでは、sys_idは顧客更新レコード名の一部になります。例えば：
sysevent_email_template_9e1998c078b71100a92ecacd80df1d39。 - 別のインスタンスの同じテーブルに同じレコードを作成すると、異なるsys_idを持つ顧客更新レコード名が生成されます。例えば：
sysevent_email_template_10b958c8653311005840134572f8e020
その結果、たとえレコードがそうでなければ同一かもしれませんが、レコードは異なる名前になり、システムは競合を検知しません。
- 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 ファイルのエクスポートとインポート」を参照してください。
- システムディクショナリーからテーブルへのユニークなインデックスを有効にします。「テーブルアドミニストレーション」を参照してください。