ステップ 2: リポジトリの準備

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

はじめに

実稼働環境に移行する前に、少なくともテスト環境と稼働前環境ですべての移行タスクを実行することを強くお勧めします。EBX® 6 アーティファクトを含むサーバーを起動すると、リポジトリの移行が自動的に開始されます。このプロセスは元に戻せません。リポジリ内のデータモデルにエラーが含まれていない場合にのみ、移行が正常に完了します。
注意:
実稼働環境のリポジトリのコピー、または実稼働中のリポジトリによく似たものを使用することをお勧めします。これにより、実稼働環境のリポジトリを準備するために必要な労力を見積もることができ、自動移行プロセスにかかる時間を把握できるため、それに応じてダウンタイムを計画できます。
リポジトリを移行用に準備するには、次のタスクの手順を完了します。

タスク 1：バックアップの作成

移行プロセスは元に戻すことはできません。この点を考慮して、リポジトリを現在の状態でバックアップすることが重要です。
注意:
リポジトリを 5.9 から移行する場合でも、以前のバージョン 6 からアップグレードする場合でも、リポジトリをバックアップすることが重要です。
リポジトリをバックアップするには、次の手順を実行します。
  1. EBX® 5 インスタンスをホストしているアプリケーションサーバーをシャットダウンします。
  2. EBX® 5 リポジトリをバックアップします。名前が現在のリポジトリプレフィックスで始まるリレーショナルデータベースオブジェクトをすべて含めます。このプレフィックスは、ebx.properties ファイルの ebx.persistene.table.prefix の下に指定されています。
  3. EBX® ログをバックアップして削除するか、別のフォルダーに移動します。
  4. アドオン構成をバックアップします。
    TIBCO EBX® データモデルおよびデータ視覚化アドオン、または TIBCO EBX® GO アドオンをお持ちの場合は、構成アーカイブをエクスポートし、移行の完了後に再度インポートする必要があります。手順については、アドオンの手動移行 を参照してください。

タスク 2: リポジトリの準備

移行プロセスを高速化するには、特に大量のデータを含むリポジトリの場合、EBX® 5.9 環境をクリーンアップすることが重要です。このプロセスは EBX® ユーザーインターフェイスで実行する必要があるため、EBX® への管理アクセスが必要です。
バージョン 6.2.3 以降のデータ圧縮の変更により、不要なデータスペースをすべて削除することが特に重要です。移行では、辞書が作成され、すべてのブロックが新しい形式に書き換えられ、コンテンツを共有できるブロックが検索され、辞書を使用してブロックが再圧縮されます。
次のリポジトリエレメントをクリーンアップする必要があります。

データスペースのクリーンアップ

閉じられたデータスペースは移行中に削除されます。移行前に保持したいデータスペースを再度開く必要があります。移行処理時間を最適化できるように、保持しない閉じられたデータスペースは移行前に削除して消去することをお勧めします。
データスペースを管理するには、次の手順を実行します。
  1. > > に移動します。
  2. データスペースを再度開くか削除します。
    • 削除する場合は、削除するデータスペースを選択し、テーブルの メニューから を選択します。
    • 再度開く場合は、削除するデータスペースを選択し、テーブルの メニューから を選択します。
    dataspace-cleanup.png
  3. パージ後、G\_BLK テーブルを確認します。以下のいずれかに該当する場合は、移行時間を短縮するための追加のクリーンアップについてサポートを受けるために、移行前にサポートに連絡してください。
    • G\_BLK テーブルの行数が 1,000 万行を超える場合、または
    • ペイロードが 100 GB を超える場合、または
    • G\_TRV テーブルの行数が 1 万行を超える場合

ワークフローのクリーンアップ

ワークフローのクリーンアップはオプションの手順です。ただし、すべてのワークフローテーブルは自動的に移行され、これらのテーブルは大きくなる可能性があるため、移行処理時間が長くなる可能性があります。ビジネスユースケースでワークフロー履歴が必要ない場合、または監査証跡の「保存」データベースに外部化できる場合は、テーブルを消去すると移行プロセスを高速化できます。
完了したワークフローを削除するには、次の手順を実行します。
  1. > > > に移動します。
  2. が に設定されているテーブルにフィルターを作成します。
  3. すべてのレコードを選択し、テーブルの メニューから を選択します。
    workflow-clean-1.png
    ワークフロー履歴を削除するには、次の手順を実行します。
  4. > > に移動します。
  5. 削除するすべてのレコードを選択し、テーブルの メニューから を選択します。
    workflow-clean-2.png

データモデルのクリーンアップ

