SAP Fiori Architecture

• UI (SAPUI5/Fiori): the app running in the browser.
• Fiori launchpad & front-end server: hosts the launchpad, apps and the Gateway/OData layer.
• OData services: the RESTful interface exposing backend data.
• Backend (S/4HANA/ABAP + CDS): the business logic and data.

Worth being explicit about one layer people skip: the web dispatcher or reverse proxy in front. It terminates the connection, routes to the right server, and is where external access is controlled. In any landscape where Fiori is reachable from outside the corporate network, it is part of the architecture rather than infrastructure detail.

In an embedded deployment the front-end server runs on the S/4HANA system itself (common, simpler). In a hub deployment a separate front-end server serves Fiori for one or more backends (better isolation and for multi-system landscapes). The choice affects setup, upgrades and security.

The trade is straightforward once stated. Embedded puts the front-end server in the same system as the back end: fewer moving parts, one lifecycle, and the launchpad is tied to that system's availability and upgrade schedule. Hub runs a separate front-end server that can front several back ends, which is what a landscape with more than one ERP needs, and it adds a system to maintain, patch and keep compatible.

The rule of thumb: embedded unless you have a reason, and the usual reason is more than one back end or a requirement to expose the launchpad outside the network without exposing the ERP.

A user opens an app in the launchpad; the UI5 app calls its OData service (through the gateway) which runs the backend logic/CDS and returns JSON; the app renders it. Most Fiori issues, missing tiles, "service not available", no data, map to a specific layer in this chain.

Written as a sequence, because the failure points sit between the steps. The browser loads the launchpad, which reads the user's catalogs to decide which tiles to show. Clicking a tile resolves the target mapping to an application. The UI5 application loads from the front-end server, then calls its OData service. The gateway routes that call to the back end, where the service reads data subject to the user's back-end authorisations, and the result returns as JSON.

Six steps, and each fails differently: no tile, tile does nothing, app does not load, app loads with no data, app errors on data. Knowing which one you are seeing narrows the cause immediately. See the launchpad for the first two.

Twenty minutes, and it converts a vague report into a specific one.

1. Ask what the user sees. No tile, tile that does nothing, blank app, app with an error, or app with no data.
2. No tile: catalog or space assignment on the role.
3. Tile does nothing: missing target mapping.
4. App does not load: the UI5 application is not deployed, or the front-end server is not reachable.
5. App loads and errors on data: the OData service is not activated, or the gateway cannot reach the back end.
6. App loads with no data: back-end authorisation, or genuinely no data for that user.
7. Confirm with the browser's network tab, which shows exactly which call failed and with what status.

Step seven is worth the habit. The network tab answers in seconds what an hour of configuration checking will not.

• Embedded or hub. Driven by how many back ends and by whether the launchpad must be reachable from outside.
• Where the reverse proxy sits. Exposing Fiori externally means a web dispatcher or equivalent in front, and that is a security design rather than a networking detail.
• Which UI5 version. The library can be served from the system or from a content delivery network, and version compatibility with the apps matters at upgrade.
• Caching strategy. The launchpad and UI5 libraries cache heavily, which is what makes it fast and what makes a change appear not to have taken effect.

Between the app and the data sits the gateway, and understanding its job explains a whole class of failures.

Its function is to expose ABAP data as OData over HTTP. A service is registered, mapping a technical service to an external name, and activated, which is what makes it callable. A service that exists and is not activated is the single most common cause of an app that loads and cannot fetch data.

/IWFND/MAINT_SERVICE is where services are maintained, and /IWFND/ERROR_LOG is where failures are recorded with far more detail than the browser receives. Reading that log rather than the client-side message is the difference between a guess and an answer.

In a hub deployment the gateway sits on the front-end server and routes to the back end through a trusted RFC connection, so a failure can be at the gateway, at the connection, or in the back end service, and the log distinguishes them.

The gateway also caches metadata. A changed service that still behaves as it did is usually a cache, and clearing it is the fix everybody learns once, memorably, after an hour of looking elsewhere.

A detail that causes upgrade problems out of proportion to its size: the UI5 runtime is a library, apps are built against a version of it, and where that library is served from is a choice.

From the front-end server means the version is whatever that system carries, updated with it, and every app on that system gets the same one. Simple, and it couples app compatibility to the system's patch level.

From a content delivery network means the version is specified per app or per bootstrap, and can be pinned. That allows an app to stay on a version it was tested against while others move, and it requires the network to be reachable, which matters for internal-only landscapes.

The compatibility question is real. Custom apps built against an older version can break on a newer runtime, usually through a deprecated control or a changed default, and the failure appears after an upgrade rather than during it.

The practical measures are pinning versions for custom apps, testing them against the target runtime before an upgrade rather than after, and keeping a list of which apps are custom, because standard apps are SAP's problem and custom ones are yours.

• Confusing embedded and hub setups.
• Inactive OData service breaking an app.
• Not tracing the request layer when debugging.

• Diagnosing without the network tab. It names the failing call, which no amount of configuration inspection does faster.
• Assuming a hub isolates the back end. It routes to it, so back-end availability and authorisation still decide what a user sees.
• Cache not cleared after a change. See Fiori apps, performance and security for the surrounding concerns.

• Custom apps with no record of which UI5 version they were built against. The breakage appears after an upgrade, and reconstructing what changed is far harder than having written it down.

Understanding the layers is the start, and configuring a deployment with its gateway, services and proxy so apps reach users reliably is the part you do in the course.

The tool to reach for first is the browser network tab. It names the failing call and its status in seconds, and it distinguishes the five failure modes above faster than any amount of checking configuration.