This topic explains the general procedure for creating message proxies.

In this section:

Creating Proxies

To create a message proxy:

1. In the Virtualize Server tree, right-click the server where you want the proxy deployed (Local machine or a remote server), then choose Add Message Proxy.
   
   
   
   A new Proxy node will be added under the Message Proxies folder (which will be created if not already present). The added proxy will be initially be set to a disabled state.
   
   
   
   
2. Double-click the added node to open its configuration panel.
3. In the General tab, rename the proxy and (optionally) enter a description for it.
4. Open the Connections tab. This is where you specify at what endpoints you want the proxy to listen for messages and where you want it to direct the received messages.
5. 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:
      • HTTP/HTTPS: See HTTP Configuration.
      • JMS: See JMS Configuration.
      • MQ: See MQ Configuration.
      • Internal: See Internal Transport Configuration. Internal proxies can direct traffic to virtual assets or other internal-transport proxies. This can reduce the number of queues when deploying complex virtual assets as well as increase the performance of virtual assets when routing internally.
   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.

You can now enable the proxy as described in Enabling and Disabling Proxies then start recording as described in Recording Traffic from Message Proxies.

More on Recording Session Options

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

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, Virtualize will default to Overwrite session data behavior.

Moving Proxies Across Servers

To move a proxy from one Virtualize server to another, simply drag and drop (or copy/paste) it.

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 is 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).

Note that this loop detection applies only to internally-routed forwarding (e.g., it applies to routing to localhost, not routing to a host name).