This topic explains the general procedure for creating message proxies.

In this section:

Adding Proxies

Right-click on a server in the 

Virtualize or SOAtest Server view

and choose Add Message Proxy.
 A new Proxy node will be added under the Message Proxies folder. The added proxy will initially be set to a disabled state. The proxy will need to be configured before it can be used.

To delete a proxy or folder, right-click on the node and choose Delete.

If you delete a folder that contains proxies, the proxies will be un-deployed and removed from the server.

You can also create proxies directly in the Message Proxies folder or in a subfolder by right-clicking a node in the server view and choosing Add Message Proxy.

Organizing Message Proxies

You can create subfolders in the Message Proxies folder on the server and organize its contents. 

Creating a New Folder

  1. Right-click on a node and choosing New Folder.
  2. Specify a name for the folder when prompted. 

Renaming a Folder

Right-click on the folder and Rename. You cannot rename the default folders (e.g., Virtual Assets, Message Proxies, etc.) in the server view.  

Moving Folders

You can copy and paste a folder or proxy into another folder within the Message Proxies folder from the right-click menu.

You can also drag subfolders and proxies into other subfolders.

Configuring Proxies

Double-click the added node to open its configuration panel and configure the proxy on the following tabs. When you are done, you can enable the proxy as described in Enabling and Disabling Proxies then start recording as described in Recording Traffic from Message Proxies.

General Tab

On the General tab, rename the proxy and enter a description (optional).

Connections Tab

On the Connections tab you can specify the endpoints where the proxy should listen for messages and where the received messages should be directed. For each endpoint you want to use the proxy, do the following:

  1. Click Add.
  2. Select the appropriate transport type.
  3. Complete the proxy settings as follows:

  4. In the Traffic file field, specify where you want to save the traffic data that will be captured when the proxy is set to record mode. You can later use this traffic file to generate virtual assets that represent the live traffic captured in record mode. See Transferring Files Between the Remote Server and the Local Machine for an easy way to access the recorded traffic file.
    • By default, traffic will be recorded in a file named %n_%d_%t.txt (<proxy_name>_<current_date>_<current_time>.txt). It will be stored within the recorded_traffic folder (this will be created if it does not exist). You can modify the file name, but not the folder. The folder is always located within the VirtualAssets project.
    • When specifying the file name, you can use variables such as %d (current date) %t (current time), %n (proxy name), and %u (unique time-based id). Wildcards can be used together and mixed in with the name. For example, you could use %nProxyTraffic%d or %u_%d%nTraffic.
    • Do not configure multiple proxy connections to write to the same traffic file at the same time. This could corrupt the traffic file.
  5. In the Recording Session area, 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. See More on Recording Session Options below for additional details.
    • 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. See More on Recording Session Options below for additional details.
    • New session file for each message pair (HTTP and internal only) creates a separate traffic file for each request/response pair. See More on Recording Session Options below for additional details.
  6. Click OK.

Http Listeners Tab

On the Http Listeners tab you can configure the ports on which your HTTP(S) listeners should listen. HTTP listeners simplify the connection configuration for recording HTTP traffic. There are two types available:

Reverse Proxy

This type of listener starts a port that listens for traffic and can be used to forward to either a live service or a virtual assets. This is best used when the application under test has configuration options that allow the user to configure the host and port used to connect to the backend service.

To add an HTTP Listener:

  1. Click Add Listener and select Reverse Proxy from the Type dropdown.
  2. Specify a name for the listener.
  3. Click Add Port and enter a port number. You can enable the message proxy to automatically assign a port by specifying 0 as the port number. When the proxy is enabled, the assigned port number will appear in the console. The port is randomly assigned every time the message proxy is changed/enabled. You can also send a GET request to the messageProxies API endpoint to return the automatically-assigned port number. See Testing through the REST API for additional information. 
  4. If the client sends traffic over SSL, enable the Secure option and enable your verification options. See SSL Settings for HTTP Reverse Listener Ports for details.
  5. Click OK to exit the port editor.
  6. Click Add to add additional ports to the listener or OK again to finish adding the listener.

