Skip to Content
Technical Articles

SAP Gateway Tracing and Error Checking

SAP’s Intelligent Robotic Processing Automation (iRPA) transforms manual and repetitive steps to streamline the production of rapid and successful outcomes. In the process of building these automations, I’ve honed my skills as an iRPA Developer and started to incorporate API web calls to SAP systems. Through this process it became apparent that there was an opportunity to learn a new skillset that would help make me a well-rounded technologist. Being able to support all phases of the end-to-end development process for an automation scenario will lend to quicker development cycles. The result: you won’t require additional support to stage, configure, or troubleshoot systems, when and where its appropriate (that is, having proper authorizations, following your organization’s change management process, to give a few examples)

Hence, the goal with this series of blog posts is to curate my notes from the help I’ve received while developing iRPA bots to execute API calls to SAP systems. My hope is that this collection will assist anyone who may need to make and troubleshoot API backend calls for iRPA, or for any other type of development.

SAP Gateway Tracing and Error Checking

There may come a point you’ll need visibility to the Gateway Server as you progress with your Bot development. For example, while you could be getting one response through Postman, your bot could receive a different response which may require further analysis. There are two helpful transaction codes to help you investigate why that might be the case:  /n/iwfnd/traces and /n/iwfnd/error_log.

Gateway Tracing Tool

/n/iwfnd/traces is a utility that allows you to detect and debug issues on the front end. By enabling the traces, you can see your calls as they hit the Gateway. You should also be mindful that the enabled traces are normally in place for a few hours. Further, the traces are only for your account by default.

In the Performance Trace (V2 Only) tab, all your requests will be listed from all sources such as Postman, iRPA, and even from web browsers. As shown below, clicking on the refresh button on the top left to update the main windowpane with each new request.

What might be more useful from the an iRPA development perspective is the Payload Trace tab. As with the Performance Trace, the list of requests will update after clicking on the refresh button.

You can double click on any request on the list to see the payload sent with the request and the response that was returned. Depending on how the Desktop Studio Debugger is configured, this information may not be persisted or easily retrievable. The Payload Trace will have this information.

If we double click on the failed PATCH request and click on the Response line, we see that the request in this instance wasn’t processed because the CSRF token validation failed.

Gateway Error Log

/n/iwfnd/error_log can be positioned as either an alternative or adjacent tool to the Payload Trace. The Gateway Error Log will display the error logs for all users.

For our example, we sent a PATCH request with an empty payload and that resulted as an entry in the error log that produced a 400 status code.

I hope this series of blog posts helps you navigate through the SAP Gateway and proves useful to your iRPA Bot development.

Be the first to leave a comment
You must be Logged on to comment or reply to a post.