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

始める前に:

バージョン 2.1 およびバージョン 6.0 製品の相違について目を通しておきます。

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

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

WebSphere MQ Integrator Broker バージョン 2.1 からマイグレーションした場合、XML ネーム・スペースを使用する XML メッセージを処理するメッセージ・フローを作成したかもしれません。 バージョン 2.1 では、そのような XML メッセージは、WebSphere Message Broker バージョン 6.0 で使用されるものとは異なる方法で構文解析されます。 バージョン 6.0 にホストされている場合、このようなメッセージ・フローは正常に動作し続けますが、ネーム・スペースを認識できるようにそれらをアップグレードしてください。

バージョン 6.0で使用可能な新しいノードおよび機能を利用するために、マイグレーションするメッセージ・フローを変更したい場合があります。例えば、Web サービス要求を受け取るユーザー定義のノードを、組み込み HTTPInput ノードに置換したい場合があります。

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

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

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

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

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

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

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

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

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

      メッセージ・フローを bar ファイルに追加すると、ランタイム ESQL コードがバージョン 6.0 レベルで生成されます。このコードは、バージョン 2.1 のブローカーとは非互換です。 bar ファイルにバージョン 2.1 のランタイム ESQL を組み込みたい場合には、「バージョン 2.1 のブローカー用に ESQL をコンパイルする」ボックスにチェック・マークを付けます。そのようにする場合、ESQL コードにバージョン 6.0 の機能拡張を組み込むことはできませんが、バージョン 2.1バージョン 6.0 の両方のブローカーにフローをデプロイすることができます。

      詳しくは、ブローカー・アーカイブへのファイルの追加を参照してください。

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

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

    • メッセージ・フローとしてマイグレーションされ .msgflow ファイルに保管されたリソースが、ユーザー定義のノードである可能性があるという表示。この警告が与えられた場合、指定されたリソースがユーザー定義のノードであるか メッセージ・フローであるかを確認してください。メッセージ・フローである場合、それは正常にマイグレーションされています。 それがユーザー定義のノードであるなら、11 ステップで概略されている処置を完了します。
  6. ワークベンチを開始し、「ブローカー・アプリケーション開発」パースペクティブに切り替えます。
  7. マイグレーション・コマンドによって作成または更新されたメッセージ・フロー・プロジェクトを開きます。

    プロジェクトが既に開かれている場合、右クリックして「リフレッシュ」「プロジェクトの再ビルド」をクリックし、「ブローカー開発」ビューが新しい内容を反映するようにします。再ビルドにより、メッセージ・フロー・プロジェクトの内容の妥当性検査も行われます。

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

    バージョン 2.1 ノード バージョン 6.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 ステートメントを確認してください。 バージョン 6.0ワークベンチへのインポート・プロセスによって、バージョン 2.1 のインポーターで作成した場合と異なる命名規則でモデルが作成されることがあるので、1 つ以上のフィールド参照を更新する必要があるかもしれません。
  10. 複数のノードで ESQL を再利用するために ESQL カスタマイズを組み込んだバージョン 2.1 ノードのいずれかの ESQL プロパティーをプロモートした場合、ESQL 関連プロパティーのプロモーションはサポートされなくなっているため、このプロモーションはマイグレーションされたバージョン 6.0 メッセージ・フロー内では保守されません。「タスク」ビューは、それぞれの ESQL プロモート・プロパティーごとにエラーを示します。 同じ結果を得るには、ESQL 機能を作成し、それぞれのノードの ESQL モジュールからその機能を呼び出します。
  11. ユーザー定義のノードをマイグレーションした場合、XML インターフェース定義ファイルのみがノードの .msgnode ファイル (このファイルはノードのターミナルおよびプロパティーだけを定義します) にマイグレーションされます。マイグレーションおよび定義は、バージョン 6.0 の製品で手動で完了してください。以下のステップは、必要なプロセスの概要を説明しています。 詳細については、ワークベンチでのユーザー定義ノードのユーザー・インターフェース表現の作成を参照してください。
    1. ユーザー定義のノード・プロジェクトを作成し、メッセージ・フロー・プロジェクトから新しいユーザー定義のノード・プロジェクトに .msgnode ファイルを移動します。 このファイルを移動するとき、関連するプロパティー・ファイルが作成されます。
    2. オプション: ユーザー定義のノードの開発を Eclipse 環境で完了し、ユーザー定義のノード Eclipse プラグイン (このノードを構成するファイルを収めたディレクトリー構造) を作成します。 この作業には、必要に応じてヘルプ、アイコン、およびプロパティー・エディターとコンパイラーのノード・リソースを作成することが含まれます。
    3. タスク・リストにエラーがないか検査します。 ノードまたはそのターミナル名にスペース文字 (バージョン 6.0 ではサポートされていません) が含まれている場合、またはフローに別のマイグレーション済みフローが組み込まれていて、参照が正しくない場合などに、エラーが生成されることがあります。名前を修正するか、「サブフローの配置」メニュー・オプションを使用することによって、これらのエラーを解決してください。
    4. ノード (.lil ファイル) のランタイム・コードを適切なブローカー・システムにインストールします。 マイグレーション時に、ユーザー定義のノードのコードを再コンパイルする必要はありません。
    5. ブローカーを停止および再始動し、新規または変更済みのファイルを認識させます。
リソースのマイグレーションが完了したら、マイグレーション後に実行できるタスクに関する情報について『(バージョン 2.1 からの) マイグレーション後の作業』を参照してください。
関連概念
メッセージ・フローの概要
ESQL の関数
関連タスク
メッセージ・フローでのネーム・スペース認識
既存のメッセージ・フローを開く
メッセージ・フローの内容の定義
ESQL の開発
関連資料
「ブローカー・アプリケーション開発」パースペクティブ
ESQL エディター
組み込みノード
mqsimigratemsgflows コマンド
特記事項 | 商標 | ダウンロード | ライブラリー | サポート | フィードバック

Copyright IBM Corporation 1999, 2009Copyright IBM Corporation 1999, 2009.
最終更新 : 2009-02-20 12:42:40

ac02355_