Error analysis with SAP Fiori Apps & ABAP Backend System

Error analysis with SAP Fiori Apps & ABAP Backend System

Debugging SAP Fiori: General Information - Debugging an application

There are mainly two elements to application debugging. The first section is the application's JavaScript sources. The backend code, which is an abap backend at our location, is the second half.

Debugging JavaScript applications:

For JavaScript debugging, I recommend using Google Chrome. The development tools are fairly good, and it's great to be able to alter the JavaScript code without having to deploy the sources. The ability to verify and execute JavaScript code in the console is also a convenient technique to see if a solution approach would work in Java Script code.

What I haven't discovered yet is a mechanism to debug SAP JavaScript code, which is always minified before being loaded. If anyone has a way to do this, it would be fantastic if you could share it in the comments section or email me a private message to enhance this paper.— Debugging the backend:

The abap debugger can be used to debug the abap backend as usual. External breakpoints should be used instead of session breakpoints. The debugger will not halt at your breakpoints otherwise. Switching the user for which you wish to debug in the backend system was a useful point in backend debugging. In the settings of T-Code SE80, for example, you can alter the user for whom you debug. We used this a lot when the abap developer worked directly with the JavaScript developer to examine errors/functions in the applications — we switched the backend breakpoints to the frontend developer's user and checked the code together.

NetWeaver Gateway troubleshooting:

Avoid debugging directly in the NetWeaver Gateway implementation; depending on the case (central hub/decentral hub), there are a lot of rfc function calls, and it's easy to get lost in the code. It's a fantastic product, and if the setup and customization are done correctly, you can be confident that it will perform as expected. Most of the time, there was an error in our project built in T-Code SEGW – Gateway Service Builder or a misunderstanding of the protocols implemented with NetWeaver Gateway, such as the oData protocol, in my experience. If you really need to debug in Netweaver Gateway Code, consider using the T-Code /IWFND/ERROR LOG from the NetWeaver Gateway error protocol. – You may get a list of the callstack for each error in the error log — this saves a lot of time because you don't have to start at the handle request method every time.

What should I do if a SAP Fiori App has an error?

–Always check your findings/error messages in the SAP Support Portal - most problems are discovered and reported, and most errors have SAP notes available.

First, determine whether the error is caused by the JavaScript code or the backend system. Checking the browser console for any JavaScript problems or warnings is a quick way to achieve this. The majority of the time, it was a data issue, such as missing testdata on the development system or similar issues.

If you don't discover any hints in your browser's console, try looking under the network section. The requests that are sent to the backend can be seen in Chrome. This is useful information since you can see if any queries failed right away, and you can verify if the backend delivered an error or nothing at all in the response.

If you want to see what services a SAP Fiori application calls, look for /sap/opu calls in your browser's network area, as most SAP applications use oData for communication between the client app and the backend. You're almost there with the backend implementation if you've located the service call that, for example, returns dynamic data on a launchpad tile or the service request that supplies data for the master list. If you detected the service call in your browser's network area,

T-Code /IWFND/MAINT SERVICE should be checked. This transaction gives you access to the service catalogue, where you can look for the requested service. Once you've located the called service, navigate to the service implementation, where you'll discover the gateway service's DPC (Data Provider Class) and MPC (Model Provider Class), as well as external breakpoints for debugging requests sent to the abap backend. My recommendation is to start with dynamic data or basic GET requests because they are usually the easiest to find. 

Remember that there is a breakpoint in both the getentity and getentityset methods. If you've identified the correct DPC class for the service implementation, you're ready to examine all of the backend functions. Calling the service using $metadata to acquire the service name is a handy approach to discover a service fats in /IWFND/MAINT SERVICE.