ERPClimb logoERPClimb
Login
Fiori Elements
RAP / CDS / ODatabeginner

Fiori Elements Part 1: List Report and Object Page on RAP

Key takeaway

Understand the business and technical purpose of Fiori Elements, how it differs from freestyle SAPUI5 development, and how CDS annotations drive UI rendering at runtime.

What this complete series covers

Build a Fiori Elements List Report and Object Page on a RAP OData V4 service, then refine it with annotations and use extensions only where metadata is not enough.

Who it is for
Best for SAP consultants, developers, and learners who want a practical understanding of Fiori Elements.
Prerequisites
Basic ABAP and ADT in Eclipse are recommended. The series explains the RAP/CDS/OData concepts as they are introduced.
Final outcome
By the end, you should be able to generate, annotate, extend and troubleshoot a RAP-based Fiori Elements application.
  1. Part 1: Fiori Elements Part 1: List Report and Object Page on RAP

    Understand the business and technical purpose of Fiori Elements, how it differs from freestyle SAPUI5 development, and how CDS annotations drive UI rendering at runtime.

  2. Part 2: Fiori Elements Part 2: Generate a List Report and Object Page from RAP

    Generate and run a List Report/Object Page application against a RAP OData V4 service.

  3. Part 3: Fiori Elements Part 3: Designing Apps with UI Annotations

    Learn how to configure List Report and Object Page floorplans in detail using @UI annotations, headers, facets, tables, and actions wired to RAP behavior, including runtime binding to OData V4.

  4. Part 4: Fiori Elements Part 4: Extending Apps with the Flexible Programming Model

    Learn how to add custom logic, actions, and UI fragments to a generated Fiori Elements app without breaking the annotation-driven contract, using the flexible programming model's c

  5. Part 5: Fiori Elements Part 5: Enterprise Scale — Performance, Draft and Clean Core

    Design decisions for large, multi-entity Fiori Elements applications covering deep navigation performance, complex draft hierarchies, custom extension governance, and clean-core-co

System and release assumptions: Examples target recent SAP S/4HANA / ABAP Cloud capabilities. RAP, CDS, OData, and Fiori Elements syntax and tooling can differ by ABAP platform release.

Explanation

📌 KEY POINTS
✅ Fiori Elements generates list report and object page from annotations — no UI5 code.
✅ Chain: RAP BO → projection + metadata extension → service → V4 UI binding → app.
✅ Feature control and authorization from the BDEF drive buttons automatically.
💡 Use freestyle UI5 only for requirements the floorplans cannot meet.

━━━━━━━━━━━━━━━━━━━━
▶ WHAT THIS SERIES COVERS
Part 1: List Report and Object Page on RAP — the big picture
Part 2: Generate a List Report and Object Page from a RAP service
Part 3: Designing apps with UI annotations
Part 4: Extending apps with the flexible programming model
Part 5: Enterprise scale — performance, draft and clean core

━━━━━━━━━━━━━━━━━━━━
▶ 1. WHAT FIORI ELEMENTS IS

  • A set of SAP floorplans (List Report, Object Page, Worklist, Overview Page, Analytical List Page) rendered from OData metadata and annotations.
  • The List Report Object Page (LROP) is the default floorplan for RAP transactional apps.
  • No UI5 view or controller code is written for standard behavior.

━━━━━━━━━━━━━━━━━━━━
▶ 2. THE CHAIN FROM RAP TO APP

  • RAP BO (interface views, BDEF, behavior pool).
  • Projection view + metadata extension with @UI annotations.
  • Service definition → OData V4 – UI binding → publish.
  • Preview in ADT, then generate a deployable app with SAP Fiori tools (Part 2).

━━━━━━━━━━━━━━━━━━━━
▶ 3. WHAT THE BACKEND DRIVES

  • Columns, filters, header, sections: @UI annotations.
  • Create/Edit/Delete buttons: operations in the projection BDEF.
  • Enabled/disabled buttons and fields: feature control (features : instance) and authorization.
  • Messages on fields: reported with %element from validations.
  • Draft handling: Edit/Save/Discard come from with draft in the BDEF.

━━━━━━━━━━━━━━━━━━━━
▶ 4. LIST REPORT VS OBJECT PAGE

  • List Report: filter bar (@UI.selectionField) and results table (@UI.lineItem).
  • Object Page: header (@UI.headerInfo, dataPoints) and sections (@UI.facet with fieldGroups, identification and child tables).

━━━━━━━━━━━━━━━━━━━━
▶ 5. WHEN NOT TO USE FIORI ELEMENTS

  • Highly custom interactions (drag-and-drop planning boards, graphics-heavy screens).
  • Then consider a freestyle UI5 app — still on the same RAP service.
  • In between: flexible programming model extensions (Part 4).

