This topic explains how to record HTTP, JMS, and IBM MQ traffic for test generation purposes.

Sections include:

Recording Overview

Recording from Parasoft Virtualize

The traffic files generated by Parasoft Virtualize (through the thin client interface of CTP) can be used for test creation as well as virtual asset creation.

About SOAtest’s Recording Proxies

If you do not have Parasoft Virtualize, you can use SOAtest’s recording proxies to monitor and capture live HTTP, JMS, or IBM MQ traffic from a service as an application is exercised. These proxies can concurrently capture traffic that passes through multiple endpoints.

The recording proxy monitors traffic over the specified transport(s) as an application is exercised. SOAtest "listens" to traffic requests and responses, then builds a traffic file of legitimate request/response pairs. This traffic is then used to generate a test suite that represents the captured behavior in preconfigured test client tools.

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

HTTP chunking and continue headers are not supported.

There are two main steps involved in recording and generating tests from traffic using this approach:

  1. Capturing traffic in a file. You tell SOAtest how to connect and what you want it to monitor. With monitoring enabled, SOAtest builds a traffic file from the captured requests and responses.
  2. Creating tests from that traffic file.

Recording Traffic with SOAtest

To capture live traffic across one or more endpoints:

  1. Go to File > New > Other > SOAtest > Traffic > Record Traffic.
  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, IBM MQ).
    3. Complete the proxy settings for the selected transport. See Customizing Grouping Criteria, JMS Recording Configuration, or MQ Recording Configuration for details.
    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 tests that represent the live traffic captured.
    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.
  3. Click OK.
  4. In the main wizard panel, click Next.
  5. Set the host and port of the application under test to the location specified in the wizard.
  6. From the application under test, generate the traffic that you want to record.
  7. Click Finish.

When live traffic is being captured, you can switch between the available tabs to view the requests and responses at each endpoint.

Once traffic is captured, you have two options for generating tests:

HTTP Recording Configuration

This section explains how to configure recording proxies that send and receive messages over the HTTP transport.

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, specify your HTTP settings as follows:

  1. In the Proxy (Client) and Target Application (Server) Connection Settings dialog, choose HTTP for Proxy Type.
  2. Complete the appropriate HTTP settings.

Server-Side SSL Setup

Due to the nature of SSL, SOAtest’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. In addition, SOAtest must be configured to trust the certificate presented by the service. To do this:

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

Two-Way SSL Setup

Due to the nature of SSL, SOAtest’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. In addition, SOAtest must be configured to trust the certificate presented by the service as well as to send the appropriate client certificate. To do this:

  1. Ensure that the Server Certificate setting for SOAtest is set with Trust all certificates enabled (in Parasoft > Preferences > Parasoft > Security) or that the service's Server Certificate is properly added to the SOAtest 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:

JMS Recording Configuration

This section explains how to configure recording proxies that send and receive messages over the JMS transport.

Sections include:

JMS Prerequisites

JNDI

See JMS Prerequisites.

Queue Allocation

When traffic is being exchanged over queues, the assumption is that there is a client application that sends a request to a client destination queue and a server application that receives that message from the queue, then sends another (reply) message onto a second queue for the client to receive.

With that scenario in mind, Parasoft SOAtest uses a "man-in-the-middle" (proxy) approach between the client and the server, so two extra queues are needed on the messaging provider in order to facilitate that mediation. SOAtest proxies will receive messages from where the client places them, record the message contents (if recording is enabled), then put the message on the queue where the server will receive it from. Similarly, the server sends the message to a queue where the proxy picks it up, records it (if recording is enabled), and places it back on the queue where the client is expecting the reply response.

As a result, it is necessary to allocate two additional queues and either:

Only one of the two application queues needs to be modified.

Specifying JMS Settings

Specify your JMS settings as follows:

  1. In the Proxy (Client) and Target Application (Server) Connection Settings dialog, choose JMS for Proxy Type.

  2. Specify whether you’re using JMS Queues or Topics, the Provider URL, Initial context, and connection factory (be sure to add the related jars to the SOAtest classpath), as well as any additional initial context JNDI properties, authentication, and the queues/topics you want to monitor to collect traffic.

    This option specifies whether to use the message's JMSReplyToQueueName header to determine where the proxy sends the response. If Use JMSReplyToQueueName for Response is enabled, values from the incoming request will be used to determine where to send the response.  If it is not enabled, the response will be sent to the queue specified in the UI; the values in the JMS message header will be ignored.


MQ Recording Configuration

This section explains how to configure recording proxies that send and receive messages over the IBM MQ transport.

