このセクションでは、テスト生成のために HTTP、JMS、MQ トラフィックを記録する方法を説明します。

このセクションの内容:

記録の概要

Parasoft Virtualize からの記録

Parasoft Virtualize が (CTP のシン クライアント インターフェイスから) 生成したトラフィック ファイルは、仮想アセットの作成だけでなく、テストの作成にも使用できます。

SOAtest のプロキシ トラフィック記録機能

Parasoft Virtualize がない場合、SOAtest のプロキシ トラフィック記録機能を使用し、アプリケーションを実行しながらサービスの HTTP、JMS、MQ トラフィックをモニターしてキャプチャできます。  これらのプロキシは、複数のエンドポイントを通過するトラフィックを同時にキャプチャできます。

アプリケーションの実行中、レコーディング プロキシが指定のトランスポートでトラフィックをモニターします。SOAtest はトラフィック リクエストおよびレスポンスをモニターし、適切なリクエスト/レスポンスのペアを記録したトラフィック ファイルを作成します。このトラフィックを使用して、、あらかじめ設定されたテスト クライアント ツールでキャプチャされた振る舞いを表現するテスト スイートを生成できます。

JMS、MQ、HTTP、HTTPS (SSL)、ベーシック、ダイジェスト および Kerberos 認証がサポートされています。NTLM はサポートされていません。

HTTP チャンキングおよび continue ヘッダーはサポートされていません。

この方法でトラフィック ファイルからテストを記録して生成するには、大きく分けて次の 2 つの手順を実行します。

1. トラフィックをファイルにキャプチャします。接続方法とモニター対象を指定します。モニターを有効化すると、SOAtest はキャプチャされたリクエストおよびレスポンスからトラフィック ファイルを作成します。
   • 詳細については以下を参照してください。
2. トラフィック ファイルからテストを作成します。
   • 詳細については「トラフィックからの「パラメータライズされたメッセージ」テスト クライアントの作成」および「トラフィックからの「固定メッセージ」テスト クライアントの作成」を参照してください。

SOAtest でのトラフィックの記録

1 つ以上のエンドポイントを通過するトラフィックをキャプチャするには、次の操作を行います。

1. [ファイル] メニューの [新規] > [その他] > [SOAtest] > [トラフィック] > [トラフィックの記録]をクリックします。
2. トラフィックを記録するエンドポイントごとに次の操作を行います。
   1. [トラフィックの記録におけるプロキシの設定] ダイアログで [追加] をクリックします。
      
      
      
      ウィザードが開きます。既に構成済みの接続があれば、その内容があらかじめ設定されています。
   2. [プロキシ タイプ] でトランスポート (HTTP、JMS、MQ) を選択します。
   3. 選択したトランスポートのプロキシ設定を完了します。詳細については、「グループ化条件のカスタマイズ」、「JMS の記録の構成」、または「MQ の構成」を参照してください。
   4. [トラフィック ファイル] フィールドで、このトラフィックのキャプチャで作成されるトラフィック ファイルの保存場所を指定します。後でこのトラフィック ファイルを使用して、キャプチャされたトラフィックを表すテストを生成できます。
   5. トラフィック ファイルにどのようにトラフィック データを記録するかを指定します。
      • [新規セッション データの追加] は、既存のトラフィック ファイル ([トラフィック ファイル] フィールドで指定されたファイル) に、新規トラフィック データを追加します。指定したファイルが存在しない場合、新しいファイルが作成されます。
      • [セッション データの上書き] は、既存のトラフィック ファイル ([トラフィック ファイル] フィールドで指定されたファイル) にトラフィック データを上書きします。指定したファイルが存在しない場合、新しいファイルが作成されます。
3. [OK] をクリックします。
   
   
   
   
4. メインのウィザードの画面で [次へ] をクリックします。
5. ウィザードの指定された場所で、テスト対象アプリケーションのホストとポートを設定します。
   
   
   
   
6. テスト対象のアプリケーションから、記録するトラフィックを生成します。
7. [終了] をクリックします。

