Custom message in audit record

[Jan Blokhuis]

Hello,

Is it possible to customize the message in the audit record? I mean the yellow marked text.
This would be convenient to see what exactly has gone wrong instead of viewing the associated logs of the audit.

[Jay MacDonald]

It is not possible to alter that part of the message for the hardcoded messages. You can use the Add Audit Detail assertion to add customised logging. I almost always set up traps in policy to audit when something goes wrong before failing the policy. This pseudocode illustrates what I mean:

-- At least one assertion must evaluate to true // Do something else audit and fail
---- All assertions must evaluate to true  // Do something
------ <assertions to do stuff>
---- All assertions must evaluate to true // Audit and fail
------ Add audit detail // Audit what just failed
------ Stop processing

Most of the time I set up an encapsulated assertion that handles that failure that includes customising the error message and other "clean failure" stuff. I can send an example if you are interested.

------------------------------
Jay MacDonald - Adoption Architect - Broadcom API Management (Layer 7)
------------------------------

[Jan Blokhuis]

Hello Jay,

We are already using the audit details but i'm interested in your example, maybe we can use this to make things more efficient.

Thanks!

[Jan Blokhuis]

Hi @Jay MacDonald, can you please share this example?
​

[Jay MacDonald]

Hi Blokhuis,

  Attached is the encapsulated assertion plus a very simple policy to illustrate its use. You should be able to import the policy into a test service and import he encass via the Encapsulated Assertions dialogue. This is from the SCIM Framework that I am working on, so there is an option to set the Accept header to values that should already be set in policy. Otherwise this is pretty general. It is critical that the service policy initialise the error template and several default values to load into it. When a failure is trapped, the error message and status code are passed as labelled parameters, both of which are used in an audit from within the encapsulated assertion. The encapsulated assertion sets the values for the template end exports them back out so they scope into the error template set up earlier. I use ${failed} as a safety valve in a lot of my policies, so it gets passed without needing to be labelled.

  I hope this helps.

Cheers!

JayMac



------------------------------
Jay MacDonald - Adoption Architect - Broadcom API Management (Layer 7)
------------------------------

Attachment(s)

ErrorHandlerDemo.xml   5 KB 1 version

SCIM FW: Error Handler Encass.xml   11 KB 1 version

[Jan Blokhuis]

Hi Jay,

Thanks for the examples. I'll try them out.