Technology Blog Posts by SAP
cancel
Showing results for 
Search instead for 
Did you mean: 
Farooq
Product and Topic Expert
Product and Topic Expert
937

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';
}; 

 

Farooq_0-1765353155142.png

After saving the file, restart the CAP server if needed and refresh the browser preview. 
The updated labels appear in the List Report.

Farooq_1-1765353174697.png

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: 

Farooq_2-1765353212497.png

400 - Element "ID" does not contain a valid UUID 
 

Farooq_3-1765353221133.png

This happens when the model uses: 

key ID : UUID;

Farooq_4-1765353261661.png

 

but the CSV file contains values like: 

1,2,3,4 

 

Farooq_5-1765353285174.png

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: 

  • Restart cds watch 
  • Refresh the List Report 
  • Click a row to navigate to the Object Page 

Navigation should now work without errors. 

Farooq_6-1765353394416.png

 

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: 

Farooq_7-1765353423824.png

Farooq_8-1765353430241.png

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. 

 

Farooq_9-1765353443623.png

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 
 

Farooq_10-1765353504693.png

Object Page Changes 

Farooq_11-1765353517444.png

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: 

  • Friendly labels 
  • A clean header 
  • Product details section 
  • Stock section 
  • Proper grouping of fields 

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. 

2 Comments