メッセージ・フローのマイグレーション

ご使用のバージョン 2.1 製品 (WebSphere MQ Event BrokerWebSphere MQ Integrator Broker、または WebSphere MQ Integrator) で作成したメッセージ・フローをマイグレーションし、WebSphere Business Integration Message Broker バージョン 5.0 でそれらを使用することができます。

(WebSphere MQ Event Broker バージョン 2.1 からマイグレーションする場合は、このトピック内でユーザー定義のプラグインおよび ESQL に言及したすべての情報は適応されません。これらの機能は、WebSphere MQ Event Broker バージョン 2.1 では利用できません。)

使用可能な新しいノードおよび機能を利用するために、マイグレーションするメッセージ・フローを変更したい場合があります。 たとえば、Web サービス要求を受け取るユーザー定義のノードを、組み込み HTTPInput ノードに置換したい場合があります。このリリースにおける上記の変更の詳細については、新着情報 を参照してください。

同じメッセージ・フロー・プロジェクト内で定義するなら、一度に複数のメッセージ・フローをマイグレーションすることができます。 一貫性のある参照のために、メッセージ・フローに組み込まれているサブフロー およびユーザー定義のノードをメッセージ・フローと共にマイグレーションする必要があります。

複数のメッセージ・フローを同じ名前で定義した場合、または複数のエクスポート・ファイルに メッセージ・フローがエクスポートされている場合には、マイグレーション作業により、既存のメッセージ・フローが次に同じ名前で見つかるフローで、警告が与えられることなく上書きされます。 それで、矛盾を避けるために注意が必要であり、また複数回定義済みのメッセージ・フローの最新のバージョンが 最後にマイグレーションされるようにしなければなりません。

同じメッセージ・フローの複数のバージョンを持っており、同じマイグレーション・ディレクトリー内のその他のフロー内のサブフローとしてメッセージ・フローを使用する場合、インポートの結果は予測できません。

