EBX® 5.9 から EBX® 6 への移行ガイド

メモリの全体量は以前のバージョンと同じままでかまいませんが、アプリケーションサーバーとオペレーティングシステムの間で異なる方法でディスパッチする必要があります。詳細については、メモリ管理セクションを参照してください。

この新しいバージョンは、メモリからインデックスをオフロードして、永続的な方法で格納します。追加のディスク容量が必要です。詳細については、ディスクセクションを参照してください。

パフォーマンスとチューニング > 環境の他のセクションを注意深く読んでください。

カスタム EBX® インメモリインデックス内のキャッシュにデータを完全に含めることができる小さなテーブルを考えてみましょう。ランダムなテーブルルックアップを使用してレコードに繰り返しアクセスする方が安価でした (ただし、これは一般的にデータベースと情報検索のアクセスパターンとして推奨されていません)。この新しいバージョンでは、新しい SQL 機能を利用して、これらのアクセスを書き直す必要があります。たとえば、「ネストされたループ」結合を実行する Java コードの場合 (テーブル A の RequestResult を繰り返し、テーブル B の osd:tableRef を検索)、このバージョンでは、SQL 結合によるクエリを使用することで、より適切に処理されるようになります。

EBX® には、特にクエリとリクエストの送信済みインスタンスの最適化に役立つ ApacheCalcite フレームワークが組み込まれています。ただし、クエリの最適化にはそれ自体にコストがかかります。このオーバーヘッドは、クエリの実行に比べて一般的に低く (そして十分に回収されます)、場合によっては、特にループが 1 つのパラメーターのみが異なる多数のクエリを生成した場合に加算される可能性があります。その場合は、パラメーター化されたリクエスト (Request.setXPathParameterを参照) またはパラメーター化されたクエリ (Query.setParameterを参照) を使用します。

プログラムによるアクセスルールは、Java インターフェイス AccessRule の実装に関係します。クエリの実行時に、テーブルにこのようなルールを設定することは、レコードごとにメソッド getPermission を実行することを意味します。このような実行は、インデックスに対して最適化するという目的を無効にします。

可能であれば、これらのプログラムによるアクセス ルールを新しいスクリプト化されたレコード アクセス権ルールに置き換えます。

プログラムラベルは、Java インターフェイス TableRefDisplay、UILabelRenderer、および ConstraintEnumeration の実装に関係します。クエリの実行時に、外部キーフィールドにこのようなルールを設定することは、レコードごとにメソッド displayOccurrence を実行することを意味します。このような実行は、インデックスに対して最適化するという目的を無効にします。可能な場合は、パターン文字列を使用してください。

プログラムによるフィルターは、Java インターフェイス AdaptationFilter の実装に関連しています。クエリの実行時に、このフィルターを使用すると、レコードごとにメソッド accept が実行されます。このような実行は、インデックスに対する最適化の目的を無効にします。可能であれば、プログラムによるフィルターを新しい SQL クエリに置き換えます。

大規模なデータセットへの依存関係が不明な制約は、検証リクエストごとにチェックされるため、避けてください。詳細については、データ検証を参照してください。

トランザクション (Procedure および TableTrigger の Java 実装) のパフォーマンスを改善するには、不要なインデックスの更新を回避する必要があります。詳細については、不要なインデックスの更新を参照してください。

検索の制限事項で説明されているように、継承されたフィールドは新しいインデックスの最適化の恩恵を受けることができません。可能な限り、これらのフィールドをリンクされたフィールドに変換することをお勧めします。

EBX® 5.9 アプリケーションサーバーインスタンスをシャットダウンします。

EBX® 5.9 リポジトリ、つまり現在のリポジトリプレフィックス (ebx.persistence.table.prefix) で始まる名前のリレーショナルデータベースオブジェクトをバックアップします。

次の手順を容易にするために、EBX® ログをバックアップして削除するか、別のフォルダーに移動します。

EBX® 5.9 アプリケーションサーバーインスタンスを再起動します。

閉じたデータスペースは移行されません (つまり、削除されます)。このようなデータスペースを保持する場合は、移行する前に再度開く必要があります。それらを保持するつもりがない場合は、それらを削除してパージ (削除) することをお勧めします。

