ステップ 1: カスタムコードの適応

最終公開日 : Sep 16, 2026
Related information

概要

開発者として、移行をサポートする役割は、EBX® 実装で使用されるカスタムコードが新しい EBX® バイナリに対してコンパイルされ、正常に展開できることを保証することです。このタスクでは、新しい EBX® 6 アーキテクチャの 違いを理解している ことと、それが既存のカスタム Java コードのパフォーマンスにどのように影響するかを理解していなければなりません。また、TIBCO EBX® リリースノート に記載されている下位互換性に関する情報にも精通している必要があります。
新しいアーキテクチャがカスタムコードに与える影響 を確認して、カスタムコードの更新プロセスを開始します。次に、コードの適応と移行のテスト の手順に従います。テストフェーズが正常に完了すると、次のようになります。
  • コードの調整とテストが完了。
  • ローカル環境での移行を正常にテストするための必要なデータモデルとプロジェクトの変更が完了。
  • 実稼働前の環境での展開とテストが可能な新しいバイナリの生成が完了。

新しいアーキテクチャがカスタムコードのパフォーマンスに与える影響

新しいスケーラブルなアーキテクチャは、カスタム Java コードのパフォーマンスに影響を与える可能性があります。以前は問題なく動作していたシナリオでも、調整が必要になる場合があります。特に、次の項目の置き換えや最適化に重点を置いてください。
主キーによる繰り返しルックアップ
以前は、カスタム EBX® インメモリインデックスのキャッシュにテーブル全体のデータが含まれる場合、ランダムテーブル検索を使用してレコードにアクセスする方がコストがかかりませんでした。このタイプのアクセスは、新しい SQL 機能を利用するために書き直す必要があります。たとえば、テーブル A の RequestResult が反復され、テーブル B で osd:tableRef が検索されるネストされたループ結合を実行する Java コードを考えてみましょう。SQL 結合を使用して検索を処理する Query を実装する必要があります。
類似リクエストの繰り返し作成
EBX® には、Apache Calcite フレームワークが組み込まれ、送信された Query および Request インスタンスが最適化されるようになりました。クエリの最適化にはコストがかかりますが、最適化されていないクエリを実行する場合と比較すると、通常はコストが低く、回収できます。ただし、ループによって 1 つのパラメーターのみが異なる多数のクエリが生成される場合は、大幅なオーバーヘッドが発生する可能性があります。この場合、パラメーター化されたリクエスト (Request.setXPathParameter を参照) またはパラメーター化されたクエリ (Query.setParameter を参照) を使用するのが最適です。
プログラムによるアクセスルール
プログラムによるアクセスルールは、Java インターフェイス AccessRule を実装します。クエリの実行時にテーブルにルールを設定すると、各レコードに対してメソッド getPermission が実行されます。これにより、インデックスに対する最適化の利点が失われます。可能な場合は、これらのプログラムによるアクセスルールを、新しいスクリプト化されたレコード権限ルールに置き換える必要があります。
プログラムラベル
プログラムによるラベルは、Java インターフェイス TableRefDisplay、UILabelRenderer、および ConstraintEnumeration を実装します。クエリの実行時に、外部キーフィールドにルールを設定すると、各レコードに対してメソッド displayOccurrence が実行されます。これにより、インデックスに対する最適化の利点が無効になります。可能な場合は、代わりにパターン文字列を使用してください。
プログラムフィルター
プログラムフィルターは、Java インターフェイス AdaptationFilter を実装します。クエリの実行時にこのフィルターを使用すると、各レコードに対してメソッド accept が実行されます。これにより、インデックスに対する最適化の利点が失われます。可能な場合は、プログラムフィルターを新しい SQL クエリに置き換えてください。
依存関係が不明な制約
大規模なデータセットに対する依存関係が不明な制約は、検証リクエストごとにチェックされるため、避けてください。詳細については、データ検証 を参照してください。
不要なインデックスの更新
トランザクションパフォーマンス (Procedure および TableTrigger の Java 実装) を向上させるには、不要なインデックスの更新を避ける必要があります。詳細については、不要なインデックスの更新 を参照してください。
継承されたフィールド
検索の制限 で説明したように、継承されたフィールドは新しいインデックスの最適化の恩恵を受けることができません。その結果、継承されたフィールドで実行されるすべての操作 (クエリ、検証、データの比較など) は、EBX® 6 より前のバージョンと比較して遅くなります。パフォーマンスの問題を回避するために、継承されたフィールドを使用しないことを強くお勧めします。可能な場合は、ユースケースに応じて、これらのフィールドを リンクされたフィールド に変換するか、たとえばトリガーを使用して継承をシミュレートして継承されたフィールドの動作を置き換えることをお勧めします。
圧縮の最適化
リリース 6.2.3 以降、圧縮の実装では直接/ネイティブメモリを使用します。これにより、メモリ (およびインデックスとデータベースリソース) が迅速に返されるように、RequestResult および QueryResult オブジェクトをできるだけ早く明示的に閉じることの重要性が増します。以前は、ReverseRelationshipResult.getResult() は同じ RequestResult インスタンスを返していました。現在は常に新しい RequestResult を返します。使用後は必ず RequestResult を閉じるようにカスタムコードを更新してください。

