Copy Request Message to Response Assertion
The Copy Request Message to Response assertion copies the inbound request exactly as it appears at the current point in the policy, to the response. It provides a convenient method to review the results of a request without requiring a web service or an http destination.
Copy Request Message to Responseassertion copies the inbound request exactly as it appears at the current point in the policy, to the response. It provides a convenient method to review the results of a request without requiring a web service or an http destination.
The following are some examples on how you can use this assertion:
- When added after the Apply XSL Transformation or Evaluate Regular Expression assertions, the Copy Request Message to Response assertion will send the resulting message back to the client.
- When added after any of the Threat Protection assertions, the Copy Request Message to Response assertion will return the message to the client if the request passes all the threat protection assertions. If the request fails any assertion, a SOAP fault is generated and no message is returned.
Using the Assertion
- Do one of the following:
- To add the assertion to the Policy Development window, see Add an Assertion.
- To change the configuration of an existing assertion, proceed to step 2 below.
- When adding the assertion, the Request to Response Properties automatically appear; when modifying the assertion, right-clickCopy Request Message to Responsein the policy window and selectRequest to Response Propertiesor double-click the assertion in the policy window. The assertion properties are displayed.
- Specify how to handle WSS Security headers in the request messages:OptionDescriptionDon't modify the request Security headerInstructs the Gateway to leave the security header in the outgoing SOAP request message as-is. The security header in the request may still have been modified if the Gateway needed to decrypt any encrypted material during message processing.Use this setting if the protected service needs to do its own checking of the request's original security header, or if the protected service does not care whether its request messages have a security header.For best performance, use this setting whenever possible to minimize the amount of per-request message modification.Do not modify the Security header if the policy uses WS-Security. For more information, see the Add or Remove WS-Security Assertion.Remove Layer 7 actor and mustUnderstand attributes from processed Security headerInstructs the Gateway to remove the 'mustUnderstand' attribute and 'Layer 7' actor from the security header in the outgoing SOAP message.Use this setting if the presence of the Layer 7 actor causes issues with the back-end service. In certain cases, this actor may cause the back-end service to ignore the Security headers because it believes it is addressed to someone else. You will also use this setting if the back-end service does not support Security and would reject a request with 'mustUnderstand' asserted on the Security header.An alternative might be to remove the Security header completely, however this will incur a performance penalty for the extra processing required to remove these from the messages. You may want to keep the Security headers intact for logging purposes.Remove processed Security header from request before routingInstructs the Gateway to remove any security header that was processed by the gateway before forwarding the request to the protected service.Use this setting when the protected service is not expecting security headers in the forwarded SOAP requests.
- Click[OK] when done.