SAP Fiori Architecture: Launchpad, UI5, Gateway and Backend

The user enters Fiori Launchpad, which resolves launchpad content, intent navigation and the application resources. SAPUI5 executes in the browser and sends HTTP requests for metadata and business data. SAP Gateway or the relevant service runtime handles OData exposure, routing and protocol processing. Classic SEGW services execute DPC/MPC logic; RAP services execute generated service adapters and behavior implementations over CDS. The backend application performs business checks, authorizations and persistence. A reverse proxy/Web Dispatcher, identity provider, frontend server and backend can be separate or consolidated depending on architecture.

Use this layered model whenever a Fiori app is missing, fails to load, returns no data, gives 401/403/404/500, or saves incorrectly. First determine whether the problem is launchpad content/UI resources, HTTP/connectivity, service registration/metadata, authorization, or backend business logic. In hub landscapes, logs/breakpoints can be split across frontend and backend systems; in embedded S/4HANA, they can still be different software layers even on one SID.

Launchpad catalogs/spaces/pages provide navigation; PFCG/business roles provide content/authorization; SICF exposes HTTP nodes; Gateway service registration or RAP bindings expose APIs; /IWFND/ERROR_LOG and Gateway Client support service diagnosis; CDS/DCL/RAP/DPC implement data/business logic. BTP Work Zone can provide a different launchpad shell while consuming similar backend services. Authentication can be SAML/OIDC/IAS, but backend authorization remains application-specific.

A tile appears but opening it shows 'failed to load data'. Browser network trace shows the UI component loads successfully and the OData metadata returns 200, but the entity read returns 403. That proves launchpad target mapping and service activation are largely working. STAUTHTRACE in the backend identifies a missing business authorization under the propagated user. The team fixes the PFCG role rather than clearing launchpad cache or rebuilding the UI.

Fiori is the strategic S/4HANA UX. Embedded Gateway is common in S/4HANA, while existing hub architectures and BTP shells continue in many landscapes. RAP/Fiori Elements reduces custom UI/service boilerplate for new applications, but the same browser-to-service-to-business-layer troubleshooting discipline remains.

Fiori/UI developers own UI5/client behavior; Gateway/Basis own HTTP/service infrastructure; ABAP/RAP teams own backend service/business logic; Security owns identities/roles; functional teams own business configuration/data.

Fiori launchpad catalogs/spaces, missing tile, Gateway activation and end-to-end OData debugging topics cover individual layers. SICF and /IWFND/* TCode pages provide operational tools.

Production review: Capture app ID or semantic intent, launchpad shell URL, frontend/backend SID/client, browser request URL/status, service name/binding, correlation ID, actual backend user, Gateway log entry and backend message. A support ticket without those identifiers forces every team to rediscover the failing layer. Verify one known-good user/app request to separate global infrastructure from user/data-specific failure.

Additional validation: Service validation for SAP Fiori Architecture: Launchpad, UI5, Gateway and Backend: capture the service or behavior artifact, protocol, binding, consumer, actual backend user, request URL or entity/action, authorization result and backend message. Test direct service calls as well as the Fiori consumer so UI behavior cannot mask a backend security or contract problem. Include one realistic multi-row or concurrent request in addition to single-record tests, and use current target-release RAP documentation when behavior-definition syntax or generated runtime behavior is involved.