━━━━━━━━━━━━━━━━━━━━
▶ STEP BY STEP

  1. Confirm the RAP BO works via EML or the ADT preview.
  2. Add @Metadata.allowExtensions: true to the projection view.
  3. Create a metadata extension with headerInfo, lineItem and selectionField.
  4. Publish the OData V4 – UI binding and open the preview.

✅ CHECKPOINT: the preview shows a filter bar, a table and an object page without any UI5 code.

Code example

ABAP Code
// Basic CDS projection view exposed as OData V4 for Fiori Elements consumption@EndUserText.label: 'Travel Projection View'@AccessControl.authorizationCheck: #CHECK@Metadata.allowExtensions: truedefine root view entity ZC_Travel_FE  as projection on ZR_Travel{  key TravelUUID   as TravelUuid,      TravelID     as TravelId,      AgencyID     as AgencyId,      CustomerID   as CustomerId,      BeginDate,      EndDate,      @Semantics.amount.currencyCode: 'CurrencyCode'      TotalPrice,      CurrencyCode,      OverallStatus,      /* associations exposed for navigation/value help */      _Booking : redirected to composition child ZC_Booking_FE} // Metadata extension carrying UI annotations separately (recommended for clean separation)@Metadata.layer: #COREannotate view ZC_Travel_FE with{  @UI.facet: [ { id: 'GeneralInfo', purpose: #STANDARD, type: #IDENTIFICATION_REFERENCE, label: 'General Information', position: 10 } ]  @UI.lineItem: [ { position: 10, importance: #HIGH } ]  @UI.selectionField: [ { position: 10 } ]  @UI.identification: [ { position: 10 } ]  TravelId;   @UI.lineItem: [ { position: 20 } ]  @UI.identification: [ { position: 20 } ]  OverallStatus;}

Real project scenario

A travel management team needs a Manage Travel Requests app for internal staff. Instead of commissioning a freestyle SAPUI5 app (estimated 6-8 weeks), the ABAP Cloud team models the business object as a RAP managed business object, exposes a projection view with @UI annotations, and has a working List Report Object Page app running in the Fiori Launchpad within 2-3 days, including standard behaviors like sorting, filtering, export to Excel, and variant management - all inherited for free from the Fiori Elements runtime.

Common mistakes

  • Assuming Fiori Elements is 'less powerful' and defaulting to freestyle UI5 even when a standard floorplan fully covers the requirement, leading to unnecessary maintenance cost.
  • Placing UI annotations directly on the base CDS interface/business object view instead of the consumption projection view, which violates layering and breaks reusability across multiple UIs.
  • Forgetting @Metadata.allowExtensions: true on the projection view, which prevents metadata extensions or key user adaptation from working.
  • Confusing the CDS-level @UI annotations with OData V2 SAP annotations (com.sap.vocabularies.UI.v1) - they are conceptually equivalent but not always syntactically identical, causing confusion when reading generated $metadata XML.
  • Not realizing that in ABAP Cloud, only released, public CDS/OData artifacts may be exposed this way - referencing non-released objects will fail extensibility and upgrade checks.

Best practices

  • Always model UI annotations via metadata extensions on the projection view layer, not on interface or base views, to preserve reuse and layering.
  • Enable @Metadata.allowExtensions on any view intended for UI consumption or customer/partner extension.
  • Reserve freestyle SAPUI5 for genuinely custom interaction patterns; default to Fiori Elements floorplans for standard CRUD/transactional/list-detail scenarios.
  • Keep annotation ownership aligned with software component layering (core vs. partner vs. customer) using @Metadata.layer.
  • Validate generated $metadata via the service binding's preview tool before assuming an annotation was applied correctly.

Interview angle

Interviewers commonly ask candidates to explain the difference between freestyle SAPUI5 and Fiori Elements, and why SAP pushes annotation-driven UI as part of Clean Core. A strong answer distinguishes business logic (RAP behavior), data shape (CDS projection), and UI semantics (annotations/metadata extensions), and explains that Fiori Elements apps upgrade safely because the rendering engine, not custom code, interprets metadata - reducing regression risk during S/4HANA release upgrades.

Practice this lesson

Quick check

1. How does a Fiori Elements list report know which columns to display?

2. What is the primary role of the @UI.headerInfo annotation on a root CDS entity used in a Fiori Elements Object Page?

3. Which artifact is commonly used to keep Fiori Elements UI annotations separate from a reusable CDS interface model?

Interview questions

1. What are the most important best practices for Fiori Elements apps on RAP?

Answer it in your own words first, then compare.

2. What is SAP Fiori Elements, and how does it build UIs from a RAP service?

Answer it in your own words first, then compare.

Practice more with Interview AI →

Reference-verified: the steps are checked against official SAP documentation and tutorials, and object and field names in the sample code are checked for consistency. The code has not been compiled or run on an SAP system by ERPClimb. Syntax marked release-dependent varies by SAP release, so check it in your own system.

More lessons in this topic

Interview questions on this topic

Related SAP topics