Layer7 API Management

Expand all | Collapse all

Common Error Handling framework to capture policy errors

Jump to Best Answer
  • 1.  Common Error Handling framework to capture policy errors

    Posted 05-31-2017 04:00 AM

    I am developing a common error handling framework to act as a catch  block within the policy where we expect errors.

    found that ${service.error.lookuptable} captures the error message. I'm not sure how to access the message and how to traverse the same. Also can anyone help me when this is populated and what type of messages it holds



  • 2.  Re: Common Error Handling framework to capture policy errors
    Best Answer

    Posted 05-31-2017 07:39 PM

    Hi akash531407 ,

    You can get the last error message by ${audit.details.last.fullText} in your policy.

     

    Regards,

    Mark



  • 3.  Re: Common Error Handling framework to capture policy errors

    Posted 06-16-2017 01:07 PM

    this is one I've built for routing failures:

    https://layer7admin.blogspot.com/2015/02/route-failure-message-fragment-v2.html

    you should be able to do something similar (looping over the audit log for the possible error codes of the assertion you expect to have failed).  Also, I've noticed that audit.details.last will break when you turn on debug (because the last assertion becomes an add audit details from the debug fragment).  Though I've found that the only assertion that I need to know why it failed after it was called has been the routing assertion, for everything else I've found that knowing which assertion was enough (which you can do by knowing where you are in the policy through a comment in a catch block).

     

    To clearify, in the gateway a catch block looks like:

    at least one must be true

    -route via https

    -include policy fragment (or all must be true)

    --add comment (this will let you know your policy failed after the route assertion)

    --set error response template (this will talor the error response to the client)

    --stop processing (because the policy should still fail at this point and not continue, which triggers audit events)