This topic explains how to configure message proxies that either:
In this section:
Internal proxies relay traffic to (or from) virtual assets, MQ, HTTP, or other endpoints in a way that minimizes communication outside of the Virtualize server. This is especially useful when constructing complex composite assets with advanced processing behavior.
For example, assume you are establishing an intelligent routing service that directs incoming MQ traffic to either a live system, a virtual asset, a proxy for recording, or another endpoint. If MQ was used throughout, this would require a complex setup with many queues. You can minimize the number of queues (and thus optimize performance) by using MQ only for direct communications with MQ systems, then using the internal transport for all other routing:
You could then use Parasoft CTP to change the proxy’s routing "on-the-fly" based on the user, test scenario being executed, etc.
Internal proxies can forward traffic from:
To configure an internal proxy to forward traffic to a virtual asset or another internal proxy:
folder/name
. For a virtual asset at Virtual Assets> name, you would enter name
.To configure an internal proxy to forward traffic to an MQ or HTTP endpoint:
The standard MQ configuration options for Use replyToQueueName for response and Worker count are not applicable to internal proxies. |
The standard HTTP configuration option for Proxy listen path is not applicable to internal proxies. Instead, internal proxies provide a Path modifier configuration option. This option lets you specify how the proxy should modify incoming URLs. For example, if Path modifier is "/proxy" and the outgoing path is "service/abc", then an incoming URL "http://virt:9080/proxy/123" would be changed to "http://host:port/service/abc/123". |
To configure an internal proxy to forward traffic from an MQ endpoint to an internal endpoint (proxy or virtual asset):
folder/name
. For a virtual asset at Virtual Assets> name, you would enter name
.