We’ve been working with the SAP Intelligent Robotic Process Automation solution for more than a year now, developing various automations that communicate in different ways. Time for a solution to retrieve SAP’s error messages after a failed Web service call.

Recovering the exact information why your call went wrong was not always that easy. After reading this blog post, I hope you will be able to recover all the necessary details whenever a call went wrong.

When using the ‘Call a SAP Webservice’ (with destination) action in iRPA, the automation can go in failure when the call did not succeed. Retrieving the right SAP Error message and knowing what went wrong to inform the users, might be handy.

In this example, I’m trying to park a supplier invoice with a date in a closed time period.

The Call Webservice with destination will fail because the API call returns a 400 Bad request response. The SAP response itself is hidden in the parameters of the Error when catching it.

So at first, I created an automation that first gets the csrf token that’s needed, and after receiving the token we create a new post payload to park the invoice. If the webservice fails, the automation goes to the script to retrieve the error message. The input of this automation is a json object with data we retrieved from an OCR. The output is a success message or the sap error message.

This a small example of one of the ways we use to find the error. SAP Error is the input variable, that is actually the error that’s linked to step 1.

As you can see, there is a response with the SAP message which can be sent to inform the users when something went wrong.

Different places and types of the error message

At some point, we discovered that we received the error messages in a few different ways, from the same system, using the same kind of payload, asking a JSON response type for example. After a brainstorm with colleagues, we started creating a different automation that we use as dependency for catching errors from a SAP webservice call and is reusable between all our automations that work with API calls.

One of the different kind of error messages, is a XML error message inside a JSON body, this kind of error needs a different approach. Previous script will obviously fail, since there is no json error message to be found.

So, a second possibility is to retrieve the body from your response, put it into the XML to JS activity and go on to finding you error message there.

In the transformed XML structure, you can find your error message in the InnerError variable, or more straightforward in the error message text / code text itself. In the end, we ended up with an automation that at this point can find all kinds of errors and their locations that we encountered.

Conclusion

I hope it helps you in retrieving all error messages you received through webservice calls.

You can always follow me for similar content!

Questions, thoughts or comments? I’d love to hear them. Let’s get in touch!