移行プロセスを正常に完了するには、リポジトリのデータセットで使用されるすべてのデータモデルがエラーなしでコンパイルされる必要があります。この厳格な要件は、データの損失を防ぎ、移行プロセスの終了時にリポジトリの一貫した状態を確保するために設けられています。また、廃止されたアドオンの成果物は、データモデルから削除する必要があります。
データモデルをクリーンアップするには、次のセクションで説明するトピックを参照してください。

データモデルエラーの解決

データモデルエラーを解決するには、次の手順を実行します。
  1. 次の場所を確認して、データモデルエラーを見つけます。
    • > > に移動し、データモデルエラーがないか確認します。
      dataModel-cleanup.png
    • kernel.log ファイルを開き、error [-] を検索します。
      errorExample.png
  2. データモデルエラーを修正するために必要なアクションを実行します。または、データモデルが使用されなくなった場合は、削除できます。ただし、これは、子データスペースを含む、データモデルに基づいてデータセットを定義するすべてのデータスペースでも実行する必要があります。
  3. アプリケーションサーバーを再起動し、 テーブルとログを再確認して、まだエラー状態にあるモデルがないことを確認します。

廃止されたアドオンのインクルード

TIBCO EBX® Match and Merge Add-on (DAQA) がデータモデルに含まれている可能性があります。その場合、データモデルから include 命令とそのデータ型に基づくエレメントを削除する必要があります。
廃止されたアドオンに対処するには、次の手順を実行します。
  1. kernel.log ファイルを開き、****** Schema で始まるデータモデルコンパイルレポートを検索します。レポートに Include: Module: ebx-addon-daqa という情報行が含まれているかどうかを確認します。
    次の例では、カスタム モジュール ebx-sample-test に、Persons モデルへの包含が含まれています。
    daqa-dataModel-includes.png
  2. データモデルの XSD を開き、/WEB_INF/ebx/schema/ebx-addon-daqa-types.xsd を削除します。
    daqa-xsd-remove.png
  3. 定義されたタイプ DaqaMetaData を持つエレメントを検索して削除します。
    daqa-element-remove.png
  4. 上記の手順で変更されたエレメントを使用していた他のエレメントを検索して変更します。
    daqa-other-remove.png

廃止されたアドオンの Java 拡張機能

廃止されたアドオンによって提供される Java 拡張機能は、データモデルから削除する必要があります。すべての XSD ファイルを確認し、以下の非網羅的なリストへの参照をすべて削除する必要があります。
  • TIBCO EBX 情報ガバナンス アドオン (IGOV) の場合は、 com.orchestranetworks.addon.igov.IGovLabelingSchemaDocumentation の使用を確認します。
  • TIBCO EBX ルール ポートフォリオ アドオン (RPFL) の場合は、データモデル拡張機能 com.orchestranetworks.addon.rpfl.DefaultSchemaExtension の使用を確認します。
  • TIBCO EBX Information Search Add-on (TESE) の場合、テーブルフィルター com.orchestranetworks.addon.tese.SearchTableFilter の使用を確認してください。このアドオンは廃止されていませんが、これを改良バージョンに置き換え、従来のバージョンを展開しない場合は、トリガーを削除する必要があります。
  • TIBCO EBX Insight Add-on (DQID) の場合、トリガー com.orchestranetworks.addon.dqid.controller.DQIdTrigger の使用を確認してください。このアドオンは廃止されていませんが、これを改良バージョンに置き換え、レガシーバージョンを展開しない場合は、トリガーを削除する必要があります。
上記の項目を確認することに加えて、データモデルによって定義されたツールバーを確認することもお勧めします。ツールバーにはアドオンからのユーザーサービスが含まれることがあるためです。

URL ポリシー

5.9 の URL ポリシーは非推奨です。更新しないと、UI にアクセスしようとしたときに問題が発生する可能性があります。URL ポリシーが 6.x の要件に準拠していることを確認するには、 > > > > > に移動して、既存の設定を元に戻します。URL コンピューティング構成を更新するには、ebx.properties ファイルを編集します。詳細については、URL コンピューティング を参照してください。

タスク 3: クリーンなリポジトリのバックアップ

現在のリポジトリをバックアップします。
  1. EBX® 5.9 インスタンスをホストしているアプリケーションサーバーをシャットダウンします。
  2. 5.9 リポジトリをバックアップします。名前が現在のリポジトリ プレフィックスで始まるリレーショナルデータベースオブジェクトをすべて含めます。このプレフィックスは、ebx.properties ファイルの ebx.persistene.table.prefix の下に指定されています。
  3. EBX® ログをバックアップして削除するか、別のフォルダーに移動します。
  4. アドオン構成をバックアップします。
    TIBCO EBX® データモデルおよびデータ視覚化アドオン、または TIBCO EBX® GO アドオンをお持ちの場合は、構成アーカイブをエクスポートし、移行の完了後に再度インポートする必要があります。手順については、アドオンの手動移行 を参照してください。