Is it possible to parse a failure response to a data action within an IVR flow?

[monisk]

We have a data action for which the response configuration is defined as:

{
  "translationMap": {},
  "translationMapDefaults": {},
  "successTemplate": "${rawResult}"
}

The output contract for this data action is:

{
  "properties": {
    "user_email": {
      "type": "string"
    }
  }
}

Example Failure Output:
{
"status": 404,
"code": "not.found",
"message": "The requested resource was not found.",
"messageParams": {},
"contextId": "0966c62d-cad4-43fa-b54d-f409be51a824",
"details": [
{
"errorCode": "ACTION.REMOTE_ENDPOINT"
}
],
"errors": [
{
"status": 404,
"code": "NOT_FOUND",
"message": "REST call for action execute failed. Message:Request to backend service failed. Response from web service: {"code":"not_found","message":"Not Found"} [0966c62d-cad4-43fa-b54d-f409be51a824]",
"messageParams": {},
"details": [],
"errors": []
}
]
}

If we wanted to capture the failure response and handle different errors differently in the IVR flow, how would we be able to do that? With the above the IVR only has access to the response values from the success outputs. How would the configuration or output contract above need to be modified to be able to have failure outputs available in the IVR flow when the data action is invoked? (e.g. extract the status or message from the failure response in the above)

[anon88270151]

Hi Monisk. Thanks you for your feedback. This is currently only possible with Automate flows. To get this to work with call flows would require some non-trivial back end changes to the way Edge integrates with the VXML interpreter. So far we haven't had enough customer demand to make this a priority, but feel free to submit your feedback to https://purecloud.ideas.aha.io/portal_session/new stating your use case and business impact.

One thing we could do in call flows with significantly less code change impact is to at least return the HTTP status code when we know it at the VXML level (we do the vast majority of the time, but there are some cases where we don't). If that would work for you, please be sure to mention that as well in your aha feedback.

[monisk]

Hey Tom,

1. Would you happen to have any recommendations/workarounds in the absence of this feature to achieve what I've described?

2. Also could you elaborate on what you mean by Automate flows?

[anon88270151]

Hi Monisk. Sorry for the delay in getting back with you.

The only way I know to work around this is very intrusive, and doesn't work for errors originating in the HTTP transport layer, though it will for errors originating in your app/web service: Add a couple of additional properties to your successful response, say, an errorCode and an errorMessage. On success, set the errorCode to a success value (whatever you want), the errorMessage to null or empty, and the rest of the response properties as normal. On failure, set the errorCode and errorMessage to reflect the error, set the other response properties to null or empty (or just don't include them). Then in your flow you can examine the errorCode after the Call Data action returns and branch appropriately.
I wish I knew of a better workaround.

Automate flows are essentially non-call flows, like email or chat flows. They are executed by a different runtime environment (Automate) than call flows (Edge/VXML).

[anon88270151]

I completely spaced another, arguably less intrusive, workaround:

1. You can leave your web service as-is, but in Admin modify your action's schema to add the errorCode and errorMessage properties mentioned above.
2. Create an AWS Lambda function that forwards the request on to your web service. But instead of sending the response back directly, it will first add the errorCode and errorMessage properties, which the Lambda will set depending the success or error status of the web service call.
3. Using AWS API Gateway, create a REST API that maps to your Lambda function.
4. Configure your data action in Admin to use the REST API URL.
5. Modify your flow to examine the errorCode on return of the data call, and branch accordingly.

This is still a bit of work, but is a better overall solution mainly since you don't need to modify your web service. It will also intercept any HTTP-level errors between your Lambda and your web service (though not between your flow and the Lambda).
I hope this helps.

[monisk]

Hey Tom,

Thanks for the feedback and suggestions above.

Regarding the approach suggested using AWS Lambda, is this something that is well supported already in purecloud? If so, would you be able to provide some documentation on how to go about setting up a data action which proxies through the AWS Lambda function first? Or if you happen to have an example, that would be helpful.

[anon88270151]

Hey Monisk. I only know of it being done as a proof of concept; it's not something that is officially documented or specifically tested. To us it is just another URL being invoked by the Call Data action, and as long as you configure the schema correctly for it and the service it calls supports the http(s) protocol correctly, it should work.

I asked the person who did the proof of concept if he had any documentation, informal, notes, or anything at all that might be helpful, and he said no unfortunately. But I'm going to look around on Dev Center and other places to see if I can find anyone else who has done this. If I find something I'll let you know.

[monisk]

Hey Tom,

Thanks, any documentation regarding this would be appreciated, please do let me know if you find anything.