更新セットによって追跡されるカスタマイズ

更新セットは、アプリケーションテーブル、フィールド、およびレコードに対するカスタマイズを追跡できます。

更新セットでは、次の条件でカスタマイズを追跡します:

• テーブルが update_synch ディクショナリー属性を持つところ。
• 複数のテーブルに対する変更を追跡する特別なハンドラーがあるところ。
• 管理者が更新からフィールドを除外しなかったところ。

一般に、更新セットは構成情報を取得しますが、タスクまたはプロセスデータは取得しません。たとえば、更新セットは、サービスカタログアイテムの定義と、変数や変数の選択などの関連する構成データを追跡します。ただし、注文を出してサービスカタログをテストすると、更新セットは注文要求、アイテム、およびカタログタスクを追跡しません。

更新セットには、アプリケーションファイルとしてデータを転送するキャパシティが限られています。大規模なデータ転送の場合は、インポートセットまたはWebサービスでデータをエクスポートしまたはインポートします。

update_synch属性

カスタマイズが追跡されているテーブルのリストを表示するには、次に移動します システム定義 > ディクショナリ 属性にはupdate_synchが含まれています。

警告:

update_synch プロパティをディクショナリレコードに追加しません。不適切に使用された場合、この属性はパフォーマンス上の大きな問題を引き起こすか、インスタンスを使用不可能にする可能性があります。このため、顧客は update_synch 属性にアクセスできません。

デフォルトのルールでは、次の問題を避けるために、事前定義されていない表 update_synch プロパティの使用を閉鎖します。

• 一部のコアテーブルは、複数のテーブルの情報を表すため、特別な更新処理が必要。update_synch プロパティがこれらのテーブルに追加されると、重複した更新レコードが作成され、トラブルシューティングや修復が困難な重大な競合が発生する。
• update_synchプロパティを使用してインスタンス間でデータレコードを移行すると、パフォーマンス上の問題が発生する可能性がある。なぜならこれはこの目的を意図したものではない。データを移行するには、インスタンスからインスタンスへのインポートを使用する。

  「Import Sets」を参照してください。

特別ハンドラー

いくつかの変更は、複数のテーブルに関する情報を表すため、特別なハンドラを必要とします。これらの変更は、カスタマイズが収容されたときにすべてのレコードが適切に更新されるように、１つの更新セットエントリにパッケージ化します。特別なハンドラでは、以下の変更が追跡されます。

• ワークフロー
• フォームセクション
• リスト
• 関連リスト
• 選択リスト
• システムディクショナリーの入力
• フィールドラベル

警告:

フォームセクション、リスト、関連リスト、選択リスト、およびフィールドラベルの特別なハンドラーは、レコードを削除して再挿入します。これにより、テーブルを参照するフィールドがある場合は、予期しない結果が発生してデータが失われる可能性があります。

選択リスト

更新セットは、新規および更新された選択肢の両方のオプションを、更新バージョン [sys_update_version] および顧客の更新 [sys_update_xml] テーブルの分離されたレコードとして保存します。たとえば、タスクテーブルを拡張する新しいアクティビティ [u_activity] テーブルを作成します。次に、新しい選択肢オプションをタスク状態フィールドに追加します。これは、拡張テーブル(たとえば、私の状態 )に対してのみ表示されます。

これらの変更を更新セットとして発行すると、更新プログラムには、u_activity テーブルに追加した選択肢の更新レコードとバージョンレコードのみが含まれます。タスクテーブルの選択肢オプションは影響を受けません。

警告:

更新セットでは大きな選択リストを使用しないでください。使用すると、更新セットのコミットに非常に時間がかかるようになります。

ディクショナリーの変更

通常、更新セットを使用すると、データが失われるディクショナリーの変更の適用を防止します。ブロックされたディクショナリーの変更には次を含みます：

• テーブルの削除
• 列データ型の変更

更新セットは、システムディクショナリーからのテーブルの削除を追跡しません。代わりに、顧客は手動でターゲットインスタンスからテーブルを削除する必要があります。更新セットはデータ型の変更を追跡しますが、ターゲットインスタンスはデータ損失の原因となる変更をスキップし、代わりにアクションに関するログメッセージを追加します。顧客は、ログを使用して、ターゲットインスタンス上で手動でデータタイプを変更できます。

注:

更新セットのプレビューでは、ターゲットインスタンスが変更をスキップしてデータが失われるため、タイプの不一致の問題はチェックされません。また、更新セットを使用してテーブルから列を削除すると、特定の状況でデータが失われる可能性があります。ターゲットインスタンスの列にデータがある場合、そのデータは、更新セットが収容されたときに、列自身と共に削除します。列を削除する更新セットを収容しようとすると、警告メッセージが表示されます。このメッセージには、データの削除を引き起こす1つ以上の削除更新が存在し、削除の更新内容が特定されています。

ホームページとコンテンツページ

ホームページとコンテンツページは、デフォルトで更新セットに追加されません。現在の更新セットをアンロードしてページを追加します。

重要:

インスタンスからの情報を整理してデータに関するストーリーを伝える、ホームページの機能は、新しいインスタンスのダッシュボードにあります。Next Experience を有効にしてアップグレードされたインスタンスでは、ユーザーは直接 URL を持っている場合は既存のホームページを表示できますが、作成や編集はできません。レスポンシブダッシュボードと アナリティクスセンター ダッシュボードがホームページの機能を引き継ぎます。

ホームページ廃止ヘルプツールを使用して、インスタンスのホームページをレスポンシブダッシュボードに変換します。

詳細については、以下を参照してください。

• 分析センターでのダッシュボード
• レスポンシブダッシュボードの操作。

アプリケーションの変更

システムは、アプリケーションに関連付けられた変更のみを含むアプリケーションごとに個別の更新セットを作成します。これにより、各アプリケーションのアクセス設定が適切に評価され、更新セットの変更を収容するときに確実に適用される。