Recording Traffic in Parasoft Virtualize using Message Proxies

Virtualize can record live behavior of dependent system components—database queries and responses or traffic over HTTP, JMS, or MQ—then represent that behavior as a Virtual Asset. Once the Virtual Asset is created and deployed, it can emulate the captured behavior—enabling you to cut the dependencies on system components that are difficult to access.

There are two ways to record live HTTP, JMS, or MQ traffic, using message proxies or using recording wizard. Here we will discuss message proxy approach as direct recording is not available in community edition.

Recording from a Message Proxy

In previous lesson we discussed about setting recording mode in message proxy. When message proxy is in record mode it can monitor the traffic over the specified transport as an application is exercised. Virtualize “listens” to traffic requests and responses, then builds a traffic file of legitimate request/response pairs. This traffic is then used to generate and deploy a virtual asset that virtualizes the captured behavior.

Here are the steps:

  1. Enable the proxy and set it in recording mode. Parasoft Virtualize will monitor the traffic and will post all traffic (requests and reponses) in a file with the name defined in the message proxy.
  2. Once recording is done, stop the recording by using right click on message proxy. You can find this file at recorded traffic folder under your workspace/virtual Assets. Note: You will not see this file until you will stop the recording. You can configure the proxy either in append new session data mode or just get the recording file reset.
  3. Using traffic file we can create either Fixed Messages or Parameterized Messages. In case we want to get same response for all requests then used fixed message option else to parameterized the repose choose second option.

Virtualizing the Recorded Traffic

Creating “Fixed Message” Virtual Assets from Traffic

To use this prerequisites are:

  • HTTP headers for the request and responses must contain a Content-Type header with xml or json content types.
  • Message contents must be well-formed; otherwise, auto-creation of Message Responders from the traffic might fail. You can monitor the console to see if process hits any error.
Step 1:

In order to create your asset, right click the Virtual Assets project folder and select Add New > Virtual Asset. After naming your asset and clicking next, choose the Traffic > Generate Fixed Messages. The next screen will prompt you to select a traffic file to be used when creating your asset.

Step 2:

After selecting your Traffic file, the next option is to choose grouping logic. It will automatically detect the message format used by your traffic for both the requests and responses. Usually, you will want to have the messages grouped based on the operation/type and have the grouping criteria be request body. You can find group option details at bottom of the page.

Step 3:

Use the available controls to specify which parameter values should be used to determine the response messages of the virtual asset. You do not need to configure these selections; you can leave the default automatic selection enabled, if desired.

Step 4:

(Optional) If you want to set up dynamic messages (using data extracted from the incoming message to parameterize the response message or header elements), complete the Configure Dynamic Messages page for each operation that you want to parameterize. Upon completion of each wizard page, click Next to advance to the page for the next operation.

Virtualize will then create Message Responders and deploy them to the local Virtualize server.

Creating “Parameterized Message” Virtual Assets from Traffic

Step 1:

In order to create your asset, right click the Virtual Assets project folder and select Add New > Virtual Asset. After naming your asset and clicking next, choose the Traffic > Generate Parameterized Messages. The next screen will prompt you to select a traffic file to be used when creating your asset.

Step 2:

After selecting your Traffic file, the next step is to connect to a Data Repository. Virtualize comes packaged with an Embedded Data Repository that you can connect to, but it is recommended to use the MongoDB Data Repository that comes with your Virtualize installation.

When you have the repository up and running, you can check your configuration and connection to it here. Specify the name of the server as well as the name for the repository you would like to create, as well as the username and password for the server. Once all of your settings have been validated, click next.

Step 3:

On the message grouping screen, it will automatically detect the message format used by your traffic for both the requests and responses. Usually, you will want to have the messages grouped based on the operation/type and have the grouping criteria be request body.

Step 4:

The next screen in this wizard is the message grouping review. If there are multiple requests/responses for the same call, there will be the option of selecting autoconfig here to go with some default values selected by Virtualize. If your service correlates on one specific element in a response, though, it is recommended to uncheck autoconfig.

