Capturing Error Response Status Codes

[Jon Schendt]

I'm wondering how to best capture response status codes for custom error responses.

For instance, if I use the Customize Error Response Assertion, and set the response status to 404 in the assertion, I don't see that value in the ${response.http.status} variable.  If I were to return a template response rather than an error, I would see the response status in that variable.

A little policy to demonstrate:

The status shows up in the browser, so it has to be somewhere, but I also see that ${response} doesn't have any information.

If best practice is to have another context variable to reference the response code and then reference that in the custom error response assertion, that's fine, but maybe someone knows where the variable is set, and if it can be referenced.

[Joseph Fry]

Jon, as I understand what was just explained to me (thanks Charles L), the error response exists outside of the scope of the policy... the assertion is actually overriding the default value in the Tomcat thread that is handling your session.  It is not a variable in the policy because the policy may terminate unexpectedly and you still want the error to be sent.

I suspect an assertion COULD be created that reads the current error response (presumably if we can set it from policy we could read it from policy), but since your setting it, you can probably just use a variable as you described.

You MIGHT be able to reference it in a message-completed global fragment?  But that still won't appear in the debugger.

[Jon Schendt]

Joe, thank you! I knew I was getting into strange waters, and I appreciate the digging by both you and Charles. I might play around with it a little bit and see if I can write up something custom, but I'd imagine the vast majority of cases would be to create a variable that's passed through into both the Error Response as well as the status.

Thanks!

[Philippe Brand]

Hi,

In your example you don't have a ROUTE assertion so httpRouting.reasonCode will always be NULL.

What we do is to have 'error.code' and 'error.msg' variables.

We use them in Customize Error Response assertion.

Then dealing wih ROUTE assertions:

Here when ROUTE fails, it will call the 'Error" bloc and our 'Sanofi Routing' encap will handle the httpRouting.reasonCode and convert it if needed, filling-in 'status' variable and 'error.msg'. error.code is then set to this status and the Stop processing will "call" the Custom Error Response

For other error checking:

If any one of Int1 or Int2, it will call the Error bloc. if error.code already set (in Int1 or Int2 blocs), it will just fail and call 'Custom Error Response', otherwise it will default an error code and msg, and fails.

After this, we also export error.code and error.msg to be used on 'custom-message-completed' policy, where we export metrics to Splunk.

So to sum up things, our "real" variable to handle response code is error.code.

[Andrew Macdonald]

Hi Jon,

Best practice is indeed to have the response code as a separate context variable.

One reason for this is that the Customize Error Response assertion should ideally be used once at the beginning of the policy to create a template for all errors. Then in each error case the relevant details can be populated. This means you only need to make one change to update all error structures. Including this assertion only once also reduces policy size for exports and imports.

Additionally, I believe the error response is created only after the Raise Error has been processed so it would be too late to utilise any information from the response.

I hope that helps.

[Andrew Macdonald]

--- Duplicated comment (This can be deleted) ---

Hi Jon,

Best practice is to have a separate context variable.

One reason for this is the Customize Error Response should only be used once at the beginning of the policy to set an error template for the rest of the policy. This template can then be populated at the point the error is reached. This means you only need to make one change when you need to update all error responses. It also means the policy is smaller for code migrations.

Additionally, I believe the error response is only compiled once the Raise Error assertion is processed, meaning it would be too late to reference information from the response.

I hope this helps.