このセクションでは、トラフィック ログにキャプチャされたトラフィックを仮想化する方法について説明します。

セクションの内容:

はじめに

Virtualize はトラフィック ログにキャプチャされたアプリケーションの振る舞いを仮想化できます。次のようなログが対象です。

• Virtualize メッセージ プロキシ、または (たとえば JMS、MQ、HTTP 用の) プロキシのトラフィック記録機能によって作成されたログ。
• その他のソースから作成されたログ。たとえば、
  • ネットワーク解析ツールを使用してネットワーク レベルでキャプチャされたメッセージ トレースやログ。
  • アプリケーションに自身のトラフィックを記録させることで得た HTTP ログ。

この仮想化は、ウィザードを使用して、仮想アセット内でメッセージ レスポンダーを作成およびデプロイすることで実現されます。

サポート対象のトラフィック ログ フォーマット

Virtualize は以下のトラフィック ログ フォーマットをサポートしています (ファイルの拡張子は問いません)。

HTTP トラフィック ログ

HTTP パーサー タイプの場合、 Virtualize は HTTP トラフィックを認識し、 POST、GET、および PUT メソッドでパースします。DELETE はサポート対象外です。Virtualize はログに各 HTTP ヘッダーと、それに続いてメッセージ ボディのコンテンツを期待します。

HTTP request 1 headers 
HTTP request 1 body 
HTTP response 1 headers 
HTTP response 1 body 
HTTP request 2 headers 
HTTP request 2 body 
HTTP response 2 headers 
HTTP response 2 body 
...

Virtualize はメッセージボディと次の HTTP ヘッダーの間に 2 行分の改行 (Windows または Unix) を期待します。

このフォーマットは、「Virtualize メッセージ プロキシ」、「トラフィックの記録ウィザード」、あるいは「HTTP ソケット接続を介して HTTP トラフィックが転送されるときにそのトラフィックを記録できるその他の HTTP トラフィック解析ツール」によってキャプチャされるものに似ています。チャンクされたトラフィックとともに記録された HTTP チャンクおよびトラフィック ファイルはサポート対象です。チャンクされたメッセージまたは continue ヘッダーを含む生の HTTP トラフィックはサポートの対象外です。 

値はエンコードまたはデコードできます。たとえば /some/url?q=harry+potter というパスでリクエストが来る場合、たとえ "q" URL パラメーター応答条件が 'harry potter' に設定されていても、/some/url?q=harry%20potter と同じであると相関されるべきです。エンコードされた値とデータソース応答条件を使用している場合、「[ データソース応答条件] タブ」の説明を参照してください。

Virtualize は、URL エンコードされた POST リクエストの形式で送信されたボディ コンテンツを、リクエスト ボディに入れるのではなく、URL パラメーターとして扱います。これにより、個々のパラメーターに基づいて応答条件を作成する柔軟性が高まります。

JMS および MQ のトラフィック ログ

Virtualize は、 Virtualize メッセージ プロキシおよびトラフィックの記録ウィザードによって作成された、JMS および MQ のトラフィック ファイルから .pva を作成できます。 

メッセージ形式

パラメータライズされたメッセージでは、トラフィック ファイルは Virtualize がサポートする任意のメッセージ形式 (EDI、JSON、固定長、およびユーザー定義のメッセージ形式など) を含めることができます。固定メッセージでは、XML と JSON だけがサポートされています。

リクエスト/ レスポンスのサンプルに基づいたトラフィック ファイルの作成

リクエスト/レスポンスのサンプルに基づいて仮想アセットを作成したい場合、リクエスト/レスポンスを 1 つのトラフィック ファイルに集約し、そのトラフィック ファイルから仮想アセットを作成することができます。

以下のサンプルは、そのようなトラフィック ファイルのフォーマットを示しています。

POST /SomePath HTTP/1.0
Content-Type: text/xml; charset=UTF-8
 
[Request 1 Message]
 
HTTP/1.1 200 OK
Content-Type: text/xml; charset=UTF-8
 
[Response 1 Message]

POST /SomePath HTTP/1.0
Content-Type: text/xml; charset=UTF-8
 
[Request 2 Message]
 
HTTP/1.1 200 OK
Content-Type: text/xml; charset=UTF-8
 
[Response 2 Message]

サイクルの深さの指定

同じ要素が自身の子要素として表れるサイクルがトラフィックに含まれている場合、Virtualize は最初のレベルでフォーム入力へのデータ設定を中止します。起動時に RepositorySchemaCreator.cycle.limit システム プロパティを指定すると、フォーム入力にデータを設定するサイクルの深さを指定できます。例:

-J-DRepositorySchemaCreator.cycle.limit=5

パラメータライズ vs 固定メッセージの使用

Virtualize はトラフィック ログからメッセージ レスポンダーを生成するために、 2 つのオプションを提供します。

• [パラメータライズされたメッセージを生成] は、Parasoft Data Repository の値で自動的にパラメータライズされたメッセージレスポンダーを作成します。Parasoft Data Repository は、このオプションを使用するときに自動的に作成されます。このオプションは、大規模で複雑なデータ ソースを処理するために設計された GUI を使用して、レスポンス メッセージの値を迅速に追加および変更できます。データの値は、メッセージ レスポンダーおよび .pva とは関係なく格納および処理されます。このプロセスについては「トラフィックからの「固定メッセージ」レスポンダーの作成」で説明しています。
• [固定メッセージの生成] は、複数レスポンスのフォーマットを介して各レスポンスをリテラルに指定するメッセージ レスポンダーを作成します。すべてのレスポンス メッセージ データはメッセージ レスポンダー内に格納され、処理されます。レスポンス メッセージの要素は、着信メッセージから抽出したデータでパラメータライズできます。このプロセスについては「トラフィックからの「固定メッセージ」レスポンダーの作成」で説明しています。

例

2 つの違いを理解するために、 1 つのシンプルな HTTP トラフィック ファイルから次の例を考察してみましょう。このファイルは、getItemByTitle 操作のための 3 つのメッセージを含む 9 つのメッセージから構成されています。 

メッセージのパラメータライズ

[パラメータライズされたメッセージを生成] の場合、 Virtualize はメッセージ レスポンダーのgetItemByTitle レスポンスを次のように構成します。

さらに、次のような編集可能かつ拡張可能な Data Repository が作成されます。

固定メッセージ

[固定メッセージの生成] の場合、 Virtualize はメッセージ レスポンダーの getItemByTitle レスポンスを次のように構成します。