RAP / CDS / ODataadvanced

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

Key takeaway

Design decisions for large, multi-entity Fiori Elements applications covering deep navigation performance, complex draft hierarchies, custom extension governance, and clean-core-compliant lifecycle management across landscapes.

Explanation

📌 KEY POINTS
✅ Performance starts in the backend: lean CDS, $select via annotations, no to-many expands in lists.
✅ Draft keeps long edits safe; side effects keep derived fields current.
✅ Clean core: RAP + annotations + flexible programming model, no modifications.
💡 Measure with browser network tab and backend traces before optimizing.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Final part: making Fiori Elements apps fast, safe for long edits and upgrade-proof in large landscapes.

━━━━━━━━━━━━━━━━━━━━
▶ 1. BACKEND PERFORMANCE

The list reads only what the columns and filters need — Fiori Elements requests $select based on the annotations.
Avoid to-many $expand in lists; show counts and totals via to-one aggregate associations.
Texts via text associations instead of per-row lookups.
Indexes/filters that match the default filter bar fields.

━━━━━━━━━━━━━━━━━━━━
▶ 2. FRONTEND PERFORMANCE

Limit visible columns with importance; use growing lists instead of huge page sizes.
Keep custom extensions light (no extra roundtrips per row).
Measure: browser network tab (request count, payload size) and backend traces (SAT, ST05) before optimizing.

━━━━━━━━━━━━━━━━━━━━
▶ 3. DRAFT FOR LONG EDITS

with draft in the BDEF: work is saved server-side, Edit/Save/Discard come automatically.
Total ETag protects the active data while drafts exist.
Prepare runs validations before activation so errors appear early.

━━━━━━━━━━━━━━━━━━━━
▶ 4. SIDE EFFECTS

side effects in the BDEF tell Fiori which fields/entities to reload after a change.
Example: field BookingFee affects field TotalPrice; child changes affect the parent entity.
Without them users see stale derived values until refresh.

━━━━━━━━━━━━━━━━━━━━
▶ 5. CLEAN CORE

Build on RAP, released CDS views and annotations — no modifications of SAP apps.
Extend SAP-delivered Fiori Elements apps via key-user adaptation or the flexible programming model, not by copying them.
Keep extensions in separate, transportable app variants.

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

Measure the list request: fields selected, expands, response time.
Remove to-many expands; add aggregate associations.
Enable draft with total ETag and Prepare validations.
Add side effects for derived fields.
Review extensions against clean-core rules.

✅ CHECKPOINT: the list loads with one lean request and derived fields refresh without manual reload.

Code example

ABAP Code

// ===== 1. Backend: lean list data =====// Projection for the list: only fields the list needs, aggregated values from CDS//   _Totals.NumberOfItems as NumberOfItems     (to-one aggregate, no $expand of items)// Text fields via text associations, not extra requests. // ===== 2. Draft + side effects for large object pages =====//   with draft;  total etag LastChangedAt;//   side effects { field Quantity affects field TotalAmount; }   // reload only what changed // ===== 3. manifest.json settings that matter at scale ====="sap.ui5": {  "models": {    "": { "dataSource": "mainService",          "settings": { "operationMode": "Server", "autoExpandSelect": true } }  },  "routing": {    "targets": {      "PurchaseRequestList": {        "options": {          "settings": {            "initialLoad": "Enabled",            "controlConfiguration": {              "@com.sap.vocabularies.UI.v1.LineItem": {                "tableSettings": {                  "type": "ResponsiveTable",                  "growingThreshold": 20,       // page size                  "selectAll": false                }              }            }          }        }      }    }  }} // ===== 4. Checklist before go-live =====// [ ] list request: only needed $select, no to-many $expand   (browser Network tab)// [ ] backend time per request measured (ST05 / Cross Trace)// [ ] search/filter fields indexed or selective in CDS// [ ] draft tables regenerated, total etag maintained// [ ] no modifications: annotations + FPM extensions only (clean core)// [ ] roles: app tile + service authorization + business authorization

Real project scenario

A logistics company's Fiori Elements object page for shipment orders grew over 18 months to include 14 facets and 3 draft-enabled composition levels; page load times climbed to 8+ seconds and support could not tell whether slowness came from a recent CDS annotation change, a custom determination, or an unrelated key-user field addition, forcing an architecture review that introduced facet lazy-loading, reduced draft scope to the root entity only, and created a formal extension registry.

Common mistakes

Enabling draft at every composition level 'just in case' instead of scoping it to where independent save is truly required
Designing object pages with many eagerly-loaded facets, causing high initial OData request fan-out and slow perceived load time
Allowing multiple teams to add controller extensions and custom actions without a shared extension registry, making root-cause analysis of production defects very slow
Consuming unreleased/internal CDS views or annotations from a custom Fiori Elements app, causing silent breakage on the next S/4HANA upgrade
Treating performance tuning as a frontend-only problem while ignoring underlying CDS view pushdown and association design

Best practices

Scope draft enablement to the entities that genuinely require independent save, not the entire composition tree
Use lazy-loading facets and late-loading table sections to reduce initial OData request fan-out on large object pages
Maintain a formal extension registry documenting every custom action, determination, controller extension, and key-user adaptation with owner and purpose
Consume only released public CDS views and annotations in any app intended to survive S/4HANA upgrades
Periodically review facet-level OData request performance and CDS view execution plans as part of ongoing production support, not only at go-live

Interview angle

Architect-level interviews focus on trade-off reasoning: when to scope draft narrowly, how to diagnose object page performance issues systematically (facet-by-facet request analysis, CDS execution plan review), and how you would design an extension governance process across multiple delivery teams. Demonstrating awareness of the released-API compatibility contract and clean core implications for upgrades is a strong signal of real production ownership rather than app-building experience alone.

Practice this lesson

Quick check

1. A shipment object page became slow after dozens of item columns and expanded navigations were added. What should be checked first?

2. In a RAP-based Fiori Elements application, what is the main purpose of side effects annotations?

3. In a CDS view consumed by a Fiori Elements List Report application, what is the primary purpose of the @UI.lineItem annotation?

Interview questions

1. How do you design Fiori Elements apps for enterprise scale?

Answer it in your own words first, then compare.

2. You inherit a Fiori Elements app with performance and maintainability issues. What do you review?