トラフィックがキャプチャされたら、ビューを切り替えて各エンドポイントのリクエストおよびレスポンスを参照できます。

トラフィックがキャプチャされたら、以下の 2 つの方法でテストを生成できます。

• トラフィックからの「パラメータライズされたメッセージ」テスト クライアントの作成
• トラフィックからの「固定メッセージ」テスト クライアントの作成

HTTP の記録の構成

このセクションでは、HTTP トランスポートでメッセージを送受信する、プロキシのトラフィック記録機能を構成する方法を説明します。

HTTP、HTTPS (SSL)、ベーシック、ダイジェスト および Kerberos 認証がサポートされています。NTLM はサポートされていません。

プロキシのトラフィック記録機能のための HTTP 設定

プロキシのトラフィック記録機能ウィザードで、次のように HTTP 設定を指定します。

1. [プロキシ （クライアント） とターゲット アプリケーション （サーバー） 接続設定] ダイアログの [プロキシ タイプ] で [HTTP] を選択します。
   
   
   
   
2. 適切に HTTP 設定を行います。
   • サーバーサイド SSL を使用する場合、[サーバー サイド SSL の有効] をオンにします。
   • 双方向 SSL を使用する場合、[クライアント サイド SSL の有効化] をオンにし、[証明書] および [秘密鍵] の設定を行います。  クライアント サイド SSL を有効化すると、デフォルトでサーバー サイド SSL も有効になります。

サーバーサイド SSL のセットアップ

SSL の性質上、SOAtest の HTTP プロキシのトラフィック記録機能は、それ自身の証明書認証局によって署名された動的サーバー証明書を生成します。  この動的サーバー証明書を受け入れるため、HTTPS 上でリクエストを生成するクライアントは、すべての証明書を受け入れる必要があります。また、SOAtest はサービスが提示する証明書を信頼するよう構成されていなければなりません。そのためには、次の操作を行います。

1. SOtest の [サーバー証明書] 設定で [すべての証明書を信頼] が有効化されている ([Parasoft] メニューの [設定] > [Parasoft] > [セキュリティ]) か、SOAtest の cacerts ファイル (詳細については「HTTPS でデプロイされたサービスの使用」を参照) にサービスのサーバー証明書が適切に追加されていることを確認します。

双方向 SSL のセットアップ

SSL の性質上、SOAtest の HTTP プロキシのトラフィック記録機能は、それ自身の証明書認証局によって署名された動的サーバー証明書を生成します。  この動的サーバー証明書を受け入れるため、HTTPS 上でリクエストを生成するクライアントは、すべての証明書を受け入れる必要があります。また、SOAtest はサービスが提示する証明書を信頼し、適切なクライアント証明書を送信するよう構成されていなければなりません。そのためには、次の操作を行います。

1. SOtest の [サーバー証明書] 設定で [すべての証明書を信頼] が有効化されている ([Parasoft] メニューの [設定] > [Parasoft] > [セキュリティ]) か、SOAtest の cacerts ファイル (詳細については「HTTPS でデプロイされたサービスの使用」を参照) にサービスのサーバー証明書が適切に追加されていることを確認します。
2. クライアント証明書キーストア ファイル (およびクライアント証明書および秘密鍵が別のキーストアに格納されている場合は、秘密鍵のキーストア ファイルも) と適切なキーストア パスワード、キーストア タイプの情報、秘密鍵 パスワード、および証明書/秘密鍵で使用するエイリアス名があることを確認します。

トラフィックのキャプチャ

サーバーサイド SSL または双方向 SSL を使用するサービスの HTTPS トラフィックをキャプチャしたトラフィック ファイルを生成するには、前述の「トラフィックのキャプチャ」の説明に従ってウィザードを実行します。

HTTP ウィザードのページで、SSL オプションを適切に有効化します。

• サーバーサイド SSL を使用する場合、[サーバー サイド SSL の有効] をオンにします。
  双方向 SSL を使用する場合、[クライアント サイド SSL の有効化] をオンにし、[証明書] および [秘密鍵] の設定を行います。クライアント サイド SSL を有効化すると、デフォルトでサーバー サイド SSL も有効になります。
  
  