コードの適応と移行のテスト

移行をテストする前に、EBX® 5 に関連するすべての JAR ファイルと WAR ファイルを環境から削除することが重要です。
  1. リポジトリの準備
    以下に、開発環境用にローカルリポジトリを準備するための高レベルのタスクを示します。移行用に実稼働前または実稼働リポジトリを準備する場合、または次の手順で説明するリポジトリのクリーンアップ タスクの詳細については、ステップ 2: リポジトリの準備 を参照してください。
    1. 既存のリポジトリをバックアップします。
    2. EBX® を起動し、すべてのデータモデルがエラーなしでコンパイルされることを確認します。
    3. 廃止されたアドオンに対するデータモデルの依存関係が存在しないことを確認してください。詳細については、サポートされるアドオンの変更 を参照してください。
    4. データスペースとワークフローをクリーンアップします。この手順はオプションです。ただし、移行中に閉じられたデータスペースは削除されることに注意してください。保持するデータスペースを再度開きます。この手順は、データスペースの数が多いと移行時間が長くなる可能性がある大規模なリポジトリでより効果的です。
    5. URL ポリシーが 6.x の要件に準拠していることを確認します。 > > > ブ > > に移動して、既存の設定を元に戻します。URL コンピューティング構成を更新するには、ebx.properties ファイルを編集します。詳細については、URL コンピューティング を参照してください。
    6. シャットダウンしてから、クリーンなリポジトリをバックアップします。
  2. コードの準備
    1. TIBCO eDelivery (eDelivery にアクセスするにはアカウントが必須です。アカウントをリクエストするには、サポートチームにお問い合わせください) から EBX® 6 バイナリをダウンロードし、次の JAR をローカル環境 (<your download directory>/ebx.software/libにあります) に展開します。
      • EBX® 6.0.x に移行する場合
        • EBX® API の場合：ebx.jar
        • 新しい圧縮アルゴリズムのサポート：ebx-lz4.jar
      • EBX® 6.x に移行する場合
        • バージョン 6.2.3 より前の場合のみ、新しい圧縮アルゴリズムをサポートするため: ebx-lz4.jar
        • EBX® Java API の場合：ebx-api.jar
        • サードパーティ Java API: ebx-resources-api.jar
    2. カスタムコードが新しい推奨事項と要件に準拠していることを確認するには、次の点を確認してください。
    3. カスタムライブラリまたは Web アプリケーションを再コンパイルします。
  3. ローカルサーバーを起動して自動移行を開始します。プロセスは正常に終了するはずです。kernel.log ファイルでログエントリ「EBX® Started and Initialized」を探します。
    問題が発生する可能性のある一般的な問題は次のとおりです。
    • EBX® 6 を使用してコンパイルされていないライブラリ。この場合、EBX® は例外「java.lang.IncompatibleClassChangeError」をスローします。
    • データモデルエラー。解決されていないエラーが残っている場合、移行プロセスは自動的に終了します。
    • プロジェクトが正しくビルドされていない場合、プロジェクトでコンパイルエラーが発生します。
ローカル環境での移行が正常に完了したら、より大きなリポジトリを使用して実稼働前環境に展開してテストできます。ただし、実稼働前環境でテストする場合は、アプリケーションサーバーを起動する前に、ステップ 2: リポジトリの準備 で説明されているプロセスに従ってリポジトリを準備する必要があります。