You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Current »

The Message Forward tool can be attached to a Message Responder tool to forward messages to another endpoint (for example, the actual resource, an internal proxy, a virtual asset, and so on). The response returned from the endpoint will be used as the response returned by the Message Responder.

Sections include:

Understanding Message Forward

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:

  1. A client sends a request to a Parasoft Virtual Asset.
  2. A Message Responder is selected based on the specified correlations.
  3. The selected Message Responder, which has a Message Forward attached to it, doesn't have a response for the incoming request.
  4. That Message Responder provides the incoming request to Message Forward, which will invoke the actual live service being virtualized.
  5. Message Forward provides a response from the live service to the Message Responder, which then uses it as its response to the client.

Configuring Message Forward

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

  • With data source correlations: It will redirect the incoming request to another endpoint if there is no match in the Data Source Correlation.
  • With Multiple Responses view: It will redirect the incoming request to another endpoint if the incoming request does not match one of the Multiple Responses criteria.

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:

  1. Right-click the related Message Responder tool and choose Add Output.
  2. Choose Forward > Traffic > All Tools > Message Forward.
  3. Configure the tool settings to specify where (to which endpoint) you want the message redirected.
    • For details on Transport tab settings, see:
    • If you want the tool to forward to a router endpoint on the local Virtualize server without consuming an HTTP connection, enter localhost, 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.
    • With the default settings, this tool will use the applicable URL path segments and path parameters received by the attached Message Responder. This way, you do not need to hardcode them in the tool configuration. If you do not want this dynamic forwarding performed, clear the Forward incoming URL and path parameters option.

      Note that:

      • These forward paths are constructed using the same logic as HTTP message proxy forward paths. See Working with Message Proxies.

      • If this option is enabled, the "listen path" that the message proxy uses is the attached Message Responder’s URL Path correlation condition; the "forward path" is the Router Endpoint in the Message Forward tool.
      • Currently headers can only be overwritten in the HTTP transport. For example, MQMD headers and JMS property headers cannot be overwritten through the Message Forward tool.
      • In the Misc tab, you can configure the timeout and valid HTTP response codes. If these metrics aren’t satisfied, an event will be reported to the Event Log available in the Parasoft Event Details perspective (to open this, go to Window > Open Perspective > Other, then choose Parasoft Event Details in the Select Perspective dialog that opens).

Using the Internal Transport

The internal transport allows you to forward to an internal endpoint type: either a virtual asset or an internal-transport proxy. 

  • To forward to a virtual asset, choose Endpoint > Virtual asset and specify the full path to the virtual asset (from the Virtualize Server view). For a virtual asset at Virtual Assets > folder > name, you would enter folder/name. For a virtual asset at Virtual Assets > name, you would enter name.
  • To forward to an internal proxy, choose Endpoint > Internal message proxy, then specify the proxy identifier assigned to that proxy.

Preventing Infinite Loops

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 (for example, parasoft.proxy.loop.max.limit=5). 

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

  • No labels

Need assistance? Visit our support page