このセクションでは、MQ トランスポートでメッセージを送受信するメッセージ プロキシの設定方法を説明します。

このセクションの内容:

MQ 必要条件

JAR ファイル

必要な JAR ファイルをクラスパスへ追加」を参照してください。

キューの割り当て

キューを介してトラフィックが交換される場合、「クライアント アプリケーションが宛先キューにリクエストを送信し、サーバー アプリケーションがキューからメッセージを受信する」と想定します。サーバーは、クライアントが受信する応答メッセージを 2 番目のキューに送信します。このシナリオでは、メッセージ プロキシはクライアントとサーバー間の「中間者」として機能し、仲介を促進するためにメッセージング プロバイダーにさらに 2 つのキューが必要です。Parasoft プロキシは、クライアントがメッセージを配置するキューからメッセージを取得し、内容を記録して (記録を有効にしている場合のみ)、サーバーがメッセージを受信するキューに配置します。同様に、サーバーはプロキシが取得しに行くキューにメッセージを送信し、プロキシはそのメッセージを記録し (記録を有効にしている場合のみ)、クライアントが返信レスポンスを受信するキューに配置します。

結果として、 2 つの追加キューの割り当てと、次のいずれかが必要となります。

  • クライアント アプリケーションを調整し、これら 2 つの新しいキューと通信するようにする (プロキシ接続を構成して調整)。
  • サーバー アプリケーションを調整し、別のキューを 2 つの使用するようにする。

2 つのアプリケーション キューのうち 1 つだけを修正する必要があります。

MQ 設定の指定

設定についてのヒント

さまざまな状況で記録を設定するためのヒントについては、「トラフィックの記録におけるキューの設定」を参照してください。

次の手順で MQ 設定を指定します。

  1. [プロキシ接続設定] ダイアログの [プロキシ タイプ] で MQ を選択します。

     
     
  2. Using Global Queue Managers」で説明するように定義済みのキュー マネージャーを参照するのではなく、このパネルでクライアントとサーバーのキューを定義している場合、[ローカル設定] エリアでサーバーの詳細を入力します。

    単一プロキシで複数のキューマネージャーを使用する

    単一プロキシ内で複数のキュー マネージャーへの接続を設定したい場合 ( たとえば、プロキシ接続で、2 つの異なるキュー マネージャー上でデプロイされる 2 つのキューを使用したい場合)、使用するキューごとにグローバル キュー マネージャーを作成し、プロキシの設定時に適切なキューマネージャーを選択します。

  3. クライアントとサーバーのキューを指定します。このパネルの [ ローカル設定] オプションで接続ごとに設定を入力するか、 サーバー レベルで定義されたグローバル キュー マネージャーを参照することができます (詳細については Using Global Queue Managers」を参照してください)。 

    SSL

    サーバーの [接続] タブ で SSL 構成を含む Virtualize サーバーで MQ キューを定義し、ドロップダウンメニューからグローバル キュー マネージャーを選択して設定をプロキシに適用できます。SSL 構成は、ローカル設定の構成ではサポートされていません。




    • put キューは常にテスト対象のアプリケーション/クライアントがリクエスト メッセージをプット/送信する場所です。"get" キューからはレスポンス メッセージを受け取ります。

    • Virtualize または SOAtest はクライアントの put キューに送信されたメッセージをキャプチャし、処理のためにサーバーの put キューに転送します。サーバーの get キューは、 (リクエストメッセージの処理の後で) サーバーがレスポンスメッセージを置くキューです。これらのメッセージはキャプチャされ、クライアントの Get キューに転送されます。

    • メッセージ プロキシが開始するときに、2 つのリスナーがメッセージプロキシによって作成されます。1 つ目のリスナーは、クライアントの put キューで作成されます。このリスナーはクライアント put キューからメッセージをピックアップし、サーバーの put キューに置きます。2 つ目のリスナーは、サーバーの get キューで開始し、サーバーの get キューからクライアントの get キューにメッセージを移動します。
    • プロキシがキューをオープンしたりサーバーの put キューにメッセージをプットしたりするときに使用されるオプションフラグをカスタマイズしたい場合、JVM システム プロパティ  parasoft.proxy.mq.put.open.options および parasoft.proxy.mq.put.options を、Virtualize または SOAtest が起動するときに指定できます。たとえば、MQMD ヘッダー putApplicationName のためのカスタマイズされた値がメッセージにあるものとします。キューのopen.options で MQOO_SET_ALL_CONTEXT フラグを設定し、put.options で MQPMO_SET_ALL_CONTEXT フラグを設定すると、メッセージ プロキシはカスタマイズされた putApplicationName ヘッダー値を転送することができます。

      オプションフラグの値については、IBM の mq_queue_get_open_options およびmq_message_put_options パラメーターを参照してください。例:

      soatest.exe -J-Dparasoft.proxy.mq.put.open.options=2052 -J-Dparasoft.proxy.mq.put.options=2064
      ここで使用される値は、個々のフラグによって表されるすべての値の合計です。たとえば、open.options の値 2052 は、3 つのフラグ MQC.MQOO_SET_ALL_CONTEXT、MQC.MQOO_INPUT_SHARED、および MQC.MQOO_INPUT_EXCLUSIVE がオンであることを意味します。

      キューの設定の詳細

      さまざまな状況で記録を設定するためのヒントについては、「トラフィックの記録におけるキューの設定」を参照してください。

  4. 必要に応じて [レスポンスに replyToQueueName を使用する] の設定を変更します。このオプションは、どこでプロキシがレスポンスを送るかを決定するためにメッセージの replyToQueueName ヘッダーを使用するかどうかを指定します。このオプションは、MQMT_REQUEST タイプの MQ メッセージへのレスポンスに影響します。
    • 有効な場合、受信リクエストからの値を使ってレスポンスの送信先が決定されます。オプションが有効ではない場合、レスポンスは GUI で指定されたキューに送られます。具体的には以下のとおりです。
    • オプションが有効であり、MQMD.replyToQueueManagerName と MQMD.replyToQueueName の両方の値が指定されている場合、これらの値によって、キュー マネージャーとレスポンスの送信先のキュー名の両方が決定されます。

    • オプションが有効であり、MQMD.replyToQueueManagerName または MQMD.replyToQueueName がリクエストにない場合、それらの値のかわりに GUI で指定された値が使用されます。
    • オプションが無効な場合、MQ リクエスト メッセージの replyToQueueName および replyToQueueManagerName フィールドは無視されます。GUI の設定によって、メッセージの送信先が決定されます。
  5. 必要に応じて [ワーカーのカウント] の設定を変更します。

    ワーカーのカウントを調整する

    各ワーカーが MQ プロバイダーに独自の接続を作成します。たとえば、20 のワーカーがある場合、WebSphere MQ Explorer では、メッセージ プロキシがリスンするリクエスト (get) キューの Open input count 列の値として 20 が表示されるはずです。デフォルト値の 1 より多いワーカーのカウントでプロキシがデプロイ/再デプロイされると、コンソールに「Started x listener(s)」というメッセージが表示されます (x には構成されたワーカー数が入ります)。 

    ワーカーのカウントを増やすことは並列時のパフォーマンスに役立ちます。プロキシのメッセージ処理チェーン全体が並列化され、各ワーカーのスレッドは他のスレッドと並行してメッセージ応答条件、レスポンス メッセージの生成などを行います。しかし、高いワーカーのカウントを提供すると、作成/破棄する接続が増えるため、プロキシのデプロイ/アンデプロイ/再デプロイに時間が掛かります。また、 MQ インフラストラクチャに許可する同時接続数の制限を持たせることが可能です。ユーザーのインフラストラクチャで構成/許可された数を越えるべきではありません。 

    ワーカー カウント機能は、Tomcat server.xml の maxThreads 属性と同等です。

    server.xml ファイルを調整するには:

    1. Virtualize を起動し、少なくとも 1 つのレスポンダーが作成されていることを確認します。
    2. <INSTALL>/plugins/com.parasoft.ptest.libs.web_<VERSION>/root/tomcat/conf/server.xml を変更します。
    高い数の同時仮想ユーザーを使用するとき (つまり負荷テスト中など)、通常はこれらの値を増やすことでより良いパフォーマンスを期待できます。


  6. グローバル キュー マネージャーを使用している場合、[ローカル設定] エリアで接続の詳細情報を指定します。以下のいずれかのモードを選択できます。
    • デフォルトモード: 接続の詳細情報 (たとえばホスト、ポート、チャネルなど) を手動で入力できます。
    • CCDT モード: 接続の詳細情報が記述されたクライアント チャネル定義 (CCDT) ファイルを指定できます。

