SAP OData

Each Fiori app is bound to one or more OData services that expose the backend data and operations it needs. When the app loads or the user acts, it calls the OData service over HTTP (returning JSON), which runs the backend logic (often a CDS view) and returns the result. No OData service, no data.

A frequent setup task (and cause of errors) is activating the app’s OData service in the backend/gateway (transaction /IWFND/MAINT_SERVICE). If the service is not active, the app shows errors or no data, one of the most common Fiori issues.

Worth being precise about the two steps, because they are separate and both are required. Registration maps the technical service to an external name in the gateway. Activation makes that name callable. A service registered and not activated exists in the catalogue and returns nothing, which is the state most "the app does not work" reports are in.

The other half people forget is the system alias. In a hub deployment the gateway and the back end are different systems, and the alias is what tells the gateway which back end to call. An alias pointing at the wrong client is the cause of the puzzling case where the service works and returns somebody else's data.

Understanding the call an app makes turns a vague performance complaint into something specific.

On opening, a list report requests the metadata once, then a first page of entities with $top and a $skip, plus $select for the visible columns and $count for the total. Filters typed by the user become $filter.

Scrolling requests the next page. Sorting reissues with $orderby. Opening a record fetches one entity, and its detail sections may use $expand to pull related data.

So a slow app is usually one of four things: the service reads everything and filters afterwards, the expand is pulling far more than the page shows, the page size is large, or the underlying view is slow regardless.

The tool that answers it in seconds is the browser network tab: it shows every call the app made, the full URL with its query options, the response size and the time. Reading that before opening any configuration is the habit worth building.

OData lets apps request precisely what they need using $filter, $select, $expand, $orderby and paging ($top/$skip). Well-built apps use these to fetch minimal data, keeping performance good; poorly-built ones over-fetch.

The critical question for each is whether it reaches the database. In a CDS-based service the framework translates them into the generated SQL, so a filter genuinely reduces what is read. In a hand-built service they only work if somebody implemented them, and the common failure is a service that selects everything and filters in ABAP. That behaves correctly, passes testing on a small dataset, and falls over when real data arrives. See building services in ABAP.

Version note: the OData version matters when you read documentation. Version 2 is what most classic gateway services speak, and version 4 is what newer services and the RAP model use. They differ in the URL conventions, in how batch requests are formed and in what the metadata document looks like, so a code sample for one will not work against the other. Establish which version a service speaks before following any example.

Twenty minutes, and it makes the whole chain visible.

1. Open any standard Fiori list app with the browser developer tools on the network tab.
2. Find the metadata request. It is fetched once and often cached afterwards.
3. Find the first data request. Read its query options: the page size, the selected fields, the count.
4. Type a filter in the app. A new request appears carrying $filter.
5. Sort a column. Another request, with $orderby.
6. Open a record. A single-entity request, possibly with an $expand.
7. Note the response times and sizes. If one call dominates, that is the one to investigate.

Doing this once means never again diagnosing a Fiori performance problem by guessing which layer is slow.

Fiori problems are reported the same way every time, as the app being broken, and the cause is in one of four layers. Working through them in order is much faster than guessing, because each step rules out a layer.

1. Does the tile even appear? If not, the problem is the catalogue and the role, not the service. Nothing has been called yet.

2. Does the app open and show an error? Read the browser network tab. A 404 on the service means it is not activated or the name is wrong. A 403 means the user is authenticated and not authorised. A 500 means the back-end code failed, and the useful detail is in the back-end error log rather than the browser.

3. Does it open and show nothing? The call succeeded and returned an empty set. Either there genuinely is no data for the filter, or the user cannot see any of it. Running the same query as a user with wide authorisations separates those two in a minute.

4. Does it open, show data, and behave oddly? Stale metadata is the usual answer: the service changed and the client cached the old shape. Clearing the cache is the test, and if that fixes it you have your cause.

The reason to follow the order rather than start with the most likely cause is that steps one and two are seconds each, and the layers people jump to first are the slow ones to check.

OData services are secured by the same backend authorizations the role grants; the service checks authorization objects as it runs. Frontend access and backend authorization must align for the app to work.

The consequence worth stating: the service inherits the user's back-end authorisations, so two users calling the same service legitimately see different data. That is correct behaviour and it is also why a report of "the app shows nothing" needs to establish whether it is broken or whether that user is simply not authorised for any of the data. Those look identical from the outside. See Fiori roles for the two halves involved.

• Inactive OData service, the classic "app not working".
• Over-fetching data instead of using query options.
• Missing backend authorization for the service.

• Diagnosing without the network tab. It names the failing call and its status immediately.
• Metadata cached after a service change. The app behaves as it did and the change is live; clearing the cache is the fix.
• Deep expands on a list. See SAP OData services and the launchpad for the surrounding layers.

And one habit worth forming: when a service is slow, compare its response time against the same query run directly in the back end. If both are slow the problem is below the service, and if only the service is slow it is above the database. That one comparison saves a great deal of searching in the wrong layer.

Activating a service is two clicks, and building one whose filters reach the database and whose app stays fast on real data is the part you do in the course.