Troubleshooting ABAP-Fiori E2E Scenarios with little (or no) information

Are you struggling with the famous “There is an issue in this Fiori App” email?

Were you not given further details on which is the error, in which environment it happened, nor which is the service name?

Are you starting with SAP Fiori but want to rely on your strong ABAP skills?

Or are you just curious…?

Then this blog post is for you.

Trobleshooting can be tough, even more when the issue is not clearly defined and details are scarse. The goal of this blog post is to guide you to obtain almost all the information you need to deep dive and analyze technical errors regarding Fiori Apps (from now on, ABAP + OData scenarios). It is intended for ABAP developers or consultants who are starting with SAP Fiori and/or Web Development and need some light on the path.

Ready? Join me in this wonderful SAP Fiori-ABAP troubleshooting journey!

Where are we standed?

The Business Picture

Let’s assume the following scenario: An issue is reported by an end-user regarding some Fiori Report which is not showing all the records it should (or duplicated, why not?). No more details given, just the current behavior vs the desired behavior. At this point you could be wondering:

1. Do I have access to the SAP Fiori Launchpad/App? Am I able to reproduce the issue?

2. Where and how can I find the implementation of that logic? Is it SAP Fiori? Is it ABAP?

Let’s also asume you have access to different S/4HANA environments (DEV, QAS, PRD) with proper roles, and the answer to question 1 is Yes, as this is a pre-requisite.

The Technical Picture

In traditional ABAP world, we are used to think of solutions as one big box which handles it all (Logic/Data/UI). Now with (not anymore so) modern SAP technologies such as SAP Fiori or SAP BTP, we need to conceive solutions as decoupled, modularized and decentralized. This layers are connected through a service, which in SAP Realms, implements the OData Protocol.

Before – Monolithic:

◉ Logic: Classic ABAP SE38 Report/Module Pool

◉ Data: Inside the report (ABAP+OpenSQL)

◉ UI:  Inside the report (ABAP ALV / Dynpros)

Now – Layers/Modules:

◉ Logic Layer: ABAP Class/Methods (or any other backend tech)*

◉ Data Layer: Same as before, or CDS Views (or any other DB Provider)*

◉ UI Layer: Fiori App  (or any other Frontend Framework)

◉ Service Layer: OData Service or any other implementation (HTTP-Rest/SOAP)

*These two layers can be combined into one, if we generate an oData Service from a published CDS View.

To clean up, we are on a End-To-End Fiori-ABAP scenario, in which we have a SAP Fiori App that may/may not be running on a standalone Frontend server, and some custom OData implementation running on a Backend server (probably an S/4HANA instance).

The Challenge

I have summarized key things we need to know to make this possible, and that probably we don’t:

1. If the Fiori App is running on a standalone Frontend server, and which is this system.

2. Technical name of the OData service

3. Which is the Backend server the Fiori App is taking the data from

4. Technical name of the service entity which is being queried/updated/created

5. The root cause of the issue

Let’s answer questions 1 to 5. First of all we want to know if where are our SAP Fiori App, OData service and backend logic running. So..

1. Where is Fiori Running?

OData Services may be published and activated in a dedicated envinronment (Frontend server). If this was the case, we need to find the service in the service catalog to verify which is the Backend System that it is pointing to. Remember: we were given no information about this, so here is how we can find out:

Retrieving System ID by checking Fiori URL

Sometimes the hostname hides the System ID of the server. We will look for a pattern which may indicate that. In this example, the hostname is xxxgwd.xx.xx.com. GWD might be our System ID. Otherwise we should ask to a basis consultant or architect.

Look at a system ID pattern in Fiori URL

To make sure, we will try to log in to the system as any other S4 Environment. We first need to fetch the IP for that hostname, so open the Windows Command Line (CMD). And enter the command ping gwd.xx.xx.com. You should receive the response from it:

Pinging Fiori Host through CMD

If this System ID/IP is different than your backend, then we have a Standalone Frontend server in which Fiori is running.

Asuming this is the case, open SAP Logon and create a new connection with that IP, and the System ID we took from the URL. Instance number is usually = 00.

Creating an entry for the Frontend Server

And voila! We reached the Frontend server all on our own. Now we should be able to log in with the same credentials we used for the SAP Fiori Launchpad:

We log in with the same credentials we use in Fiori Launchpad

Keep this open, we will be back in a minute!

2. Which is the OData Service?

OData is always behind a SAP Fiori Application. To verify this, we will use our always handy Chrome Development Tools. Open the Fiori App we are troubleshooting, and hit F12 to open them.

Chrome Development Tools

Go to Network Tab (hit Ctrl+R if requested). Here we have the list of request that the SAP Fiori App is trigering to the Backend. As they work with OData by default, one of these request must be the one who fetches the OData Service Metadata. In the list, look for the keyword $metadata or use the filter bar.

Check the URL. Now we have the complete url of the OData Service just before /$metadata path.

We can get the provider OData Service within the metadata request

As SAP Fiori Apps communicate with OData services, we should almost always be able to see a request sent from the browser to the backend asking for the OData service metadata, which is like the Holy Bible of the service.

We are making progress, but we need more answers..

3. Which is the Backend System?

Now that we have the OData Service Name, got to the Frontend server we logged in step 1, and enter Transaction /IWFND/MAINT_SERVICE to see the Service Catalog.

Here we find all published Services

Remember the URL we fetched from Chrome? There we retrieved our OData service name (step 2). We should be able to find it in the catalog.

Find your service and double click it. On the bottom right, you will see the System Aliases. This is the name of the Logical System (to connect via RFC) of the available backend Systems.

Marked system alias relates to our Backend Server

Now we have reached the backend server of the service. When system alias is double clicked, you will be forwarded to this server (keep in mind it could be the same as the one you are currently logged in).

Actually Troubleshooting

Now we have all the information we need: Frontend Server, Backend Server and OData service. We will find it’s implementation and put a breakpoint on the correct method to debug it.

Go to the SAP Gateway Client from the previous screen.

Entering Gateway Client

Click on Service Implementation button

With Gateway client we are able to test Services

We are taken to the Backend Server, and we can target the Implementing Class

We can navigate to the ABAP Class which acts as backend

As this is a Report, we target the *GET_ENTITYSET method which corresponds to the OData Entity we see on it. In this example NotificationList (we can get Entity names from Service metadata).

This is the final method which is executed from the Fiori App

Place an external breakpoint targeting the user logged in Fiori Server.

Always use External Breakpoints to debug Fiori Apps

This is not magic! Now we are able to trigger a debug session on the backend side, by accessing via SAP Fiori. Enjoy!

Debugger session is triggered after accessing again the SAP Fiori App