デフォルトモードを使用している場合、以下のフィールドを設定します。




オプション説明
ホストIBM MQ が実行中のホスト名を指定します。
ポートIBM MQ が実行中のポートを指定します。
チャネルサーバー定義チャネルの名前を指定します。
キュー マネージャーキュー マネージャーの名前を指定します。
ユーザー名/パスワード必要な場合、入力します。

CCDT モードを使用している場合、以下のフィールドを設定します。

ローカルサーバーの場合:
 



リモートサーバーの場合:



オプション説明
CCDT ファイル

CCDT ファイル (拡張子 .tab) の場所を指定します。 

リモート サーバーでプロキシがデプロイされる場合、テキスト フィールドを使って、サーバー ツリーの [Workspace files] ノードに表示されるときと同じように、CCDT ファイルへの相対パスを指定します。

ローカル サーバーでプロキシがデプロイされる場合、[ファイル システム] または [ワークスペース] ボタンを使ってファイルの場所を指定できます。現在ローカル サーバーでデプロイされているが後でリモート サーバーでデプロイするプロキシを設定する場合、リモート サーバーにプロキシをデプロイする前に、そのリモート サーバーに CCDT ファイルをデプロイする必要があります。詳細については「リモート サーバーとローカル マシン間でのファイル転送」を参照してください。

キューマネージャーキュー マネージャーの名前を指定します。
ユーザー名/パスワード必要な場合、入力します。

MQ CCSID の設定

多くの場合、Virtualize が MQ キュー マネージャーの接続に使用するデフォルトの CCSID で問題ありません。しかし、別の CCSID を使用するよう MQ キュー マネージャーが設定されている場合、CCSID がキュー マネージャーによってサポートされていないという通知を受け取るでしょう。

MQ キュー マネージャーの接続に使用するデフォルトの CCSID を変更するには、JVM 引数で次のシステム プロパティを設定します。

parasoft.mq.environment.ccsid=<CCSID>

設定する CCSID は、キュー マネージャーの CCSID および JVM がサポートする文字セットによって異なります。

その他の設定 」も参照してください。

グローバル キュー マネージャーの使用

特定の Virtualize サーバー全体に適用されるグローバル キュー マネージャーの設定は、サーバー レベルで定義し、ここで参照することができます。  詳細については「 [接続] タブ」を参照してください。グローバル キュー マネージャーを使用するには、適切な [キュー] ボックスから選択します。MQ サーバーは、hostname: queue manager name



の命名規則を使用してリストされます。定義済みのグローバル キュー マネージャーの詳細を確認するには、[設定の表示] をクリックします。 

キューの構成についてのヒント

さまざまな状況で記録を設定するためのヒントについては、「トラフィックの記録におけるキューの設定」を参照してください。

  • No labels