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

始める前に:

conditions for a Version 5.0 broker participating in a Version 6.0 broker domainに関する概念トピックに目を通しておきます。

ご使用のバージョン 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 ノードに置換したい場合があります。

このリリースにおける上記の変更の詳細については、バージョン 6.0 の新機能 を参照してください。

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

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

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

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

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

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

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

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

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

      変更の始まりメッセージ・フローを bar ファイルに追加すると、ランタイム ESQL コードがバージョン 6.0 レベルで生成されます。このコードは、バージョン 2.1 のブローカーとは非互換です。 bar ファイルにバージョン 2.0 のランタイム 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 ステートメントを確認してください。 バージョン 5.0 の バージョン 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, 2006 最終更新: 08/21/2006
ac02355_