In our policy we are using Stop Processing assertion whenever any validation fails.
1. At Least Once Assertion Must Evaluate to true
1.1 All Assertions Must Evaluate to true
1.1.1 Check for any Code Injection issues
1.2 All Assertions Must Evaluate to true
1.2.1 Customize Error Response
1.2.2 Stop Processing
When ever policy execution reaches to Stop Processing assertion API is responding with Unhandled exception. Not with Customize error response.
What could be the reason for this?
Good Afternoon. Have you tried to run the Service Debugger through to see where the policy walks through? I've tried the logic with the following policy and I receive back the correct response on a 9.1 Gateway when it fails the code injection.
Director, CA Support
Thanks for the response:
I have realized the reason for Unhandled exception response is Global Fragment declared as below:
Policy Type: Global Policy FragmentPolicy Tag: Message Completed.
Customozie error: Unhandled Exception, Response Code: 503
- I believe Global fragments of type 'message completed' should executed on all cases irrepective of success or failure of the policy- Why this response is not returned with policy completes successfully? This executes only when Stop Processing or Raise error assertions are executed.
- Is there a way to configure not to execute this Global Policy Fragments(message completed) for my policy(service)?
You are correct that the global policy will execute on all execution of the policies. The only way to bypass would be to include logic to pass through in your global policy based on certain response from the main policy.
Can you elaborate on logic to pass through global policy? Please provide an example to bypass this.
The policy logic will need to be modified based on the logic in the global policy as the default policy is blank. The simpliest way would be to have at lease one branch with the second branch being continue processing if the primary logic fails.
We have found another workaround. We have used 'Return Template Response to Requestor' assertion instead of Custom Error Response and checked the option 'Send Response Immediately'.
This way I believe this assertion is responding to the requestor before Global Fragment (Message complete) gets executed.
But I am not sure is there any side-effects of using approach?
Why do we have two different response assertions( 'Return Template Response to Requestor' and 'Custom Error Response') which are doing almost the same funtionality?
The checkbox for send response immediately will not wait until the end of the policy to send the response. This will cause the response to be sent and the connection will be closed so keep alives will not be maintained.
The difference between the Return Template Response to Requestor and Custom Error Response is that the custom error response will trigger when any assertion branch fails without traversing the rest of the policy where the Template assertion will need to be built into a failure branch.
Instead of setting your generic error response in 'message completed' set it in your 'message recieved' so that you can overload it.