SAP Fiori Elements

SAP Fiori elements moves UI decisions from code into metadata:

1. An OData service exposes the business entities, for example purchase orders and their items.
2. Annotations describe how the UI should present them: UI.SelectionFields for filter fields, UI.LineItem for table columns, UI.HeaderInfo for object titles, UI.Facets for object page sections.
3. The app descriptor (manifest.json) selects a floorplan template for each page and sets options such as initial loading or mass edit.
4. At runtime, the framework reads metadata, annotations and descriptor and builds the pages, including filter bar, variants, tables, forms, messages and navigation.
5. Where the generated page falls short, developers add extensions instead of rewriting the page.

The developer's main work is therefore in the service and its annotations, not in JavaScript. SAP Fiori elements turns a well-annotated service into a working app, and a poorly annotated one into a poor app.

OData V4 adds building blocks and custom pages, so developers can combine standard elements with their own SAPUI5 code inside the same app. The list report paired with the object page is the classic combination, often abbreviated LROP. Choosing a floorplan in SAP Fiori elements means choosing an interaction pattern, not a visual template.

SAP recommends SAP Fiori elements for OData V4 for new applications and states that the OData V2 variant remains fully supported. In practice the choice depends on three factors:

• Back end: RAP service bindings can publish a UI service as OData V2 or V4, and CAP serves OData V4 by default. Services built in SEGW are typically OData V2.
• Extension needs: building blocks and the flexible programming model are available only with OData V4.
• Existing apps: an app that works on V2 does not need migration to keep running; configuration settings differ between the two, for example initialLoad in V4 versus loadDataOnAppLaunch in V2.

For a new custom app on a current SAP S/4HANA or SAP BTP back end, OData V4 is the default choice in SAP Fiori elements, and V2 is the pragmatic choice when the service already exists.

SAP Fiori elements fits when the task follows a standard pattern: search a list, open an object, edit it, run actions. The framework delivers filter bars, variant management, tables, drafts, messages, accessibility and translation support without custom code, and SAP keeps those features current across SAPUI5 releases.

Freestyle SAPUI5 fits when the interaction itself is unusual: a planning board, a guided scanner flow, a highly visual layout, or data from sources that are not OData. Freestyle code gives full control and full responsibility for maintenance.

SAP's own guidance treats the two as combinable rather than exclusive: start from SAP Fiori elements, use building blocks, and write freestyle code only for the gaps. A useful decision test is whether stakeholders can accept the floorplan's layout for at least the main screens. SAP Fiori elements is the better choice whenever the requirement is a business object, not a bespoke interaction.

Extension options depend on who owns the app:

• Your own app: extension points let developers add custom columns, actions, sections, header facets and filters; with OData V4, the flexible programming model adds building blocks and custom pages.
• An SAP-delivered app: adaptation projects, created with SAP Fiori tools, change or extend the app without modifying SAP's code; key user adaptation lets key users rearrange or hide fields at runtime.
• The data side: a new field usually starts in the service and its annotations, not in the UI.

Availability differs by edition: in SAP S/4HANA Cloud Public Edition, check which of these paths SAP supports for the app in question. Every extension of an SAP Fiori elements app becomes code or configuration that someone must own through upgrades.

1. Fighting the floorplan. Large amounts of custom code to force a non-standard layout cancel the maintenance benefit; at that point freestyle SAPUI5 is often more honest.
2. Treating it as no-code. Annotations are code in another form; they need review, versioning and tests.
3. Ignoring draft handling. Edit scenarios without a draft-enabled service lose resume, locking and validation behavior that users expect.
4. Leaving defaults unexamined. Initial loading, mass edit and table types have defaults that can load too much data or too little; set them deliberately.
5. Annotating in two places. Annotations can live in back-end CDS and in local annotation files; local files override the service metadata, and the last file listed in manifest.json wins, so duplicates make behavior hard to trace.

Most SAP Fiori elements problems are service and annotation design problems that only become visible in the UI.