Service Bindings Part 6: Preview, $metadata and Fiori Elements Annotations

📌 KEY POINTS
✅ Preview renders a Fiori Elements app from your annotations.
✅ UI annotations belong in metadata extensions of the projection.
✅ $metadata shows exactly what consumers receive.
⚠️ If a field is missing in the UI, check @UI annotations before code.

▶ WHERE WE ARE
The Purchase Request service is published and tested (Parts 2–5). The preview works but looks empty and generic. In this part you describe the screens with annotations, check them in preview, and understand how Fiori Elements turns metadata into UI.

━━━━━━━━━━━━━━━━━━━━
▶ HOW FIORI ELEMENTS WORKS
Fiori Elements does not have hand-written screens. It reads the service's $metadata — entity types, keys, navigation, actions and UI annotations — and generates standard floorplans: a List Report (search + table) and an Object Page (header, sections, item table). So what you see in the app is a direct function of the annotations you publish. If something is missing on screen, look at the annotations first.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE ANNOTATIONS LIVE
Put UI annotations in a metadata extension (DDLX) on the projection view, not in the CDS view itself and never on the ZR_ base views:

• The projection must allow it: @Metadata.allowExtensions: true (added in Managed RAP Part 5).
• One metadata extension per projection entity: ZC_PurchReq and ZC_PurchReqItem.
• @Metadata.layer: #CORE for your own development.

This keeps the data model clean and lets UI and API projections differ.

━━━━━━━━━━━━━━━━━━━━
▶ THE ANNOTATIONS YOU NEED FOR A COMPLETE APP

• @UI.headerInfo — the object's name, plural name and title field (shown on the Object Page header).
• @UI.selectionField — filter fields in the List Report filter bar.
• @UI.lineItem — table columns in the List Report (and in the Items table on the Object Page). Also used to place action buttons above the table with type #FOR_ACTION.
• @UI.facet — the sections of the Object Page: e.g. a "General" section showing the identification fields and an "Items" section showing the item table through the _Item association.
• @UI.identification — fields in the "General" section, plus action buttons on the Object Page header.
• @UI.hidden — hide technical fields like UUIDs.
• @Consumption.valueHelpDefinition — value help (F4) for a field, e.g. currency from the released view I_CurrencyStdVH.

Action buttons appear only if the action exists in the projection BDEF ("use action approve") AND is annotated with #FOR_ACTION. Their enabled state comes from feature control (Managed RAP Part 3) — you do not code it in the UI.

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

1. Right-click ZC_PurchReq → New → Metadata Extension, name ZC_PURCHREQ. Add the annotations from the code example.
2. Do the same for ZC_PurchReqItem.
3. Activate both. (No need to republish the binding for annotation changes, but you may need to clear the metadata cache — see Part 5.)
4. Open ZUI_PURCHREQ_O4, select PurchaseRequest, click Preview.
5. Check: filter bar shows Request ID and Status; table shows columns and Approve/Reject buttons; clicking a row opens the Object Page with General and Items sections; Submit appears in the header; Approve is greyed out for a New request (feature control working); Currency has a value help.

READING $METADATA — WHAT TO LOOK FOR
Open <service URL>$metadata in the browser or /IWFND/GW_CLIENT:

• EntityType Name="PurchaseRequestType" — the entity; <Key> shows RequestUUID and, for draft services, IsActiveEntity.
• Property elements — every exposed field with its Edm type (Edm.Guid, Edm.String, Edm.Decimal…). A field missing here is missing from the projection or service definition.
• NavigationProperty Name="_Item" — the link to items. Missing = child not exposed in the service definition.
• Action elements — submit, approve, reject, and the draft actions. Missing = not in the projection BDEF.
• Annotations Target="…PurchaseRequestType" — UI.LineItem, UI.Facets, UI.HeaderInfo. Missing = annotation not active, not in a metadata extension of THIS projection, or stale cache.

This is the fastest way to answer "is the problem in the backend or in the UI?": if it is correct in $metadata, the backend is done.

━━━━━━━━━━━━━━━━━━━━
▶ WHAT PREVIEW PROVES AND WHAT IT DOES NOT
Proves: annotations, navigation, draft flow, actions, feature control and validations work end-to-end for your user.
Does not prove: launchpad integration, other users' roles, custom UI extensions, performance with real volumes, or deployment in QAS/PRD.

━━━━━━━━━━━━━━━━━━━━
▶ FROM PREVIEW TO A REAL APP

1. In SAP Business Application Studio or VS Code with SAP Fiori tools, create a Fiori Elements "List Report Page" (OData V4).
2. Connect to the system, choose service ZUI_PURCHREQ_O4, main entity PurchaseRequest, navigation entity _Item.
3. Run locally; the app looks like the preview because both read the same metadata.
4. Deploy to the ABAP repository and make it available: on-premise through a launchpad catalog, space/page and target mapping; in the cloud through an IAM app and business catalog (Part 3).

━━━━━━━━━━━━━━━━━━━━
▶ WHAT YOU HAVE AFTER THE SERIES
A complete, annotated Fiori Elements app on a RAP business object, and the skills to publish, move, troubleshoot and verify service bindings.

A developer reported that the Approve button did not appear in the Purchase Request app, although the action worked in EML tests. The UI team suspected a Fiori bug.
Opening $metadata answered it in two minutes: the Action element "approve" was there, but UI.LineItem contained no DataFieldForAction for it. The #FOR_ACTION annotation had been added to the metadata extension of the API projection by mistake, not to ZC_PurchReq. After moving it and clearing the V4 metadata cache, the button appeared, correctly greyed out for requests in status New.
A week later the same team used the same technique the other way round: a missing Items section turned out to be a NavigationProperty missing from $metadata, which pointed to the service definition, not the UI.

• Putting UI annotations directly into CDS views or on ZR_ base views instead of metadata extensions on the projection.
• Forgetting @Metadata.allowExtensions: true on the projection view.
• Annotating an action with #FOR_ACTION but not exposing it in the projection BDEF (or the reverse).
• Coding button enablement in the UI instead of using feature control in the BDEF.
• Missing @UI.facet, which leaves the Object Page empty.
• Wrong targetElement in the Items facet (must be the association name, e.g. '_Item').
• Assuming a UI problem without first checking $metadata.
• Expecting annotation changes to appear without clearing the metadata cache.

• One metadata extension per projection entity, layer #CORE for own development.
• Hide technical keys with @UI.hidden; show semantic numbers instead.
• Use released value help views (…StdVH) for currencies, units and other standard fields.
• Let feature control drive button state; the UI just displays it.
• Check $metadata first whenever something is missing on screen: backend or UI?
• Use the binding preview for fast iteration, then generate the real app with SAP Fiori tools.

Common questions: "How does Fiori Elements know what to display?", "Where do you put UI annotations in RAP and why?", "Which annotations do you need for a List Report and Object Page?", "How do you show an action button?"
Strong answer: Fiori Elements renders from $metadata — entity types, navigation, actions and UI annotations. Annotations go into metadata extensions on the projection so the BO stays UI-neutral and different projections can have different UIs. Name headerInfo, selectionField, lineItem, facet and identification, and explain that an action button needs both the projection BDEF entry and a #FOR_ACTION annotation, while its enabled state comes from feature control. Saying you check $metadata to decide whether an issue is backend or UI is a strong practical signal.