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

📌 KEY POINTS
✅ Generate the app with the Fiori tools generator (List Report Page, OData V4, your service).
✅ Main entity = root projection; navigation entity = child (items) for the object page table.
✅ Preview locally with npm start; iterate on annotations, not on generated code.
⚠️ Missing columns or sections are almost always annotation problems — check $metadata.

▶ SAP FIORI ELEMENTS TUTORIAL: GENERATE A LIST REPORT AND OBJECT PAGE FROM RAP

━━━━━━━━━━━━━━━━━━━━
▶ WHAT YOU WILL BUILD

In Part 1 you learned how Fiori Elements turns metadata into UI.

Now you will generate a real List Report + Object Page application from a RAP OData V4 service.

The goal is to understand the complete connection:

RAP business object
→ projection and annotations
→ OData V4 service
→ Fiori tools application generator
→ List Report
→ Object Page

You do not need to hand-code a full SAPUI5 CRUD application.

━━━━━━━━━━━━━━━━━━━━
▶ PREREQUISITES / PREVIOUS PART

You need:

• a RAP OData V4 UI service;
• SAP Business Application Studio or a supported Fiori tools development environment;
• access to the backend system/service;
• basic understanding of List Report and Object Page.

A Travel-style service is ideal for learning because it has a clear root entity and child data.

━━━━━━━━━━━━━━━━━━━━
▶ 1. CONFIRM THE BACKEND FIRST

Before opening the application generator, verify the backend.

Check:

• service binding is active;
• OData V4 service is reachable;
• metadata loads;
• root entity set exists;
• keys are correct;
• UI annotations are available or will be added in the next part;
• authorization allows your user to read data.

If the service does not work independently, generating a frontend will not fix it.

━━━━━━━━━━━━━━━━━━━━
▶ 2. CREATE THE FIORI ELEMENTS APPLICATION

In SAP Business Application Studio / Fiori tools, open the application generator.

Choose the floorplan that fits the requirement.

For this tutorial choose:

List Report Page + Object Page

This gives you:

• a list page for searching/filtering many Travels;
• an object page for viewing or editing one Travel;
• navigation based on OData metadata;
• standard actions and draft behavior when exposed by RAP.

━━━━━━━━━━━━━━━━━━━━
▶ 3. SELECT THE ODATA V4 SERVICE

Connect the generator to your SAP system.

Choose the RAP OData V4 service created earlier.

Do not select a similarly named service by guesswork.

Check the service:

• title;
• entity sets;
• service version;
• system destination;
• authentication context.

The frontend is generated against this contract.

━━━━━━━━━━━━━━━━━━━━
▶ 4. CHOOSE THE MAIN ENTITY

Select the root entity, for example:

Travels

That root entity becomes the main List Report collection.

If Bookings are exposed through a navigation/composition relationship, they can later appear on the Travel Object Page.

━━━━━━━━━━━━━━━━━━━━
▶ 5. NAME THE APPLICATION CLEARLY

Use names that make sense to another developer six months later.

For example:

• Module: travelmanagement
• Application title: Travel Management
• Namespace: com.company.travel
• Description: Manage Travels and Bookings

Avoid names such as test1 or demo2 in a project that may later be transported.

━━━━━━━━━━━━━━━━━━━━
▶ 6. GENERATE THE PROJECT

The generator creates the application shell and configuration.

Typical generated artifacts include project configuration, manifest metadata, UI5 dependencies and run configuration.

The important point is:

> The generator creates the frontend application structure. It does not move your business logic out of RAP.

Validations, determinations, actions, authorization and save logic remain in the RAP BO.

━━━━━━━━━━━━━━━━━━━━
▶ 7. RUN THE APP

Start the generated application.

The List Report should open.

If no columns are visible yet, that can be normal when UI annotations are missing or incomplete.

The next lesson focuses on the annotations that shape the List Report and Object Page.

At this stage prove:

• app starts;
• OData call succeeds;
• entity data can be requested;
• navigation is connected;
• no authentication or destination error occurs.

━━━━━━━━━━━━━━━━━━━━
▶ 8. WHAT THE LIST REPORT DOES

A List Report is designed for working with many business objects.

Typical capabilities include:

• filters;
• search where supported;
• table columns;
• sort/group/personalization depending on configuration;
• navigation to an object;
• create/delete/actions where exposed.

The UI is driven mainly by metadata.

This gives teams a consistent user experience without building every control manually.

━━━━━━━━━━━━━━━━━━━━
▶ 9. WHAT THE OBJECT PAGE DOES

The Object Page is for one business object.

For a Travel, it can show:

• header information;
• general data;
• price/status;
• actions;
• Booking child table;
• sections/facets;
• edit/draft controls.

The next lesson will add annotations such as line items, identification fields and facets.

━━━━━━━━━━━━━━━━━━━━
▶ 10. UNDERSTAND DRAFT BEHAVIOR

If the RAP service is draft-enabled, Fiori Elements can use that model.

The user can:

1. open an active object;
2. choose Edit;
3. work on a draft;
4. navigate between sections;
5. save/activate;
6. discard if required.

Do not reimplement draft state in custom JavaScript.

