This topic explains how to virtualize traffic that is captured in traffic logs.
You can virtualize application behavior captured in traffic logs, including:
Virtualization is achieved by using a wizard to create and deploy Message Responders within a virtual asset.
Virtualize supports the following traffic log formats (the file extension does not matter).
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.
Virtualize supports the creation of .pvas from JMS and MQ traffic files produced by Virtualize message proxies and the traffic recording wizard.
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.
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]
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:
Virtualize provides two options for generating Message Responders from traffic logs:
To understand the difference, consider the following example from a simple HTTP traffic file with 9 messages, including 3 messages for the getItemByTitle operation.
With "generate parameterized messages," Virtualize configures the Message Responder’s getItemByTitle responses as follows.
Additionally, it creates the following editable and extensible Data Repository.
With "generate fixed messages," Virtualize configures the Message Responder’s getItemByTitle responses as follows.
Video Tutorial: Creating Virtual Assets from Sample Request/Response Pairs
In this video you'll learn how to create a virtual asset from a sample piece of XML.