JMS の記録の構成

このセクションでは、JMS トランスポートでメッセージを送受信する、プロキシのトラフィック記録機能を構成する方法を説明します。

このセクションの内容:

• JMS 前提条件
• JMS 設定の指定

JMS 前提条件

JNDI

「JMS の前提条件」を参照してください。

キューの割り当て

トラフィックがキューを介して送受信される場合、クライアント接続先キューにリクエストを送信するクライアント アプリケーションがあり、キューからメッセージを受信するサーバー アプリケーションがあり、別の (リプライ) メッセージをクライアントが受信するための 2 つ目のキューに送信すると仮定されます。

このようなシナリオを考慮し、Parasoft SOAtest はクライアントとサーバー間の「仲介者」(プロキシとも呼ばれます) として動作します。このような仲介を容易にするために、メッセージ プロバイダー上に 2 つのキューがさらに必要になります。SOAtest のプロキシは、クライアントがメッセージを送信したキューからメッセージを取得し、メッセージのコンテンツを記録して (記録が有効化されている場合)、サーバーが受信するキューにメッセージを put します。同様に、クライアントがメッセージを取得するためのキューにサーバーがメッセージを送信すると、メッセージを記録して (記録が有効化されている場合)、クライアントが返信レスポンスを期待しているキューにメッセージを戻します。

結果として、2 つの追加のキューと、以下のどちらかの操作が必要になります。

• クライアント アプリケーションの構成を変更し、2 つの新しいキュー (およびそれらのキューに対応するよう構成されたプロキシ接続) を使用して通信する。
• サーバー アプリケーションの構成を変更し、2 つの新しいキューを使用する。

クライアントまたはサーバーのどちらかだけを変更する必要があります。

JMS 設定の指定

JMS を設定するには、次の操作を行います。

1. [プロキシ （クライアント） とターゲット アプリケーション （サーバー） 接続設定] ダイアログの [プロキシ タイプ] で [JMS] を選択します。
   
   
   
   

2. JMS のキューまたはトピックのどちらを使用するか、プロバイダー URL、初期コンテキスト、および接続ファクトリを指定します (関連する jar ファイルを必ず SOAtest のクラスパスに追加してください)。また、その他の初期コンテキスト JNDI プロパティ、認証情報、モニターしてトラフィックを収集するキュー/トピックを指定します。
   
   

   レスポンスに JMSReplyTo を使用する

   このオプションは、メッセージの JMSReplyToQueueName ヘッダーを使用してプロキシがレスポンスを送信する宛先を決定するかどうかを指定します。[レスポンスに JMSReplyTo を使用する] オプションがオンの場合、受信リクエストの値を使用してレスポンスの送信先を決定します。  このオプションがオフの場合、UI で指定されたキューにレスポンスが送信され、JMS メッセージ ヘッダーの値は無視されます。

   
   

   • キューを使用する場合: SOAtest は、クライアントの接続先キューに送信されたメッセージを取得し、サーバーがそれらのメッセージを処理できるよう、サーバーの Reply to キューにフォワードします。サーバーの接続先キューは、サーバーが (リクエスト メッセージを処理した後に) レスポンス メッセージを送信するキューです。SOAtest はこれらのメッセージを取得し、クライアントの Reply to キューにフォワードします。詳細については「記録のためのキューの構成 」を参照してください。
     
     
     
     
   • トピックを使用する場合: SOAtest はクライアントのサブスクライブ トピックで受信リクエストをモニターし、サーバーのパブリッシュ トピックで送信リクエストをモニターします。

MQ の構成

このセクションでは、MQ トランスポートでメッセージを送受信する、プロキシのトラフィック記録機能を構成する方法を説明します。

このセクションの内容:

• MQ 前提条件
• MQ 設定の指定

MQ 前提条件

Jar ファイル

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

キューの割り当て

トラフィックがキューを介して送受信される場合、クライアント接続先キューにリクエストを送信するクライアント アプリケーションがあり、キューからメッセージを受信するサーバー アプリケーションがあり、別の (リプライ) メッセージをクライアントが受信するための 2 つ目のキューに送信すると仮定されます。