Let RAP and Fiori Elements handle the standard draft contract.

━━━━━━━━━━━━━━━━━━━━
▶ 11. ACTIONS COME FROM RAP

Suppose RAP exposes an action called AcceptTravel.

Fiori Elements can render and call that action when the metadata and annotations expose it.

The action implementation still lives in RAP.

The frontend should not duplicate the business rule.

━━━━━━━━━━━━━━━━━━━━
▶ 12. CHILD ENTITIES

For root-child RAP models, navigation is critical.

If Travel composes Booking and the projection/service exposes that relationship, the Object Page can show a child table.

If child data is missing, check:

1. CDS composition;
2. redirected association in projection;
3. service metadata;
4. UI facet/line-item annotations;
5. authorization.

Do not start by editing the UI project blindly.

━━━━━━━━━━━━━━━━━━━━
▶ 13. WHERE UI ANNOTATIONS SHOULD LIVE

For ABAP/RAP-driven Fiori Elements, many UI annotations can be placed in a metadata extension.

This keeps UI presentation separate from the reusable CDS interface model.

Examples:

• UI.headerInfo
• UI.lineItem
• UI.identification
• UI.selectionField
• UI.facet

The next lesson uses these in detail.

━━━━━━━━━━━━━━━━━━━━
▶ 14. PREVIEW VERSUS REAL APPLICATION

Backend service preview is useful for checking service behavior.

A generated Fiori Elements application is the real frontend project.

Do not confuse the two.

Service preview proves the backend contract.

The generated application proves how Fiori Elements consumes that contract.

━━━━━━━━━━━━━━━━━━━━
▶ 15. TROUBLESHOOTING THE FIRST RUN

━━━━━━━━━━━━━━━━━━━━
▶ APP CANNOT CONNECT
Check destination/system configuration, authentication and service URL.

━━━━━━━━━━━━━━━━━━━━
▶ APP OPENS BUT NO DATA
Check OData request, authorization, filters and backend entity data.

━━━━━━━━━━━━━━━━━━━━
▶ DATA EXISTS BUT NO USEFUL COLUMNS
Check UI annotations.

━━━━━━━━━━━━━━━━━━━━
▶ OBJECT PAGE DOES NOT NAVIGATE
Check key fields and navigation metadata.

━━━━━━━━━━━━━━━━━━━━
▶ CHILD TABLE IS EMPTY
Check composition/navigation plus service exposure.

━━━━━━━━━━━━━━━━━━━━
▶ ACTION IS MISSING
Check base behavior, projection behavior, service metadata and action annotations.

━━━━━━━━━━━━━━━━━━━━
▶ CHECKPOINT

You are ready for Part 3 when:

• the generated application starts;
• the List Report calls the RAP OData V4 service;
• you can open an object;
• the Object Page loads;
• you understand which behavior belongs to RAP and which presentation belongs to Fiori Elements.

━━━━━━━━━━━━━━━━━━━━
▶ COMMON MISTAKES

• Generating the frontend before testing the backend service.
• Duplicating RAP validations in UI JavaScript.
• Using freestyle UI code for standard List Report/Object Page behavior.
• Assuming missing columns mean the service is broken.
• Forgetting to expose child navigation in the projection/service.
• Confusing backend preview with the generated app.

━━━━━━━━━━━━━━━━━━━━
▶ TRY IT YOURSELF

Generate a List Report/Object Page application for a simple RAP service.

Do not add custom extensions yet.

Prove only:

1. connection;
2. entity load;
3. navigation;
4. draft/edit behavior if available.

Then write down which missing UI elements can be solved with annotations rather than code.

━━━━━━━━━━━━━━━━━━━━
▶ INTERVIEW TAKEAWAY

A strong answer is:

“For a RAP-based Fiori Elements app, I first verify the OData V4 service, then use Fiori tools to generate a List Report/Object Page against the root entity. The generated frontend consumes the metadata; business logic stays in RAP. I use metadata extensions for standard UI presentation and only add custom UI extensions when annotations cannot meet the requirement.”

━━━━━━━━━━━━━━━━━━━━
▶ NEXT PART

Part 3 covers List Report and Object Page annotations in detail.

A team starts writing custom SAPUI5 controllers because the generated List Report has no useful columns.

The backend service is healthy. The real issue is that the projection lacks the required UI metadata.

The team adds line-item and selection-field annotations in a metadata extension. The generated app now shows the expected fields without custom controller logic.

• Frontend-first development before proving the RAP service.
• Rewriting standard Fiori Elements behavior in custom UI5.
• Missing navigation metadata for child tables.
• Putting business rules in frontend code.
• Treating annotations as decoration instead of part of the UI contract.

• Prove the service before generating the UI.
• Keep business logic in RAP.
• Use standard floorplans before custom extensions.
• Keep UI annotations in a clean presentation layer.
• Validate keys and navigation before debugging frontend routing.
• Add custom code only when metadata cannot satisfy the requirement.

Expect questions such as “How do you generate a Fiori Elements app from RAP?”, “Where should validation logic live?”, and “Why is the Object Page empty even though the service returns data?” Explain the chain from RAP metadata to Fiori tools and annotations.