Forward Proxy

Starts up an HTTP Proxy that can route traffic based on the “Host” header. This is best used with Mobile applications where the backend service endpoint is not configurable or in applications under test when there is no configuration option available to change the host and port used to connect to a backend service.

To add a system listener:

  1. Click Add Listener and select Forward Proxy from the Type dropdown.
  2. Specify a name for the listener.
  3. Enter a port number.
  4. Click OK to exit the port editor.
  5. Click Add to add additional ports to the listener or OK again to finish adding the listener.

Proxy Examples

The decision whether to use a reverse proxy or a forward proxy often depends on whether you want to record application traffic or mobile traffic. Examples of how you would record both are shown below:

Example 1: How to record application traffic

  1. Create a new Message Proxy.
  2. Create a reverse proxy listener on the desired port.
  3. Create an HTTP Reverse proxy connection for all traffic.
  4. Enable recording.
  5. Direct your AUT to use the virtualize server "host" and reverse proxy listener "port".

Example 2: How to record mobile traffic

  1. Create a new Message Proxy.
  2. Create a forward proxy listener on a desired port
  3. Create an HTTP Forward proxy connection for all traffic.
  4. Enable recording.
  5. Configure your mobile emulator's proxy settings to use the virtualize server "host" and forward proxy listener "port".


Configuring an HTTP Message Proxy Video Tutorial

This video describes how to set up a message proxy that can capture live traffic.

More on Recording Session Options

The following table explains how traffic data is recorded with different combinations of traffic file name values and recording session options:

Traffic file nameRecording session optionResult
Default / parameterizedAppend new session dataCreates one new file that includes all request/response pairs in the recording session.
StaticAppend new session dataAdds new traffic data to the specified traffic file (if it exists). Otherwise, creates one new file that includes all request/response pairs in the recording session.
Default / parameterizedOverwrite session dataCreates one new file that includes all request/response pairs in the recording session.
StaticOverwrite session dataOverwrites existing traffic data in the specified traffic file (if it exists). Otherwise, creates one new file that includes all request/response pairs in the recording session.
Default / parameterizedNew session file for each message pairCreates one new file for each request/response pair in the recording session. If multiple request/response pairs are detected, multiple files are created.
StaticNew session file for each message pair

If the specified file exists, overwrites existing traffic data every time an additional request/response pair is detected.

If the specified file does not exist, creates one new file for the first request/response pair, then overwrites existing traffic data every time an additional request/response pair is detected.

In both cases, the resulting file contains only the most recent request/response pair.

If a proxy uses the internal protocol and receives MQ traffic while recording, the New session file for each message pair option is not supported. If this option is selected, the default Overwrite session data behavior will be used.

Moving Proxies Across Servers

You can drag a proxy from one server to another to move it. Alternatively, you can copy from one server and paste it to another server.

Proxies can connect to an MQ manager using a global configuration or a local configuration. Global configurations are defined per Virtualizer Server and can be used by  proxies or virtual assets deployed to the server (see Connections Tab). Local configurations are defined for individual proxies or assets.

You can not deploy a proxy or asset connected to a global MQ manager if the MQ manager connection configuration does not exist on the destination Virtualize Server. If you need to move or copy a proxy/asset to another Virtualize Server, you can manually define the MQ manager connection or use the copy function to add the connection settings to the destination server (see Copying an MQ Manager Connection).  

Preventing Infinite Loops

If your proxies and/or Message Forward tools inadvertently set up a forwarding cycle like A> B> C> A, this could result in an infinite loop. To prevent such loops,Virtualize and SOAtest are  configured to stop forwarding after 10 hops. You can change this by setting the system property parasoft.proxy.loop.max.limit (e.g., parasoft.proxy.loop.max.limit=5).

The built-in loop detection only applies to internally-routed forwarding (e.g., routing to localhost, not routing to a host name).

  • No labels