このようなシナリオを考慮し、Parasoft SOAtest はクライアントとサーバー間の「仲介者」(プロキシとも呼ばれます) として動作します。このような仲介を容易にするために、メッセージ プロバイダー上に 2 つのキューがさらに必要になります。SOAtest のプロキシは、クライアントがメッセージを送信したキューからメッセージを取得し、メッセージのコンテンツを記録して (記録が有効化されている場合)、サーバーが受信するキューにメッセージを put します。同様に、クライアントがメッセージを取得するためのキューにサーバーがメッセージを送信すると、メッセージを記録して (記録が有効化されている場合)、クライアントが返信レスポンスを期待しているキューにメッセージを戻します。

結果として、2 つの追加のキューと、以下のどちらかの操作が必要になります。

• クライアント アプリケーションの構成を変更し、2 つの新しいキュー (およびそれらのキューに対応するよう構成されたプロキシ接続) を使用して通信する。
• サーバー アプリケーションの構成を変更し、2 つの新しいキューを使用する。

クライアントまたはサーバーのどちらかだけを変更する必要があります。

MQ 設定の指定

MQ を設定するには、次の操作を行います。

1. [プロキシ （クライアント） とターゲット アプリケーション （サーバー） 接続設定] ダイアログの [プロキシ タイプ] で [MQ] を選択します。
   
   
   
   
2. 表示されるフィールドで MQ 設定を指定します。構成の詳細については下記を参照してください。
   
   

記録のためのキューの構成

このセクションでは、WebSphere MQ およびポイントツーポイントのJMS を記録する (トピックではなくキューが使用される場合) ための構成方法について説明します。

概要

SOAtest が JMS の ポイントツーポイント メッセージングおよび WebSphere MQ を記録する際に使用する方法では、SOAtest がプロキシ (別の言葉で言えば媒介/仲介者) の役割を果たす必要があります。

接続先キューである REQUEST_QUEUE にリクエストを送信/put/push し、RESPONSE_QUEUE からレスポンス/リプライを受信/取得/pull するクライアント/コンシューマー アプリケーション (クライアントと呼びます) があるとします。また、接続先キューである REQUEST_QUEUE からリクエストを受信/取得/pull し、RESPONSE_QUEUE にレスポンス/リプライを送信/put/push するサーバー/プロバイダー アプリケーション (サーバーと呼びます) があるとします。

トラフィックの記録に際しては、2 つの構成オプションが考えられます。1 つは、クライアント アプリケーション側が使用するキューを変更することです。もう 1 つは、サーバーが使用するキューを変更することです。

最良のアプローチは、どちら側にアクセスして変更できるかによります。どちらの場合も、記録プロセスを実現するには、2 つのキューを追加する必要があります。ここでは、新しいキューを PROXY_REQUEST_QUEUE および PROXY_RESPONSE_QUEUE とします。

シナリオ 1: クライアント アプリケーションの変更

このシナリオでは、クライアント アプリケーションのデプロイメント構成にアクセスして、使用するキューを変更できなければなりません。クライアントがサーバーとの通信に使用するキューを次のように変更します。

• PROXY_REQUEST_QUEUE にメッセージを put/送信/push する
• PROXY_RESPONSE_QUEUE からメッセージを受信/取得/pull する

この場合、サーバーのキューを変更する必要はありません。

MQ または JMS 記録ウィザードで、次のようにキュー名を指定します。

シナリオ 2: サーバー アプリケーションの変更

このシナリオでは、サーバー アプリケーションのデプロイメント構成にアクセスして、使用するキューを変更できなければなりません。サーバーがクライアントとの通信に使用するキューを次のように変更します。

• PROXY_REQUEST_QUEUE からメッセージを受信/取得/pull する
• PROXY_RESPONSE_QUEUE にメッセージを put/送信/push する

この場合、クライアントのキューを変更する必要はありません。

MQ または JMS 記録ウィザードで、次のようにキュー名を指定します。