If you can't, or just don't want to, deploy message proxies (the recommended approach; discussed in Recording Traffic from Message Proxies), you can record HTTP, JMS, and  MQ traffic "on the fly" with the recording proxy. Like message proxies, these proxies can concurrently capture live HTTP, JMS, and MQ traffic that passes through multiple endpoints. 

The recording proxy can monitor traffic over the specified transport(s) 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 (returning virtualized responses that correlate to the incoming request messages based on the traffic captured).

JMS, MQ, HTTP, HTTPS (SSL), Basic, Digest, and Kerberos authentication are supported; NTLM is not.

HTTP chunking and continue headers are not supported.

There are three main steps involved in virtualizing this application behavior:

  1. Capturing traffic in a file. You tell Virtualize how to connect and what you want it to monitor. With monitoring enabled, Virtualize builds a traffic file from the captured requests and responses.
  2. Creating Message Responders from that traffic file.
  3. Verifying that those Message Responders were automatically deployed as a virtual asset.

Recording Traffic

To simultaneously capture live traffic across one or more endpoints:

  1. Open the Record Traffic wizard. You can access it in a number of ways:
  2. For each endpoint where you want to record traffic, do the following:
    1. In the Configure Proxies for Recording Traffic dialog, click Add. The wizard that opens will be pre-populated with any connections you have already configured.
    2. Under Proxy Type, select the desired transport (HTTP, JMS, MQ).
    3. Complete the proxy settings for the selected transport.
    4. In the Traffic file field, specify where you want to save the traffic file that will be created to capture this traffic. You can later use this traffic file to generate virtual assets that represent the live traffic captured.  When specifying the file name, you can use variables such as %d (for current date) and %t (for the current time).
    5. Specify how you want traffic data recorded in traffic files:
      • Append new session data adds new traffic data to an existing traffic file (the one specified in the Traffic file field). If the specified file does not already exist, a new file will be created.

      • Overwrite session data overwrites the traffic data in an existing traffic file (the one specified in the Traffic file field). If the specified file does not already exist, a new file will be created.

    6. Click OK.
  3. From the application under test, generate the traffic that you want to record.
  4. Click Finish.

When live traffic is being captured, you can switch between the available tabs to view the requests and responses at each endpoint. The following screenshots show traffic being concurrently captured at three different endpoints.

Virtualizing the Recorded Traffic

Once you have recorded traffic, you can create and deploy virtual assets as follows:

  1. Create Message Responders from the traffic files created—see Creating Message Responders from Traffic Files - Overview.
  2. Verifying that those Message Responders were automatically deployed as virtual assets—see Deploying Virtual Assets.

Configuring Recording Proxies for HTTP

This section explains how to configure recording proxies for HTTP. This is different than the HTTP configuration for deployable message proxies (which is discussed in HTTP Reverse Proxy Configuration). It covers:

Note that HTTP, HTTPS (SSL), Basic, Digest, and Kerberos authentication are supported; NTLM is not.

Specifying HTTP Settings for the Recording Proxy

In the recording proxy wizard (as opposed to deployed message proxies), you specify your HTTP settings as follows:

  1. In the Proxy Connection Settings dialog, choose HTTP for the Proxy Type.
  2. Complete the appropriate HTTP settings.

Server-Side SSL Setup

Due to the nature of SSL, Virtualize's proxy for HTTP recording generates a dynamic server certificate signed by its own certificate authority. In order to accept this dynamic server certificate, the client generating the requests over HTTPS will need to be set up to trust all certificates. To do this:

  1. Ensure that the Server Certificate setting for Virtualize is set with Trust all certificates enabled (in Parasoft > Preferences > Security) or that the service's Server Certificate is properly added to the Virtualize cacerts file (see Configuring for Services Deployed Over HTTPS for more details).

Two-Way SSL Setup

Due to the nature of SSL, Virtualize's proxy for HTTP recording generates a dynamic server certificate signed by its own certificate authority. In order to accept this dynamic server certificate, the client generating the requests over HTTPS will need to be set up to trust all certificates. To do this:

  1. Ensure that the Server Certificate setting for Virtualize is set with Trust all certificates enabled (in Parasoft > Preferences > Security) or that the service's Server Certificate is properly added to the Virtualize cacerts file (see Configuring for Services Deployed Over HTTPS for more details).
  2. Make sure you have the client certificate keystore file (and if the client certificate and private key are stored in different keystores, the private key keystore file) as well as relevant keystore passwords, keystore type information, private key password, and the name of the alias being used for the certificate/private key.

Capturing the Traffic

To generate a traffic file that captures HTTPS traffic from a service that uses server-side or two-way SSL, complete the wizard as described in Capturing the Traffic (above).

In the HTTP wizard page, be sure to enable the appropriate SSL option:

Configuring the AUT

To configure your application under test to access the virtual asset that will represent this recorded traffic: