Search

カスタムオブジェクトとカスタムフィールドのデプロイメントはどのように機能しますか？

環境：

カスタムオブジェクトとカスタムフィールド
November 2010とそれ以降のバージョン

解決策：

カスタムオブジェクトとカスタムフィールドの概要

新しいカスタムオブジェクトまたはカスタムフィールド（CO、CF）を作成するか、既存のカスタムオブジェクトまたはカスタムフィールドを更新するには、データベースのスキーマに変更が加えられている必要があります。通常は、大規模なデッドロックやその他の重大な問題を防ぐために、影響を受ける各行を更新できるように、サイトを停止する必要があります。

私たちには、複数のサーバーが並行して動作するシステムがあり、一方のサーバーで変更を可能にし、他方のサーバーは継続してライブを続けることができます。第2サーバにすべての更新が行われると、システムはそのサーバに「フェイルオーバー」（移動）できます。これは、スキーマの変更が行われるたびにサイトが受けるダウンタイムを防ぐためです。

このセットアップには、ダウンタイムのない現場でデータベーススキーマの変更を可能にするなど、大きなメリットがありますが、これを実現するにはいくつかの犠牲が必要です。1つの欠点は、フェイルオーバーが発生する前に、レプリケーション・サーバーでも変更の更新を完了する必要があることです。この理由は、レプリケーションデータベースの基になるスキーマが本番データベースと異なる場合、レプリケーションが本番へ正確に反映することが不可能であるためです。こちらのアンサーをご覧ください。Answer ID7541：レポートに使用される異なるデータベース・タイプに関する情報

ロールバック

カスタムオブジェクトに多数の変更を加えた後で、デプロイしないと決めた場合は、変更をロールバックすることができ、カスタムオブジェクトは以前のデプロイ前の状態に戻ります（カスタムオブジェクトが一度もデプロイされていない場合 、すべてのカスタムオブジェクトが削除されます）。オブジェクトがデプロイされたら、デプロイメントをロールバックするオプションはありませんが、手動でそれらの変更を元に戻して再デプロイする必要があります。ロールバックオプションは、まだデプロイされていないエディタ内で行われた変更のみを示します。

カスタムオブジェクト

特定のデプロイメントが実行する正確な時間は予測できません。現在サーバー上にあるプロセスによっては、変更が数時間から数日かかることがあります。展開時間に影響するいくつかの要素を以下に示します（これは包括的な一覧ではありません）:

• データベースのサイズ
• デプロイされる変更の数
• デプロイ中の Oracle B2C Service サポートサイトへのトラフィックの量
• デプロイされる変更のタイプ

この場合は、展開を待機することをお勧めします。 通常は正常に完了しますが、ちょっと時間がかかります。 カスタムオブジェクトのデプロイメントを計画するベストプラクティスは、時間外（つまり、ピーク時よりも御客様のサイトへのトラフィックが少ない時間帯）にスケジュールすることです。

カスタム・オブジェクトについての追加情報:

• Creating Custom Objects （英語）
• Creating Indexes on a custom object　（英語）
• カスタム・オブジェクトのデプロイメント・エラー・メッセージ

カスタム・フィールド

変更しているテーブルのサイズ（サイトのインシデント数や連絡先数など）によっては、カスタムフィールドの追加に時間がかかることがあります。ただし、カスタム・フィールド作成中、数時間たっても引き続きCXコンソールでカスタム・フィールドが固まってしまった場合は、テクニカルサポートへお問い合わせを提出していただきますことをお薦めいたします。

カスタムフィールドについての追加情報:

• カスタム・フィールドの追加
• Answer ID 7344:カスタム・フィールドの追加または編集時のエラー:「次のテーブルの行数が最大許容数を超えています。」