With the List Report in place from Part 2: Creating the List Report, the next natural step is to improve how each product looks when navigating to its details. The Object Page is completely annotation-driven, which means the way fields appear, how they are grouped, and how sections are displayed all depend on how the CDS annotations are written.
This part starts by improving field labels using element-level annotations, then introduces the basic Object Page layout, and finally adds additional sections and groups to give the page a clean structure. One common navigation issue (UUID mismatch) is also explained along the way, since it usually appears right when developers first open the Object Page.
1. Element-Level Annotations
By default, the List Report and Object Page use the raw property names from the entity (name, category, etc.). This often results in labels appearing in lower case or with technical names. To make the fields more readable, element-level annotations allow each field to have a user-friendly label.
Element-level annotations can be added in the same CDS file where you maintain the UI structure. In our setup, this file is: srv/annotations.cds
Below is a simple example of how to assign labels to each field:
using my.products as prod from '../db/schema.cds';
annotate prod.Products with {
name @title: 'Product Name';
description @title: 'Product Description';
category @title: 'Category';
price @title: 'Price';
stock @title: 'Stock Available';
releaseDate @title: 'Release Date';
isAvailable @title: 'Available';
};
After saving the file, restart the CAP server if needed and refresh the browser preview.
The updated labels appear in the List Report.
You should now see readable labels instead of the original lowercase names, as shown in the above screenshot.
2. Object Page Layout configuration (Details Page)
When any of the row item is selected from the table, we will be navigated to details page but there would be some error. You might see the Object Page fail to load with an error similar to:
400 - Element "ID" does not contain a valid UUID
This happens when the model uses:
key ID : UUID;
but the CSV file contains values like:
1,2,3,4
Since UUIDs must be actual GUID strings, CAP rejects these when the Object Page tries to fetch a record by key.
FIX
Update the CSV file to use valid UUID strings for each product, or change the key type to Integer. Most real CAP projects use UUID keys, so the CSV was updated to match.
Replace the data sample of my.products-Products.csv with below data:
ID,name,description,price,stock,category,releaseDate,isAvailable
"B83D6B76-D790-4656-AFBB-79E2D1F0ABA6",Laptop,A powerful laptop for all your computing needs,1200.00,50,Electronics,2024-01-15,true
"BEAA624C-8437-4D1D-B97C-3813BB73118D",Headphones,High-quality noise-cancelling headphones,250.00,150,Electronics,2024-02-20,true
"CDE3B969-E979-4041-A12B-9D68929C1904",Smartphone,The latest smartphone with a stunning camera,899.99,200,Electronics,2024-03-10,true
"3C945EE2-F8F7-44E3-964C-CB912EDA04D7",Coffee Maker,A machine that brews a perfect cup of coffee,75.50,80,Home Appliances,2023-11-05,false
"8423C374-B4DF-4AF6-B36C-F8AF9B0FA06D",Keyboard,A mechanical keyboard for a superior typing experience,125.00,120,Electronics,2024-04-01,true
"2724D8E2-F2D1-4DAD-8389-E6CFF9531137",Blender,A high-speed blender for smoothies and more,99.99,60,Home Appliances,2023-12-15,true
"19B30BE0-535F-4660-A4E0-072D84058C75",Desk Chair,Ergonomic desk chair for maximum comfort,180.00,40,Furniture,2024-02-28,true
"11BF348F-80C5-40BE-9134-D31A914C0755",Monitor,A 27-inch 4K UHD monitor,350.00,70,Electronics,2024-03-25,true
"83C3282B-2F2D-4C23-8793-0E3F22ABAA6C",Vacuum Cleaner,A powerful vacuum cleaner for all floor types,150.00,90,Home Appliances,2023-10-30,true
"B1093BBD-D49E-47DF-A355-ECB8A81F3C3A",Tablet,A lightweight tablet perfect for on-the-go use,450.00,110,Electronics,2024-01-20,true
After updating IDs:
Navigation should now work without errors.
3. Resolving label, Facts and Field Group Issues
While building the application, one of the simplest issues ended up taking the most time. The table columns and the Object Page labels were still showing in lower case and non of the Facets and FieldGroup annotation getting applied, even after adding annotations. It looked like a small thing, but it completely stopped the flow and took far longer to debug than expected.
As shown below, the labels in the List Report and the Object Page simply refused to update:
At first, the problem did not make sense. The annotations were correct, the service was running, and the UI preview was refreshing. But the labels stayed exactly the same. Eventually, the root cause turned out to be something very easy to overlook: the application generator had created an annotation file under the app folder, and that file was overriding the behavior. Since CDS annotations inside the UI module are not compiled by CAP, the UI was never getting the updated metadata.
CDS-based annotations inside the app folder are not included in the service metadata, so the UI will never pick them up.
Because of this, the generated file should be deleted or renamed to avoid confusion.
There are two ways to manage annotations for the application:
Option A (Recommended): Use server-side CDS annotations
Move or copy all annotation blocks into: srv/annotations.cds
CAP will compile these annotations and expose them in the OData $metadata.
Fiori Elements reads its UI behavior from service metadata, so this is the cleanest and most reliable approach.
This is the best practice for CAP-first projects.
Option B: Keep UI-side annotation file and reference it from the UI
If you prefer to keep the generator-created file under: app/productfe/annotations/
then the content must be translated into an OData annotation XML/JSON file and referenced directly in manifest.json as an annotation source.
This keeps the annotations on the UI side only, and works independently of CAP metadata.
This approach is possible, but it requires extra steps and is harder to maintain. It is usually not recommended when building applications with CAP, because UI annotations do not flow through the OData service metadata.
Updated UI on deleting the annotation file following Option A
Object Page Changes
Updated Code Structure
using my.products as prod from '../db/schema';
// Element Level Labels
annotate prod.Products with {
name @title: 'Product Name';
description @title: 'Product Description';
category @title: 'Category';
price @title: 'Price';
stock @title: 'Stock Available';
releaseDate @title: 'Release Date';
isAvailable @title: 'Available';
};
annotate prod.Products with @(
UI : {
HeaderInfo : {
TypeName : 'Product',
TypeNamePlural: 'Products',
Title : {Value: name}
},
SelectionFields: [
name,
category
],
LineItem: [
{ Value: name },
{ Value: category },
{ Value: price },
{ Value: stock },
{ Value: isAvailable }
],
Identification : [
{Value: name},
{Value: description},
{Value: category}
],
Facets: [
{
$Type: 'UI.ReferenceFacet',
Label: 'Product Details',
Target: '@UI.Identification'
},
{
$Type: 'UI.ReferenceFacet',
Label: 'Stock Information',
Target: '@UI.FieldGroup#Stock'
}
],
FieldGroup #Stock: {
Data: [
{ Value: stock },
{ Value: isAvailable }
]
},
}
); After applying this file and refreshing the preview, the Object Page should now have:
7. Summary
At this stage, the Object Page now feels like a proper application screen rather than a raw auto-generated view. The fields have meaningful labels, the content is organized into sections, and navigation works without errors. These elements provide the structure needed for the next phase of enhancements as the application grows.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
| User | Count |
|---|---|
| 48 | |
| 23 | |
| 20 | |
| 18 | |
| 16 | |
| 16 | |
| 13 | |
| 13 | |
| 13 | |
| 12 |