Handling an internal.server.error in Data Action

[Tagus]

Good afternoon all,

I am looking for some assistance with how to handle errors within a Data Action that is used within the SOAP API Adapter provided by Genesys professional services. Currently I have an issue with a third party API whereby one of their payment functions produces a generic error that does not stop a payment from being taken successfully, but due to the iterative nature of the adapter requiring all scenarios to be mapped, I am at a loss as to how to catch an error and ignore it.

As currently, if the error could be ignored, the flow will receive a correct boolean response that the payment was made successfully and would thus allow a working scenario whilst the third party patches the generic error.

Currently the mapping covers the success criteria of a 'true' or 'false' that the adapter receives when making the API call. But I was thinking that I would need to add a catch for the below error into the translationMap in response to be able to inform the adapter that it should be ignored.

"code": "internal.server.error"
"status": "500"
.........
"details": [
{
"errorCode": "ACTION.REMOTE_ENDPOINT"
}
],

Since the payment will be taken if this error is ignored, it will be a win to get this implementation working whilst awaiting a fix.

Any assistance would be greatly received.

Many thanks!

[Jason_Mathison]

Hi Tagus,

If a data action gets an HTTP response outside of 200 - 299 it will take the failure path as that is considered a failure response. If this is a non-voice IVR you should be able to check which HTTP status code you received and make a decision on what to do.

Other options include contacting the professional services team to modify the SOAP API Adapter for your needs, or put in a middleware layer to handle the response from the SOAP API Adapter differently.

You could also vote for / add comments to this idea: https://genesyscloud.ideas.aha.io/ideas/INB-I-1498

--Jason

[Tagus]

Hi Jason,

That is very helpful and I appreciate the quick response on this post

I will have a further explore on the Flow front to try and catch this in a failure path.

Many thanks!