API Connect

Hi Niyasuddin,
This has been requested before.  Unfortunately, as of my retirement at the beginning of the year there was not a way to get this additional information at runtime.  You'll need to open a request for enhancement. You could setup a DataPower SMTP logging target on the specific event code, but that may not notify the individual you'd like to see this detail.

Best Regards,
Steve

This would be a great feature, and I am surprised it hasn't been supported yet. That along with the inability to map errors that occur pre-processing make it hard to align responses with enterprise standards, meaning that consumers often need to support two differing sets of error formats. 

I have run into the same thing while working with API Connect (10.x) the global error policy does catch validation errors, but the default “Validate: Internal Validation Error” isn’t very descriptive for clients. One workaround I tried was to add custom logging in the validate or catch block, then use a gateway script to pull out the detailed error information (like which property failed) from the var://context/validate/error context variable. That way you can forward a cleaner message upstream. It won’t magically give full schema-level detail to the consumer, but at least you can bubble up which element failed instead of just “internal validation error.” It’s kind of similar to what I had to do in another small project of mine (I built a gestational age calculator API in Python). The raw errors coming back from validation weren’t very user-friendly, so I ended up intercepting them, mapping them to something readable, and then returning that to the client. Same principle here.

If you need a starting point, I’d suggest:

• Check validate/error in your DataPower context

• Create a custom error mapping in your global error policy

• Return a simplified JSON payload with the failing element name

Not perfect, but it’s worked decently in my case.

Thank You @Nathan Zayne

Can you please elaborate more on the steps suggested by you?

Thank you @Nathan Zayne, Good to know, we are also looking for this one