Introduction

Virtualize can virtualize application behavior that is captured in traffic logs—including:

Logs produced by Virtualize message proxies or recording proxies (e.g., for JMS, MQ, HTTP).
Logs produced from other sources; for example:
- Message traces or logs captured at the network level using network sniffing tools.
- HTTP logs obtained by having your application log its traffic.

This "virtualization" is achieved by using a wizard to create and deploy Message Responders within a virtual asset.

Supported Traffic Log Formats

Virtualize supports the following traffic log formats (the file extension does not matter).

HTTP Traffic Logs

For the HTTP parser type, Virtualize can recognize and parse HTTP traffic with POST, GET, and PUT methods. DELETE is not supported. Virtualize expects the log to contain each HTTP header, followed with message body content:

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 also expects there to be two line endings (Windows or Unix) between a message body and the next HTTP header.

This format is similar to what would be captured by the Virtualize message proxy, recording wizard, or other HTTP traffic sniffing tools that can record HTTP traffic as it gets transmitted over the HTTP socket connection. HTTP chunking and traffic files that are recorded with chunked traffic are supported. However, raw HTTP traffic files that include chunked messages or "continue" headers are not supported.

Values can be encoded or decoded. For instance, if a request comes in at path /some/url?q=harry+potter, this should correlate the same as /some/url?q=harry%20potter, even if the "q" URL Parameter Correlation is set to 'harry potter'. If you are using encoded values and data source correlations, see the notes for Data Source Correlation Tab.

JMS and MQ Traffic Logs

Virtualize supports the creation of .pvas from JMS and MQ traffic files produced by Virtualize message proxies and the traffic recording wizard.

Message Formats

For parameterized messages, the traffic files can include any message format that Virtualize supports (including EDI, JSON, fixed length, and custom message formats). For fixed messages, only XML and JSON are supported.

Constructing a Traffic File Based on Sample Requests and Responses

If you want to create a virtual asset based on sample requests/responses, you can aggregate the requests/responses into a single traffic file, then create virtual assets from that traffic file.

The following sample shows the format for such a traffic file:

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]

Specifying Depth of Cycles

When traffic has cycles in which the same element is a child of itself, Virtualize stops populating form input at the first level. But you can set the RepositorySchemaCreator.cycle.limit system property on startup to specify how many cycles deep to populate the form input. For example:

-J-DRepositorySchemaCreator.cycle.limit=5

Using Parameterized vs. Fixed Messages

Virtualize provides two options for generating Message Responders from traffic logs:

Generate parameterized messages creates Message Responders that are automatically parameterized with values from a Parasoft Data Repository (which is also automatically created when you use this option). This option allows you to rapidly add and modify response message values using a graphical interface designed for manipulating large, complex data sources. Data values are stored and manipulated independently of the Message Responder and .pva. This process is described in Creating Parameterized Message Responders from Traffic.
Generate fixed messages creates Message Responders that specify each response literally via Multiple Response format. All response message data is stored and manipulated within the Message Responder. Response message elements can be parameterized with data extracted from incoming messages. This process is described in Creating Fixed Message Responders from Traffic.

Example

To understand the difference, consider the following example from a simple HTTP traffic file with 9 messages, including 3 messages for the getItemByTitle operation.