Layer7 API Management

Expand all | Collapse all

Default XML response being logged after Raise Error

Jump to Best Answer
  • 1.  Default XML response being logged after Raise Error

    Posted 10-23-2017 02:22 AM

    Hi,
    I have a policy as below where i check for a condition and raise error if condition is not matched. The policy is as below.

    - At least one
       - All assertions must evaluate to true
                -compare ${request.http.parameter} is not empty
                -Return Template Response as "Succesfully procesed" (Send Immediatly Checked)

       - All assertions must evaluate to true
                - Return Template Response as "Failed as input is empty" (Send Immediatly Checked)
                - Raise Error

    When I don't pass the input I am getting the error response "Failed as input is empty" in SOAP UI. But when i see in the audit viewer response tab i see an XML response. Why this XML is getting generated and logged instead of actual response that we sent to consumer?

     

     

    Sample Code:



  • 2.  Re: Default XML response being logged after Raise Error
    Best Answer

    Posted 10-23-2017 11:20 PM

    Dear suhas.mv ,

    This is working as expected.

    When you checked "Send response immediately", the assertions after template response assertion won't be executed, ie. the Raise error assertion won't be executed, so your template response will be returned to requestor and gateway will think this policy executed successfully.

    When you don't check "Send response immediately", the gateway will continue to execute the remaining assertions until the end of the policy, or an error to terminate the policy. If there are multiple assertions to generate the response, the latest one will be returned to requestor. When Raise error assertion executed, gateway will generate a standard error response and terminate the policy execution. As raise error executed later than template response assertion, the error response will be sent.

     

    If you want to customized the error response, you should use custom error response assertion,

    Customize Error Response Assertion - CA API Gateway - 9.2 - CA Technologies Documentation 

     

    For more details about raise error assertion and return template response assertion, you may refer to,

    Raise Error Assertion - CA API Gateway - 9.2 - CA Technologies Documentation 

    Return Template Response to Requestor Assertion - CA API Gateway - 9.2 - CA Technologies Documentation 

     

    Regards,

    Mark



  • 3.  Re: Default XML response being logged after Raise Error

    Posted 10-23-2017 11:43 PM

    Hi Mark,

     

    Thanks! I think the Customize Error Response is the right assertion to use with raise error.

     

    Regarding the point "When you checked "Send response immediately", the assertions after template response assertion won't be executed, ie. the Raise error assertion won't be executed, so your template response will be returned to requester and gateway will think this policy executed successfully.

    I assume when "Send response immediately" is checked  the "Raise Error" assertion will still be executed after the response is sent to the requester. Because when i see the  response tab in audit viewer, it always has the Default XML response in it in both the cases i.e "Send response immediately Checked and Unchecked". The only difference is, when it is checked the requester gets the template response, if not requester gets a default XML generated by Raise error (This is expected as GW picks up latest response generated). Could you please confirm ?



  • 4.  Re: Default XML response being logged after Raise Error

     
    Posted 11-07-2017 01:15 PM

    You could also replace the Raise Error with Stop Processing so that policy execution is more straightforward (it simply will stop processing where it is put, so putting the Stop Processing assertion inside the last all folder would stop the entire service execution).

     

    Since you really do not need to use Send Response Immediately in the Return Template Response, I would also look into replacing the Return Template Response with Customize Error Response so that you can further control the error handling in a cleaner manner (including response headers and error behavior such as dropping connection on failure etc).