The next screen will allow you to set correlations for the elements in different requests. To view these correlations, click on the request correlation tab at the top of the window. If you had the autoconfig option available, you will see all of the values the option would have chosen for correlation here. If not, all boxes on this tab will be blank. To set a correlation, click the “new” button on the right of whichever set of info you would like to correlate on.

Step 5:

Once you have selected all of the different correlation options, you will be able to set your data reuse options in the data repository. There are several options here that may need some explanation:

Data Set Import
  • Update: Keep all old and new data, and if there is any overlap in the data, overwrite the old data with the new.
  • Replace: Discard all previous data and keep new data.
  • Merge: Similar to update, but if there is overlap, discard the new parts of the data.
  • Overwrite: Overwrite any overlap in the old data from new data, then discard the rest of the new dataset.
Record Import
  • Reuse: Keep all old records, discard all new.
  • Update: Keep all records.

If you have any questions about these, refer to the Venn Diagrams that describe the repository’s behavior. It is usually recommended to use Update – Update for the two values.

Step 6 (Optional):

You can then, if you so choose, create a template for many of the steps you just took. The template will save all of the different options that you chose for the different steps and apply those the next time you would like to create a pva from the same service from traffic or update the repository with more data.

Completing the Request Parameter Selection Wizard

The Request Parameter Selection wizard will present you with a step for each operation detected in the traffic file. At this step, Virtualize will generate a “name”-based XPath for each operation/group; this will be used to set the Responder Correlation for that operation. For example, if the element name under the SOAP Body is “SubmitOrder”, then the XPath expression set to the responder correlation section would look like local-name(/*/*[local-name(.)=”Body”]/*)=”id” Note that when the message is not XML, XPaths and parameter selections are applied to the converted XML version of the request message. For each group of messages belonging to the same operation, requests are mutually compared to determine the parameters that differ among the requests.

  • With the automatic option, Virtualize will analyze the differences in the request elements, then use the results of this analysis to generate XPath expressions for the multiple responses available within that operation/group. The goal is to automatically generate a response for each distinct request element. If the traffic is a SOAP Envelope, then structural differences are allowed as long as the messages share the same operation element (this is the first element under the SOAP Body). If the traffic is generic XML, then structural differences are allowed as long as the messages have the same root node.
  • If you manually select the request parameters, then you can select one or more request parameters to use for generating these multiple responses XPaths.
  • We recommend the manual option if you want control over how the correlations are generated. The automatic option is intended for quick generation/configuration in simple cases.

Message Grouping Options

This is again a great feature provided by Parasoft Virtualize which allow us to choose an option on which basis similar requests can be grouped while creating the virtual assets from traffic. Available options are:

None: No grouping. A responder is generated for each response messages in the traffic file. Use this option if you want every request/response pair in separate Message Responders.

Based on operation/type: Group messages based on the operation or message type. This is useful for service traffic that contains messages that are distinctly identifiable either by operation or by the format’s message type (i.e., the name of the element under the SOAP Body, the name of the root element in plain XML messages, or the message type of a specified message format). A responder is generated for each operation/type discovered within the traffic file.

 Based on similar requests: Group messages based on request message structure. This tells Virtualize to analyze the request message structures and group the request/response into responders so that each responder will contain responses that correlate with requests that have a similar structure. Messages are considered “similar” when they have an identical DOM tree model, even if they have different values. This option is used to optimize and simplify the rules for correlating requests to responses within each Message Responder.

Based on similar responses: Group messages based on response message structure. This tells Virtualize to analyze the response message structures and group the request/response pairs into responders so that each responder will contain responses that have a similar structure. Messages are considered “similar” when they have an identical DOM tree model, even if they have different values. This option is used in order to generate Message Responders that are optimized for data source parameterization. Since all responses within a Message Responder are similar, a data source can be generated more easily for each responder to create data-source-driven assets.

Leave a Reply

Your email address will not be published. Required fields are marked *