Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Showing results for 
Search instead for 
Did you mean: 
Former Member

Hy everybody,

i'm working on SAP Fiori apps & custom Fiori app development & at the beginning i needed some time to understand the concepts & involved components with SAP Fiori. I would like to share a document with you, where you can find some explanations/approaches during error analysis with a SAP Fiori applications & where i try to give some advice for people who are new to this topic.

This document consist of a general debugging part for the components involved and some tricks to find the executed code during error analysis of a SAP Fiori app.

General Information on debugging SAP Fiori:

Application debugging:

Application debugging consists mostly of two parts. First part are the JavaScript sources of the application. Second part is the backend code, which in our place is an abap backend.

- JavaScript application debugging:

My advise would be using google chrome for the JavaScript debugging. The development tools are quite good & the ability to change the JavaScript code directly without having to deploy the sources is great. Also the possibility to check & execute some JavaScript Code in the console is an easy way to check if a solution approach could work in the Java Script code.

What i did not found so far, was a way to debug the SAP JavaScript code, as it is always minified when loaded. => If someone knows a way for this, that would be great if you could share this in the comments part or if you could send me a pm to extend this document that would be great.

- Backend debugging:

Debugging the abap backend can be done as usual with the abap debugger. It's important to use external breakpoints instead of session breakpoints. Otherwise the debugger will not stop at your breakpoints. A helpful point in the backend debugging was, that you can switch the user for which you want to debug in the backend system. You can change the user for which you debug in the settings of e.g. T-Code SE80. We've used this a lot when the abap developer worked directly with the JavaScript developer to check errors/functions in the applications - we changed the breakpoints in the backend to the user of the frontend developer and checked the code directly togehter.

- NetWeaver Gateway debugging:

Avoid to debug in the NetWeaver Gateway implementation directly, depending on the scenario (central hub/decentral hub) you can get lost easy in the code as there are quite some rfc function calls. It's a great product & best you assume, that it's working as designed if the setup&customizing is done properly. My experience was, that most of the time it was an error in our project builded in T-Code SEGW - Gateway Service Builder or a misunderstanding of the protocols implemented with NetWeaver Gateway eg. oData protocoll. If you realy need to debug in Netweaver Gateway Code - try to use the NetWeaver Gateway error protocol T-Code /IWFND/ERROR_LOG - In the error log, you can get a list of the callstack for every error occured - this save's usually a lot of time as you don't have to start at handle_request method every time.

There is an error in a SAP Fiori App - What now?

- Always check your findings/error messages in the SAP Support Portal - Most errors are found & reported and there are SAP notes available for most errors.

- First try to find out, if the error occurs in the JavaScript Code or in the backend system. A fast way to do this is to check the browser console if there are any JavaScript errors or warning. Most of the time, it was a data issue for example missing testdata on dev system or stuff like this.

- If you don't find any hints in the console of your browser, look at the network section of your browser. In chrome it's possible to see the requests that are send to the backend. This is a helpful information where you can see directly if some requests failed & in the response you can directly check if there is an error or nothing at all returned by the backend.

- If you want to now, what service(s) are called by a SAP Fiori Application, check the network section of your browser for /sap/opu calls as most SAP applications use oData for communication between client app and backend. If you have found the service call that eg. returns dynamic data on a launchpad tile or the service request, that provides the data for the master list, then you are already quite close to the backend implemenation. If you found the service call in the network section of your browser, check T-Code /IWFND/MAINT_SERVICE in this transaction you find the service catalog and there you can search for the called service. Once you found the called service, you can get to the service implementation where you find DPC (Data Provider Class) and MPC (Model Provider Class) of the gateway service and thats where you can set the external breakpoints to debug the requests send to the abap backend. My advice here would be, try to start with dynamic data or simple GET requests as they usualy are the easiest to find - remeber that there is a getentity and getentityset method - put a breakpoint in both of them. If you found the right DPC class of the service implementation, then you are ready to check all functions implemented on the backend side. A good way to find a service fats in /IWFND/MAINT_SERVICE is to call the service with $metadata to get the service name.

I hope someone finds a helpful hint in this brief error analysis description. Let me know by comments or pm if i can help you any further with error analysis in SAP Fiori.

I wish you a nice day.

Regards,

Michael

3 Comments
Labels in this area