メッセージ・フローをマイグレーションするには、次のようにします。

  1. バージョン 2.1 をアンインストールする前に、バージョン 2.1 ツールを使用してコントロール・センターから 1 つ以上のメッセージ・フローをエクスポートします (詳細については、バージョン 2.1 ライブラリーを参照してください)。

    マイグレーション・プロセスは、参照されるすべてのサブフローを同じエクスポート・ファイルに組み込むと最も効果的です。したがって、単一のメッセージ・フロー・プロジェクトにマイグレーションしたいすべてのメッセージ・フローを、単一のエクスポート・ファイルにエクスポートすることをお勧めします。

  2. エクスポート・ファイル (1 つ以上) を、ワークベンチ を実行している新規のシステムに転送します。 これらのファイルを保管するディレクトリーに他のファイルが何も含まれていないことを確認します。 単一のメッセージ・フロー・プロジェクトにインポートするファイルを別々のディレクトリーに保管し、それぞれのディレクトリーを別々にマイグレーションします。 サブディレクトリー内のファイルはマイグレーション・コマンドに無視されるため、ファイルをプロジェクト・ディレクトリーのサブディレクトリーに保管しないようにしてください。
  3. ワークベンチ・セッションをアクティブにする場合は、ワークベンチをクローズする必要があります。 ワークベンチ が実行している場合、マイグレーション・コマンドを実行することはできません。
  4. コマンド・プロンプトでは、新規のプロジェクト名およびエクスポート・ファイルを保管したディレクトリーを指定して、mqsimigratemsgflows・コマンドを呼び出します (このコマンドの詳細については、mqsimigratemsgflows コマンド を参照してください)。 コマンドが完了したときには、次のようになっています。
    • 指定されたディレクトリー内のエクスポート・ファイルに含まれているメッセージ・フローは、指定のメッセージ・フロー・プロジェクトにインポートされています。 プロジェクトがすでに存在していた場合、現行の内容があればそれと共に、追加のメッセージ・フローが組み込まれます。 プロジェクトがコマンドの呼び出し前に存在しなかった場合、それは作成されます。 コマンドでメッセージ・フロー・プロジェクトを作成できるようにすることをお勧めします。
    • メッセージ・フローおよびサブフローが作成されて、それらの定義は <flow_name>.msgflow という名前のファイルに保管されています。 ユーザー定義のノードが作成され、それらの定義は <node_name>.msgnode という名前のファイルに保管されています。

      ローカルの命名規則に従うために、インポート後にこれらのメッセージ・フローまたはノードのいずれかを名前変更したい場合には、すべての参照の一貫性および整合性を保存するために ワークベンチ で提供されている機能を使用する必要があります。 ファイル・システム内のいずれのファイルも名前変更しないでください。

    • メッセージ・フロー内のノードで ESQL を含むものがあった場合、それらの ESQL はノードそのものから抜き出され、ESQL ファイル <message_flow_name>.esql に保管されます。 それぞれのノードの ESQL が適切な CREATE MODULE ステートメントと END MODULE ステートメント間でラップされます (Compute、Database、または Filter の場合)。 ESQL ファイルは、すでに存在しない場合はこのコマンドによって作成されます。

      変更の始まりESQL エディターのプリファレンス・ページで、ESQL のデフォルト互換性レベルをチェックしてください。 このオプションのデフォルト値は 5.0 で、メッセージ・フローをバー・ファイルに追加する際に、レベル 5.0 のランタイム ESQL コードが生成されることになります。 このコードは、バージョン 2.1 のブローカーとは非互換です。 バー・ファイルにバージョン 2.0 のランタイム ESQL を組み込みたい場合には、エディターのプリファレンスを初期化する必要があります。 そのようにする場合、ESQL コードにバージョン 5.0 の機能拡張を組み込むことはできませんが、バージョン 2.1 とバージョン 5.0 の両方のブローカーにフローをデプロイすることができます。 詳細は、ESQL エディターを参照してください。変更の終わり

  5. コマンドを呼び出したディレクトリーに書き込まれたレポート・ファイル mqsimigratemsgflows.report.txt をチェックします。 コマンドは、以下の情報を提供します。
    • それぞれのメッセージ・フロー、サブフロー、およびユーザー定義のノードの名前。 これらのリソースにバージョン 5.0 とは非互換の名前があった場合、整合性を確実なものとするために、その名前とその名前への参照のすべてがコマンドにより更新されます。 (無効な名前のあるリソースを複数回マイグレーションする場合、その名前の修正は常時同じものとなります。)
    • マイグレーションされた各リソースの成功または失敗。
    • 見つけられないサブフローがあるという表示 (サブフローの定義がエクスポート・ファイルのどれにも含まれていないが、サブフローは 1 つ以上のマイグレーション済みのメッセージ・フローには含まれている)。 これが起きた場合、欠落しているサブフローを見つけ、適切なプロジェクトにそのサブフローをインポートして、このエラーを解決してください。 何らかの理由で欠落しているサブフローを検索できない場合、そのサブフローを元の名前で再作成してください。 その後、影響を受けたすべてのフローは新しいサブフローに正しくリンクすることができます。

      エクスポートおよびインポート・プロセス全体を繰り返す必要はありません。

    • メッセージ・フローとしてマイグレーション済みで .msgflow ファイルに保管されたりソースが、ユーザー定義のノードである可能性があるという表示。 この警告が与えられた場合、指定されたリソースがユーザー定義のノードであるか またはメッセージ・フローであるかをチェックする必要があります。 メッセージ・フローである場合、それは正常にマイグレーション済みです。 それがユーザー定義のノードであるなら、11 ステップで概略されている処置を完了する必要があります。
  6. ワークベンチ を開始し、「ブローカー・アプリケーション開発 (Broker Application Development)」パースペクティブ に切り替えます。
  7. マイグレーション・コマンドによって作成または更新されたメッセージ・フロー・プロジェクトを開きます (プロジェクトを右クリックし、「プロジェクトを開く (Open Project)」を選択します)。 プロジェクトがすでに開かれている場合、右クリックして 「リフレッシュ (Refresh)」「プロジェクトの再ビルド (Rebuild Project)」を選択し、「ナビゲーター (Navigator)」ビューが新規の内容を反映するようにします。 再ビルドにより、メッセージ・フロー・プロジェクトの内容の妥当性検査も行われます。

    ESQL およびマッピングがバージョン 5.0 とは異なる方法で処理されるので、マイグレーション・プロセスは、バージョン 2.1 の一部のノードをバージョン 5.0 の別のノードに置換します。 置換されたノードについては、以下の表で示します。 それぞれのノードと関連付けられた ESQL は、デフォルト名を持つモジュール、およびそのモジュールの名前に設定されたノード・プロパティーとして作成されます。

    バージョン 2.1 ノード バージョン 5.0 ノード
    Compute Compute
    Filter Filter
    Database Database
    DataDelete Database
    DataInsert Database
    DataUpdate Database
    Extract Compute
    Warehouse Database
  8. メッセージ・フローに 1 つ以上の Filter ノードが含まれている場合、ESQL ファイル内の各ノードの ESQL モジュールをチェックして、RETURN ステートメントがブール値に解決される有効な式を正しく戻すことを確認してください。
  9. メッセージ・フローに ESQL を持つノードが含まれており、インポートされた C ヘッダーから派生したメッセージ内のフィールドをその ESQL が参照している場合、C ヘッダーをワークベンチ にインポートすることでメッセージ・モデルを再作成したなら、このメッセージを参照する ESQL ステートメントを検査してください。 バージョン 5.0 の ワークベンチ へインポートをした場合、バージョン 2.1 のインポーターで作成した場合と異なる命名規則でモデルが作成されることがあるので、1 つ以上のフィールド参照を更新する必要があるかもしれません。
  10. 複数のノードで ESQL を再使用するために ESQL カスタマイズを組み込んだバージョン 2.1 ノードのいずれかの ESQL プロパティーをプロモートした場合、ESQL 関連プロパティーのプロモーションはサポートされなくなっているため、これはマイグレーションされたバージョン 5.0 メッセージ・フロー内では保守されません。 「タスク (Tasks)」ビューは、それぞれの ESQL プロモート・プロパティーごとにエラーを示します。 同じ結果を得るには、ESQL 機能を作成し、それぞれのノードの ESQL モジュールからその機能を呼び出す必要があります。
  11. ユーザー定義のノードをマイグレーションした場合、XML インターフェース定義ファイルのみがノードの .msgnode ファイル (これはノードのターミナルおよびプロパティーだけを定義します) にマイグレーションされます。 ユーザー定義のノードのマイグレーションおよび定義は、製品のこのバージョンで手動で完了する必要があります。 以下のステップは、必要なプロセスの概要を説明しています。完全な詳細については、ワークベンチでのユーザー定義ノードのユーザー・インターフェース表現の作成 を参照してください。
    1. ユーザー定義のノード・プロジェクトを作成し、メッセージ・フロー・プロジェクトから新しいユーザー定義のノード・プロジェクトに .msgnode ファイルを移動します。 これを行うとき、関連するプロパティー・ファイルが作成されます。
    2. オプショナル: ユーザー定義のノードの開発を Eclipse 環境で完了し、ユーザー定義のノード Eclipse プラグイン (このノードを構成するファイルを収めたディレクトリー構造) を作成します。 この作業には、必要に応じてヘルプ、アイコン、およびプロパティー・エディターとコンパイラーのノード・リソースを作成することが含まれます。
    3. タスク・リストにエラーがないか検査します。 ノードまたはそのターミナル名にスペース文字 (バージョン 5 ではサポートされていません) が含まれている場合、またはフローに別のマイグレーション済みフローが組み込まれていて、参照が正しくない場合に、エラーが生成されることがあります。 名前を修正するか、「サブフローの配置 (Locate subflow)」メニュー・オプションを使用することによって、これらのエラーを解決してください。
    4. ノード (.lilファイル) のランタイム・コードを適切なブローカー・システムにインストールします。 マイグレーション時に、ユーザー定義のノードのコードを再コンパイルする必要はありません。
    5. ブローカーを停止および再始動し、新規または変更済みのファイルを認識させます。

関連概念
メッセージ・フロー
ESQL の関数

関連タスク
既存のメッセージ・フローを開く
メッセージ・フローの内容の定義
ESQL の開発

関連資料
「ブローカー・アプリケーション開発 (Broker Application Development)」パースペクティブ
ESQL エディター
組み込みノード
mqsimigratemsgflows コマンド