更新セット競合の解決
競合は新しいローカル更新を持つ更新です。
プラットフォームは各更新セットからのカスタマーアップデートレコードの名と更新済みフィールドの値を比較することで競合を検知します。名前が一致しても更新日の値が異なる場合は、競合が存在します。
カスタマーアップデートがあるインスタンスから別のインスタンスに移動されると、ターゲットインスタンスと一致するように書き換えられる場合があります。書き換えには、顧客更新プログラムの更新名と、更新プログラム内の 1 つ以上のsys_idの変更が含まれる場合があります。レコードまたは参照フィールドが結合戦略を使用するテーブルに対するものである場合、再書き込みが行われます。これにより、カスタマーアップデートが正しいレコードに適用されることが確認されます。たとえば、tablename.fieldname のsys_dictionaryレコードのインスタンス A で 123 sys_id、インスタンス B で sys_id 456 がある場合、そのレコードを参照する顧客更新がインスタンス A から取得され、インスタンス B のsys_update_xmlテーブルに記録されると、 123 への参照は 456 を読み取るように更新されます。
合体戦略
結合とは、更新プロセス中に一意の識別子として使用される 1 つ以上のフィールドに基づいてレコードを識別するプロセスのことです。更新セットは、別々のインスタンスで独立に作成する同一のレコード間の競合を検知できます。このような競合を検知するには、レコードは合体する列に基づく合体戦略が必要です。競合の検出はテーブルの一意性に依存するため、合体する列を結合するとき、テーブルは一意である必要があります。同じレコードが異なるインスタンスで別々に作成されている場合、ここにリストされていないレコードは競合しません。
| タイプ | 列の合体 |
|---|---|
| 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_idsの変更が含まれる場合があります。レコードまたは参照フィールドが結合戦略を使用するテーブルに対するものである場合、再書き込みが行われます。これにより、カスタマーアップデートが正しいレコードに適用されることが確認されます。たとえば、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 ファイルのエクスポートとインポート」を参照してください。
- システムディクショナリーからテーブルへのユニークなインデックスを有効にします。「テーブルアドミニストレーション」を参照してください。