Fiori Performance Part 2: OData Request and Back-End Performance
Full lesson currently free to read · AI practice limits apply separately
Make data requests fast: request only needed fields with $select, page with $top and $skip, avoid N+1 patterns with $expand or batching, push filtering and aggregation to CDS, and analyse slow services in the back end.
Visual overview
Explanation
📌 KEY POINTS
✅ Request only needed properties with $select and avoid over-expanding navigation properties.
✅ Page lists with $top/$skip; never load complete large entity sets.
✅ Avoid one request per row (N+1) — use $expand or batched requests.
✅ Filtering, sorting and aggregation belong in CDS and the database, not the UI.
⚠️ A slow service is often a slow CDS view — analyse it in the back end.
━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Part 1 covered start-up. Part 2 covers data access, often the bigger cost.
━━━━━━━━━━━━━━━━━━━━
▶ 1. LEAN REQUESTS
Each property and expanded association costs database and network time. Use $select (automatically with autoExpandSelect in V4) and expand only what the screen shows. Check payload sizes in the network tab.
━━━━━━━━━━━━━━━━━━━━
▶ 2. PAGING
Lists should request pages of data and load more on demand. Requesting a full entity set with thousands of rows is slow in the back end and in the browser. Fiori elements and growing tables page automatically if the service supports it.
━━━━━━━━━━━━━━━━━━━━
▶ 3. AVOIDING N+1
A common anti-pattern is reading a list and then sending one request per row for additional data. Use $expand for related data, include calculated fields in the CDS view, or batch requests. N+1 patterns multiply latency.
━━━━━━━━━━━━━━━━━━━━
▶ 4. PUSH WORK DOWN
CDS views can filter, join, aggregate and calculate in the database efficiently. Doing these steps in JavaScript after loading raw data moves load to the slowest place. Design CDS consumption views for the UI's needs.
━━━━━━━━━━━━━━━━━━━━
▶ 5. BACK-END ANALYSIS
If requests are slow on the server, analyse the CDS view and the service: SQL trace (ST05), ABAP profiler (SAT) or the performance tools for CDS and RAP. Expensive associations, missing indexes and calculations on large tables are typical causes.
━━━━━━━━━━━━━━━━━━━━
▶ STEP BY STEP
- Inspect requests of a slow screen for size and count.
- Remove unnecessary expands and fields.
- Replace a per-row request with an $expand.
- Trace the back-end execution of the slowest request.
✅ CHECKPOINT: the screen sends few, lean requests and the slowest has been analysed in the back end.
How the SAP process fits together
SAP PROCESS EXPLORER · Fiori: from service to user
ERPClimb.comFiori Performance Deep Dive — process breakdown
Topic-specific conceptual flow: how key objects and decisions fit together. SAP configurations and exceptional cases can follow different paths.
Selected process stage
Measure
Analyse start-up time and requests in the browser
What this specific lesson teaches
Make data requests fast: request only needed fields with $select, page with $top and $skip, avoid N+1 patterns with $expand or batching, push filtering and aggregation to CDS, and analyse slow services in the back end.
Key lesson principle: Request only needed properties with $select and avoid over-expanding navigation properties.
Representative SAP learning flow, not a guarantee of system runtime sequence in every scenario. The chapter-specific facts come from the published lesson text.
Real project scenario
An object page took eight seconds because the controller requested supplier details once per item — 200 extra requests for large orders. Adding the supplier name to the items CDS view and expanding it removed the extra calls and the page loaded in under two seconds.
Common mistakes
- Over-expanding associations.
- No paging on large sets.
- Per-row requests.
- Aggregating in JavaScript.
Best practices
- Lean $select and $expand.
- Server-side paging.
- CDS designed for UI needs.
- Back-end tracing for slow services.
Interview angle
Interviewers ask how you optimise OData requests in Fiori apps — select, expand, paging, N+1 — and how you analyse a slow service in the back end.
Practice this lesson
Original educational case studies for SAP consultants, not official SAP certification exam questions. Verify product edition and implementation details against the current SAP documentation.
Quick check
0 of 3 questions attempted
1. What is the N+1 request pattern?
2. Where should aggregation of large data happen?
3. A single OData request is slow on the server. What should you analyse?
Interview questions
1. How do you optimise data performance of a Fiori app?
Answer it in your own words first, then compare.
Check before use: lesson examples are educational, not a guarantee of correctness for your SAP edition or release. Sample code has not been executed on your SAP system. Confirm API availability, syntax, authorizations and business impact in an approved development or test environment.