移行の期間を短縮するには、完了したワークフローをすべて削除し、ワークフロー履歴をクリーンアップすることを検討してください。

自動移行では、リポジトリデータセットで使用されるすべてのデータモデルがエラーなしでコンパイルされる必要があります。この厳格なポリシーは、データの意図しない損失を防ぎ、サーバーの起動時に一貫したリポジトリ状態に到達するために採用されています。

このステップの目標は、リポジトリ内の少なくとも 1 つのデータセットで使用されるすべてのデータモデルにエラーがないことを確認することです。

これを確実に行うには、最初にデータモデルのコンパイルレポートを読む必要があります。

1. データモデルのコンパイルレポートは、サーバーの起動から次の行まで、「カーネル」ログに表示されます。

   ******** EBX(R) started and initialized. ********

2. ログのこの部分では、データモデルのコンパイルレポートは次のように始まります。

   ****** Schema

3. エラーメッセージは次で始まります。

   error [

注意：データモデルのコンパイルレポートは、[管理] > [テクニカル構成] > [モジュールとデータモデル] ページへの Web アクセスからも入手できます。各レポートは個別に展開する必要があります。

データモデルにエラーがある場合は、修正する必要があります。または、これらのデータセットが使用されなくなった場合、エラーのあるデータモデルに基づいてデータセットを削除できます (ただし、データモデルに基づいてデータセットを定義するすべてのデータスペースのデータセットを削除する必要があることに注意してください。別の方法として、カスタムプロパティを使用することもできます。EBX® 6 に展開する場合、スキーマまたはスキーマのリストに基づいてすべてのデータセットをグローバルに除外します。ステップ 11 を参照)。

すべてのクリーンアップが完了したことを確認したら、ログを削除し、ステップ 3 (アプリケーションサーバーを再起動) に戻って、エラーのあるデータモデルがないことを確認します。

注意：DAMA アドオンが使用されている場合：DAMA 1.8.x で非推奨としてマークされた API は、DAMA 2.0.0 では使用できなくなりました。データモデルがこれらの非推奨の API を宣言している場合は、コンパイルエラーを防ぐために、最新の API を使用するようにデータモデルを更新してください。

非推奨の API とその代替品のリストについては、Digital Asset Manager のドキュメントを参照してください。

EBX® 5.9 環境に展開されたアドオンが含まれている場合は、追加の手動介入が必要です。詳細については、次のセクションを参照してください。

EBX® 5.9 アプリケーションサーバーインスタンスをシャットダウンします。

ステップ 2 の説明に従って、EBX® 5.9 リポジトリのバックアップを繰り返します。

一部のクラスが EBX® 6 のインターフェイスに変換されているため、すべてのカスタム Java コードを新しいバージョンに対して再コンパイルする必要があります (それ以外の場合、実行時に java.lang.IncompatibleClassChangeError エラーが発生します)。

この手順では、リリースノートに記載されている下位互換性の問題とアドオンからの問題を評価する機会を提供します。

アプリケーションサーバーに展開されているすべての ebx*.war と ebx.jar ファイルを、EBX® 6 で提供される新しいアーティファクトに置き換えます。詳細については、Java EE 展開を参照してください。

EBX® アドオンを使用する場合は、すべての ebx-addon-*.war ファイルと ebx-addons.jar ファイルを EBX® 6 に準拠した新しいバンドルで提供されるファイルに置き換えます。

EBX® 6 で展開されたアプリケーションサーバーインスタンスを再起動します。

少なくともデータモデルにまだエラーがある場合、自動移行は自動的に停止され、ログにはこれらのエラーに関係するデータセットの詳細が示されます。修正を容易にするために、ログには、プロパティ ebx.migration.5to6.excludeAllDatasetsOnDataModels に失敗したスキーマの場所を予期された形式でフィードする提案も提供されます。次のステップとして、2 つのオプションがあります。

• これらのデータセットを移行から除外することに同意する場合は、このプロパティを ebx.properties にコピーします。

• この提案を受け入れない場合は、ステップ 3 に戻る必要があります。

エラーのあるデータモデルがない場合、データベーススキーマとデータは自動的に移行されます。データの量によっては、このプロセスに時間がかかる場合があります。