Lesson 3 of 6
Generating the UI: Fiori elements annotations and UI5
7 min
Listen to this lesson
For a claims worklist, Elena doesn't write a UI; she describes one. SAP Fiori elements builds standard floorplans from OData metadata and annotations: a List Report to find claims and an Object Page to work on one. The real work is the annotations, which say which columns appear, which fields are filters, what the header shows and how the page is divided into sections. Joule, the SAP Fiori tools wizards and the Fiori MCP server can all generate them; a person still decides whether the result fits the job.
The annotations that shape the app
| Annotation | Controls | For the claims app |
|---|---|---|
@UI.LineItem | Table columns in the list report | Claim number, customer, serial number, status, claimed amount |
@UI.SelectionFields | Filter bar fields | Status, customer, failure date |
@UI.HeaderInfo | Object page title and type names | Type "Warranty Claim", title claim number |
@UI.Facets and @UI.FieldGroup | Sections and grouped fields on the object page | General, Failure, Items |
@Common.Label | Field labels | Business words, not technical names |
Core UI annotations for a Fiori elements list report and object page in CAP.
Three ways to generate it
| Tool | How | Good for |
|---|---|---|
| Joule in Business Application Studio | From the storyboard, add a UI application and ask Joule to adjust it | Staying inside SAP Build Code |
| SAP Fiori tools | Application Generator wizard and Page Map, in Business Application Studio or VS Code | Deterministic scaffolding with the floorplan you choose |
| Fiori MCP server with a coding agent | Tool generate_fiori_app_cap creates an app inside an existing CAP project; list_functionality and execute_functionality modify it | Agentic work in VS Code or another IDE |
Options for generating a Fiori elements UI for a CAP service.
The Fiori MCP server's recommended agent rules encode good practice that applies whichever tool you use: start with a List Report on the main entity and an Object Page for details, use one main entity with navigation to related entities, use UUID keys, and change the app by editing project code (manifest and annotations), not by personalizing the screen.
Freestyle UI5 with Joule
When the design doesn't fit a floorplan, SAP documents /ui5 slash commands in Joule for freestyle SAPUI5 apps. With a view or controller open, you can ask, for example, for a table in the main view bound to an OData entity; Joule lists the files it considers relevant, proposes the XML view code and explains it. /ui5-typescript commands help migrate JavaScript UI5 apps to TypeScript. Freestyle code is more yours to maintain than annotations, so ask whether a floorplan would do before choosing it.
- Is the screen a list, a detail page or both?Yes → Fiori elements with annotations · No → continue
- Can a flexible column layout or custom section close the gap?Yes → Fiori elements with an extension · No → continue
- Does the team own UI5 skills for the long run?Yes → freestyle UI5, generated with /ui5 and reviewed · No → revisit the design
Checking the generated UI
- Every column and filter has a business label; no technical names leak through.
- The list report filters return the right claims; status filter values match the enum.
- The object page shows items as a table section, created with the claim (draft, if enabled).
- Read-only fields (claim number, status after approval) can't be edited in the UI and are protected in the service as well.
- Keyboard navigation and screen reader labels work; Fiori elements gives you a good start but labels come from your annotations.
- The app behaves the same for a user with only display rights: buttons they can't use are hidden or rejected by the service.
Draft handling deserves a specific look. Fiori elements object pages usually edit through drafts, so a claim being edited exists as a draft until the user saves it. If the generated service enables drafts, test that validations run when the draft is activated, not only on direct API calls, and that a second user sees the draft lock. These behaviors come from CAP and Fiori elements together, and they are easy to miss when the preview is tried by one person with one claim.
- Fiori elements apps come from annotations: LineItem, SelectionFields, HeaderInfo, Facets, FieldGroup and labels.
- Generate with Joule, Fiori tools or the Fiori MCP server; review the annotations, not just the screen.
- Use /ui5 commands for freestyle apps only when a floorplan won't do; freestyle code is more to maintain.
- Authorization lives in the service; the UI only reflects it.
Check your understanding · not graded
Lesson check
1. Which annotation defines the table columns in a Fiori elements list report?
2. Which Fiori MCP server tool creates a Fiori app inside an existing CAP project?
3. What does SAP document the /ui5-typescript Joule commands for?
4. An annotation hides the Approve button for display users. What else is required?