When calling a REST endpoint through an integration service, if there is an error, we do not have access to the error data from within the Design workspace. Often REST services return an errorList data structure with details on the error. We currently cannot access this data structure when the status code is not in the 2xx range. There are a number of cases where we would like to handle an error differently based on the error message or code. Also, it would be helpful to document this information for debugging purposes.
A recent example of this is a restful service I call to search for documents. This API returned a specific error message when there are no documents that match the search criteria. Since Chorus cannot access the error message data, I could only build generic error handling in the presentation flow and could not notify the user their search yielded to results. In this case, we had an internal development resource change the API to accommodate the shortcoming in Chorus and not return an error when there are no search results. Modifying the service is not always an option and is not the most effective use of development resources.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.