Fiori annotations

The annotations are the same CDS annotations, and the half that turns them into OData metadata is the same compiler: a CAP Java build runs @sap/cds-dk on Node.js to produce the CSN the Java runtime loads. What the Java side owns is serving them, and the few annotations the Java runtime reads itself rather than the compiler.

Showing artifacts, examples and content with confirmed Java applicability. View All CAP

Overview

SAP SHIPS

The same annotations reach a Fiori elements client from a Java service, and the half that produces them is the same compiler: a CAP Java build compiles the model to CSN with the Node.js package @sap/cds-dk, and com.sap.cds:cds-services-bom pins the runtime that serves the result and hosts the index page, whose preview is turned on in a deployment with cds.index-page.enabled. One annotation is Java's alone: a virtual element marked @cds.java.descendants.aggregate builds a hierarchy view from an aggregate expression.

Not covered: At the terms the compiler translates, as on Node.js, with one difference a reader needs: the compiler is a build dependency rather than part of the runtime, so which shortcuts a Java project has follows the @sap/cds-dk version in its package.json and not the cds-services-bom version in its pom.xml.

No community provider states this flavor. The three cds-plugins on this capability are loaded by @sap/cds, which is the Node.js runtime.

Built into com.sap.cds:cds-services-bom

SourceBuilding CAP Java Applications — CDS Maven Pluginchecked 2026-10-15

THE COMMUNITY ADDS

urp-vocab

Artifacts3

3 of 3 artifacts

ArtifactSignals

Packages3

@sap-ux/odata-vocabulariesOASIS and SAP OData vocabularies with a VocabularyService

Signals

none

com.sap.cds:cds-services-bomMaven bill of materials pinning CAP Java module versions

Signals

none

urp-vocabCDS vocabulary for User-Rendered Patterns display annotations

Signals

Functional boundary

Tasks3Beta

Covers, under conditionsNot assessed

Put a value help on a field a Fiori client rendersAlso in UI5, ABAP1 under conditions

A field in a Fiori elements app offers the values it allows instead of a free-text input, with the list coming from the model rather than from code in the app.

Covers getting the value-list annotation onto the field. Where the values are kept — a code list entity, a CDS enum, a table of its own — is the model's design and not this outcome, and so is anything the app adds on top of the control.

Covers, under conditionscom.sap.cds:cds-services-bomThe same two ways on a Java service. The shortcut and the vocabulary translation belong to the compiler, which a CAP Java build runs on Node.js as @sap/cds-dk, and this release serves the metadata that comes out of it.

Conditions: The shortcut reaches a field only where that field is a managed association to the annotated entity. Which shortcuts a project has follows the @sap/cds-dk version the Maven build installs, which since CDS Maven plugin 3.6.0 is a devDependency in package.json rather than a version in pom.xml.

Remaining work: The same modelling as on Node.js. Nothing in this part of the outcome is written in Java.

Open artifact →

See the annotations rendered before any Fiori app exists1 under conditions

A developer changing @UI annotations sees the page they produce straight away, with no UI application in the project to generate or rebuild first.

Covers the loop while the annotations are being written. It is not a way to ship a screen: what answers this outcome is a page the server renders, not an app, and the distinction is where the decision sits.

Covers, under conditionscom.sap.cds:cds-services-bomThe same preview from a Java service, with its own switch: cds.index-page.enabled, rather than the cds.fiori.preview a Node.js project sets.

Conditions: The entity has to be exposed over OData V4. It is disabled in production. cds.index-page.enabled set to true turns it back on in a cloud deployment for a test or a demo.

Remaining work: Nothing in the project for the local loop, and the annotations themselves still come from the model the Maven build compiles.

Open artifact →

Show a self-referencing entity as a Fiori tree tableAlso in ABAP1 under conditions

An entity whose rows point at their own parent is rendered as an expandable tree in a Fiori elements list report instead of a flat list.

Covers the annotations the service carries and the one setting in the app's manifest.json that the guide requires with them. Building the hierarchy in the data, and anything the app does inside the tree's rows, is outside it.

Covers, under conditionscom.sap.cds:cds-services-bomThe same @hierarchy shortcut, because a CAP Java build compiles the model with the same Node.js compiler, and one annotation this runtime reads itself: a virtual element marked @cds.java.descendants.aggregate builds the hierarchy view from an aggregation expression, which is how a tree shows an aggregate over a row's descendants rather than the row's own value.

Conditions: The entity needs a recursive association to itself. The same hierarchy qualifier and TreeTable setting in the app's manifest.json as on Node.js. The shortcut belongs to the compiler, so it is available once the Maven build installs an @sap/cds-dk that has it, independently of the cds-services-bom version.

Remaining work: Add the controlConfiguration block to the app's manifest.json, and write the aggregation expression where the tree is meant to show aggregates.

Open artifact →