Sections include:

Prerequisites

Jar Files

See Adding Necessary Jar Files to the Classpath.

Queue Allocation

When traffic is being exchanged over queues, the assumption is that there is a client application that puts a request to a client destination queue and a server application that gets that message from the queue then puts another (reply) message onto a second queue for the client to get.

With that scenario in mind, Parasoft SOAtest uses a "man-in-the-middle" (proxy) approach between the client and the server, so two extra queues are needed on the messaging provider in order to facilitate that mediation. SOAtest proxies will receive messages from where the client places them, record the message contents (if recording is enabled), then put the message on the queue where the server will receive it from. Similarly, the server sends the message to a queue where the proxy picks it up, records it (if recording is enabled), and places it back on the queue where the client is expecting the reply response.

As a result, it is necessary to allocate two additional queues and either:

Only one of the two application queues needs to be modified.

Specifying MQ Settings

Specify your IBM MQ settings as follows:

  1. In the Proxy (Client) and Target Application (Server) Connection Settings dialog, choose MQ for Proxy Type.
  2. Specify the IBM MQ settings in the available fields. See below for more configuration details.

This option specifies whether to use the message’s replyToQueueName header to determine where the proxy sends the response. It impacts responses to IBM MQ messages of type MQMT_REQUEST.

If Use replyToQueueName for Response is enabled, values from the incoming request will be used to determine where to send the response. If it is not enabled, the response will be sent to the queue specified in the UI. More specifically:

  • If Use replyToQueueName for Response is enabled and values for both MQMD.replyTo-QueueManagerName and MQMD.replyToQueueName have been specified, those values will determine both the queue manager and the queue name to send the response to.
  • If Use replyToQueueName for Response is enabled and either MQMD.replyToQueueM-anagerName or MQMD.replyToQueueName is missing from the request, the values specified in the UI will be used in place of the missing value.
  • If Use replyToQueueName for Response is disabled, the replyToQueueName and reply-ToQueueManagerName fields in the IBM MQ request message will be ignored. The UI settings will determine where the message is sent.


Configuring Queues for Recording

This section explains how to configure recording for IBM MQ and JMS point-to-point (when queues are used, not topics).

Overview

The method that Parasoft SOAtest uses for capturing/recording JMS point-to-point messaging and IBM MQ requires SOAtest to be a proxy or, in other words, an intermediary / man-in-the-middle.

Assume that there is a client/consumer application (we’ll call this "Client") that sends/puts/pushes a request message on destination queue REQUEST_QUEUE and receives/gets/pulls a response/reply from RESPONSE_QUEUE. Also assume there is a server/provider application (we’ll call this "Server") that receives/gets/pulls messages from REQUEST_QUEUE and sends/puts/pushes responses to RESPONSE_QUEUE.

There are two possible configuration scenarios for recording traffic. In one, you modify the queues that are used on the client application end. In the other, you modify the queues that are used on the server.

The best approach to use depends on your ability to access and modify each end. In both cases, you will need to create two extra queues in order to enable the recording process. Here, we’ll label them as PROXY_REQUEST_QUEUE and PROXY_RESPONSE_QUEUE.

If a publish and subscribe scheme is used (using Topics instead of queues), then you don’t need to introduce new topics into the system. That’s why only two destinations need to be provided in the wizard:

  • One for the requests, labeled in the wizard as the "Client Subscribe Topic."
  • One for the response, labeled in the wizard as the "Server Publish Topic."

Scenario 1: Modifying the Client Application

In this scenario, you need access to the client application deployment configuration in order to adjust the queues it uses. Modify the queues that the client uses to communicate with the server as follows:

The server does not need to have its queues changed in this case.

In the IBM MQ or JMS recording wizard, provide the queue names as follows:

Client Queues
Destination/Put QueuePROXY_REQUEST_QUEUE
Reply to/Get QueuePROXY_RESPONSE_QUEUE
Server Queue
Reply to/Get QueueREQUEST_QUEUE
Destination/Put QueueRESPONSE_QUEUE

Scenario 2: Modifying the Server Application

In this scenario, you need access to the server application deployment configuration in order to adjust the queues it uses. Modify the queues that the server uses to communicate with the client as follows:

The client does not need to have its queues changed in this case.

In the IBM MQ or JMS recording wizard, provide the queue names as follows:

Client Queues
Destination/Put QueueREQUEST_QUEUE
Reply to/Get QueueRESPONSE_QUEUE
Server Queue
Reply to/Get QueuePROXY_REQUEST_QUEUE
Destination/Put QueuePROXY_RESPONSE_QUEUE