バージョン 5.0 からのマイグレーションの計画

コンポーネントおよびリソースをバージョン 6.0 にマイグレーションするために実行すべきステップの順序と範囲を計画します。

このセクションでは、マイグレーションを計画する方法について説明します。
  1. 製品コンポーネントをマイグレーションする方法を決定します。
    1. バージョン 6.0 の新機能について説明し、 新規のおよび変更された機能について学習します。 これらの変更は、今後、マイグレーション済みのコンポーネントを使用する方法に影響を与える場合があります。
    2. バージョン 6.0 コンポーネントが依存関係を持つ可能性のある、他の製品の要件を確認してください。 前提条件となる製品、および他のオプションの製品についての詳細は、インストール・ガイドおよびインストールの両方の参照セクションに示されています。
    3. 製品コンポーネントをマイグレーションする場所を決定します。同じコンピューターの別の場所または 2 番目のコンピューターにこれらをマイグレーションしてください。 例えば、コンポーネントを別の場所にマイグレーションして、マイグレーション中に可用性を維持することもできます。 構成マネージャー を別のオペレーティング・システムに移行させることも考慮できます。
    4. 製品コンポーネントをマイグレーションする時期を決定します。 現時点で、レベル バージョン 5.0 で一部のコンポーネントを保存し、後でそれらをマイグレーションすることもできます。
    5. コンポーネントをマイグレーションする順序を決定します。 任意の順序でコンポーネントをマイグレーションできますが、特定の状況では、特定の順序でコンポーネントをマイグレーションする必要がある場合もあります。

    以前のバージョンおよび他の製品との共存は、WebSphere Message Broker バージョン 6.0 を同じコンピューター上で以前のバージョンの製品と共存させる方法、およびバージョン 6.0 コンポーネントを以前のバージョンのコンポーネントと共に機能させる方法について説明します。

  2. 既存のリソースを WebSphere Message Broker バージョン 6.0 と共に使用する方法を決定します。
    アプリケーション・リソース

    ユーザー定義拡張子マッピング・ファイルがある場合に限り、メッセージ・フロー・ファイル、メッセージ・セット定義ファイル、ESQL ファイル、XML スキーマ・ファイル、およびブローカー・アーカイブ・ファイルなどの、開発およびデプロイメント・リソースをマイグレーションするための特定のタスクを実行する必要があります。

    これらのリソースはそのまま WebSphere Message Broker バージョン 6.0 で使用を開始できます。 ただし、ツールキット内でリソースをオープンまたは再ビルドするときに、いくつかのマイグレーション処置は自動的に実行されます。また、いくつかの動作上の変更が、メッセージ・フローおよびメッセージ・セットの使用方法に影響を与えることがあります。メッセージ・フローのマイグレーションの注意事項およびメッセージ・セットのマイグレーションの注意事項で示されている指針を参照してください。

    • すべてのバージョン 5.0 およびバージョン 5.1 のユーザー定義ノード・プロジェクトを、Message Brokers Toolkit バージョン 6.0 と連動させるためにアップグレードする必要があります。 プロジェクトをクリーニングする (「プロジェクト」 > 「クリーニング」をクリックする) ことによってプロジェクトをアップグレードします。 プロジェクトをクリーニングすると、バージョン 6.0 がユーザー定義拡張機能に含まれる ESQL ファイルをコンパイルするのに必要とされる拡張ポイントが、プロジェクト plugin.xml ファイルに作成されます。
    • mqsimigratemfmaps コマンドを使用して バージョン 5.0 マッピング・ファイル (.mfmap) を バージョン 6.0 マッピング・ファイル (.msgmap) にマイグレーションします。

    Message Brokers Toolkit バージョン 6.0 で現在のリソースの使用を開始した後、 それらのリソースの再使用は Message Brokers Toolkit バージョン 5.0 またはバージョン 5.1 での制約事項に従います。 詳しくは、以前のバージョンの Message Brokers Toolkit でのマイグレーション済みリソースの使用の条件を参照してください。

    変更の始まりコード・ページ・コンバーター変更の終わり
    変更の始まり

    WebSphere Business Integration Message Broker バージョン 5.0WebSphere Message Broker バージョン 6.0 の間でコンバーターが大幅に変更されているため、旧レベルの一連のコンバーターは WebSphere Message Broker バージョン 6.0 に含まれています。

    バージョン 5.0 環境でコンバーターを使用している場合は、マイグレーション後にもそれらの使用を継続できるように、追加のステップを取ることが必要になることがあります。 このタスクの詳細については、旧レベルの製品のコンバーターの使用を参照してください。

    変更の終わり
  3. マイグレーションが正常に行われるようにするために、どのテストを実施するかを決めます。

    マイグレーションのテストの目的は、マイグレーション中に発生する可能性のある問題を識別することです。 例えば、問題が発生すれば、マイグレーション済みの一部のリソースを、マイグレーションを開始する前にバックアップしたバージョン 5.0 のレベルにリストアしなければならなくなる可能性があり、そうなると、マイグレーション後にこれらのリソースに対して加えた変更はすべて失われることになります。 実動ドメインをマイグレーションする前に開発ドメインおよびテスト・ドメインをマイグレーションすることによって、こうした問題を識別し、さらに問題が生じた場合にそれに対処するための戦略を開発することができます。

    変更の始まりそれぞれの新規リリースには、外部動作に影響を与える製品の問題を解決する変更が含まれていることがあります。 アプリケーションが文書化されていない動作や正しくない動作に依存している場合、これらのアプリケーションをテストして、マイグレーションのスケジュールの際に必要な変更を行うための時間を確保する必要があります。変更の終わり

  4. オプション: マイグレーションする準備ができたら、-c パラメーターを使って mqsimigratecomponents コマンドを実行します。 この形式のコマンドにより、マイグレーションが可能であることを確認するために、バージョン 5.0 コンポーネントに対するマイグレーション前のチェックが実行されます。 マイグレーション前のチェックによって、潜在的な問題を識別し、マイグレーションに進む前にそれらを訂正することができます。
  5. オプション: 製品の動作の変更に応じてリソースを更新するための、マイグレーション計画の時間の追加を検討してください。 すべてのリリースには、外部の規格を確認するための修正などの、外部動作に対する機能拡張および修正が含まれています。 リソースが文書化されていない動作または不正確な動作に依存している場合 (例えば、Compute ノード内の ESQL コードなど)、ビジネス・シナリオに及ぼす影響を理解するために、これらのリソースに変更を加えてテストすることが必要になる場合があります。

マイグレーションを計画したら、リソースをバックアップします

関連タスク
バージョン 5.0 製品からのマイグレーション
小さなドメインをバージョン 5.0 からマイグレーションする計画
大きなドメインをバージョン 5.0 からマイグレーションする計画
複数のドメインをバージョン 5.0 からマイグレーションする計画
ハイ・アベイラビリティー・ドメインをバージョン 5.0 からマイグレーションする計画
バージョン 5.0 または バージョン 5.1 からのユーザー定義ノードのマイグレーション
マイグレーション済みのコンポーネントを以前のバージョンに復元する
旧レベルの製品のコンバーターの使用
関連資料
インストール・ガイド
mqsimigratecomponents コマンド
特記事項 | 商標 | ダウンロード | ライブラリー | サポート | フィードバック

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

ah20650_