The Message Forward tool can be attached to a Message Responder tool to forward messages to another endpoint (e.g., the actual resource, an internal proxy, a virtual asset, etc.). The response returned from the endpoint will be used as the response returned by the Message Responder.
Sections include:
A Message Forward tool can be added as an output to a Message Responder tool so that when an incoming request is not handled by a Message Responder, the Message Forward tool directs that request to another endpoint.
For instance, here is an example for a virtualized service:
The Message Forward tool can be used with a Message Responder that is configured to use either the Multiple Response view or Data Source Correlation (but not both).
Do not chain a Message Forward tool against a Message Responder using BOTH the Multiple Response view and Data Source Correlation.
If you want to use Message Forward to route a message to another endpoint when all other Message Responders in your Responder suite fail, set up your Responder suite with the appropriate Message Responders—some that are configured to virtualize messages, and one last one that is configured to forward responses (acting as a catch-all).
To add a Message Forward tool:
127.0.0.1
, or the special host name host.virt.internal
. When using localhost or 127.0.0.1
, the specified port must match the port Virtualize is deployed on; when using host.virt.internal
the port is not used. For example, a virtual asset deployed on http://localhost:9080/myVirtualAsset can also be reached using http://host.virt.internal/myVirtualAsset.These forward paths are constructed using the same logic as HTTP message proxy forward paths.
|
If your message 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).