0% found this document useful (0 votes)
249 views8 pages

UI Annotations in CDS Views Explained

The document discusses various UI annotations in ABAP CDS including: 1. @UI annotations define how elements are displayed in views like tables, forms, and charts. Examples include @UI.lineItem for table columns, @UI.identification for detail pages, and @UI.fieldGroup to group fields. 2. Technical fields can be hidden from the UI using @UI.hidden while sensitive fields are masked with @UI.masked. 3. Fields can be defined as single data points with optional metadata using @UI.dataPoint, or formatted for multiline text using @UI.multiLineText.

Uploaded by

Sai Boddu
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
249 views8 pages

UI Annotations in CDS Views Explained

The document discusses various UI annotations in ABAP CDS including: 1. @UI annotations define how elements are displayed in views like tables, forms, and charts. Examples include @UI.lineItem for table columns, @UI.identification for detail pages, and @UI.fieldGroup to group fields. 2. Technical fields can be hidden from the UI using @UI.hidden while sensitive fields are masked with @UI.masked. 3. Fields can be defined as single data points with optional metadata using @UI.dataPoint, or formatted for multiline text using @UI.multiLineText.

Uploaded by

Sai Boddu
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
  • Annotation Types Examples
  • ABAP News for Release 7.51

@UI.

-- can add only 1 column in the annotation


Example 1: @[Link] in CDS View @UI --no period: multiple columns can be added
[ ] --array; {column}:--> [ {a},{b},{c}]
In this example, the element @[Link] is used to define, what can be shown in the title of a table or list.

Sample Code
...
@[Link]: { typeNamePlural: 'Sales Orders' }
define view ZExample_SalesOrder as select from sepm_cds_sales_order as so {
...
}

Example 2: @[Link]
elements in table-columns

The annotation @[Link] is used to define what elements are shown in the table-columns.

Since the desired columns of a table depend on the use-case (an overview may require more fields than a value-help) several
list-layouts can be defined, distinguished by a qualifier. If the CDS view contains analytical annotations, for
example @DefaultAggregation, they are considered automatically. No additional UI annotations are required.

Sample Code
...
define view ZExample_SalesOrder as select from sepm_cds_sales_order as so {
@[Link]: [ { position: 10 }, { qualifier: 'ValueList', position: 10 } ]
key so.sales_order_id as SalesOrder,

@[Link]: [ { position: 20 }, { qualifier: 'ValueList', position: 20 } ]


[Link].company_name as CompanyName,

@[Link]: [ { position: 30 } ]
so.currency_code as CurrencyCode,

@DefaultAggregation: #SUM
@[Link]: [ { position: 40 } ]
so.gross_amount as GrossAmount
}

Example 3: @[Link]
specific elements for selection/filter
The annotation @[Link] is used to enable specific elements for selection, for example using a filter bar.

If the CDS view is annotated as @[Link] or if a value help is available for the element, this is considered. No
additional UI annotations are required to expose the search field or value help.

Sample Code
...
define view ZExample_SalesOrder as select from sepm_cds_sales_order as so {
key so.sales_order_id as SalesOrder,

@[Link]: [ { position: 10 } ]
[Link].company_name as CompanyName,
...
}
Example 4: @[Link] elements on detail page :-identification

The annotation @[Link] is used to define which elements are shown on a detail page.

Sample Code
...
define view ZExample_SalesOrder as select from sepm_cds_sales_order as so {
@[Link]: [ { position: 10 } ]
key so.sales_order_id as SalesOrder,

@[Link]: [ { position: 20 } ]
[Link].company_name as CompanyName,

@[Link]: [ { position: 30 } ]
so.currency_code as CurrencyCode,

@[Link]: [ { position: 40 } ]
so.gross_amount as GrossAmount
} @[Link]: {groupLabel: 'Contact Details', label: 'Email', position: '10', qualifier: 'cusContact'}

Example 5: @[Link] [Link].email_address,


@[Link]: {groupLabel: 'Contact Details', label: 'Phone', position: '20', qualifier: 'cusContact'}
The annotation @[Link] is used to group several fields, for example, for sections of forms. Similar to the
annotation @[Link], the different field groups have unique qualifiers. [Link].phone_number,

GLQ {grouplabel: label: qualifier}


Sample Code
define view ZExample_SalesOrder as select from sepm_cds_sales_order as so {
@[Link]: [ { qualifier: 'GeneralInformation', position: 10 } ]
key so.sales_order_id as SalesOrder,

@[Link]: [ { qualifier: 'GeneralInformation', position: 20 } ]


[Link].company_name as CompanyName,

@[Link]: [ { qualifier: 'SalesData', position: 30 } ]


so.currency_code as CurrencyCode,

@[Link]: [ { qualifier: 'SalesData', position: 40 } ]


so.gross_amount as GrossAmount
}
CDS View level:-core - top level
Example 6:@[Link]

The annotation @[Link] represents the view of a business card. A badge can be considered as the combination of the
annotations @[Link] and @[Link]. The properties ImageUrl, TypeImageUrl, and Title correspond to the
properties from the annotation @[Link]. In addition to the Titleproperty, the
properties HeadLine, MainInfo and SecondaryInfo of the same format can be specified.
@[Link]: T H M S label,value
Sample Code title headLine mainInfo SecondaryInfo
@[Link]: {
title: {
label, value
label: 'Sales Order',
value: 'SalesOrderID' -- Reference to element in projection-list
},
headLine: {
label: 'Customer',
value: 'CompanyName' -- Reference to element in projection-list
},
mainInfo: {
label: 'Gross Amount',
value: 'GrossAmount' -- Reference to element in projection-list
},
secondaryInfo: {
label: 'Billing Status',
value: 'BillingStatus' -- Reference to element in projection-list
}
}

define view ZExample_SalesOrder as select from sepm_cds_sales_order as so {


key so.sales_order_id as SalesOrder,
[Link].company_name as CompanyName,
so.gross_amount as GrossAmount,
so.billing_status as BillingStatus,
...
}

Example 7: @[Link]
Title Description ChartType Dimensions Measures

The annotation @[Link] is used to define the properties of a chart. The annotation is defined at view level and refers to the
elements that are supposed to be used in the chart. Additionally, a title and description can be provided.

Sample Code T D C Dim Measure


...
@[Link]: {
title: 'Gross Amount by Customer',
description: 'Line-chart displaying the gross amount by customer',
chartType: #LINE,
dimensions: [ 'CompanyName' ], -- Reference to one element
measures: [ 'GrossAmount' ] -- Reference to one or more elements
}

define view ZExample_SalesOrder as select from sepm_cds_sales_order as so {


key so.sales_order_id as SalesOrder,
[Link].company_name as CompanyName,
so.currency_code as CurrencyCode,

@[Link]: 'CurrencyCode'
so.gross_amount as GrossAmount,
...
}

Example 8: @[Link] Technical keys : Guids

The annotation @[Link] prevents fields from being displayed, leaving them available for client.

This is sensible if the CDS has technical keys, for example Guids, that have to be exposed to the OData service to work, but
are usually not supposed to be displayed on the UI. Another use case are fields that are required in other calculations.

In the following example, a data point with precalculated criticality and trend is exposed. These fields are required in the client
to calculate the corresponding values, but are not supposed to be displayed directly.

Sample Code
...
define view ZExample_SalesOrdersByCustomer as select from ... as so {
@[Link]
key so.buyer_guid as BuyerGuid, numeric fields - datapoint
...
@[Link]: {
criticality: 'AmountCriticality', -- Reference to element
trend: 'AmountTrend', -- Reference to element
}

so.actual_amount as ActualAmount,

@[Link]
[Link] as AmountCriticality,

@[Link]
[Link] as AmountTrend
}

Example 9: @[Link] password fields

The annotation @[Link] marks a field that may contain sensitive data and should therefore not be displayed in clear text
by the client.

This annotation does not influence how data is transferred. If a field is marked as @[Link], dataof this field is still
transferred to the client like any other property.

Sample Code
...
define view Destination as select from ... {
@[Link]: [ { position: 10 } ]
key DestinationID,
...
@[Link]: [ { position: 20 } ]
AuthType, -- None, Basic, SSO, ...

@[Link]: [ { position: 30 } ]
BasicAuthUserName,

@[Link]: [ { position: 40 } ]

@[Link]
BasicAuthPassword,
...
}

Example 10:@[Link] multiple lines field : Description

The annotation @[Link] marks a field, for example a description, that is supposed to be displayed by controls that
support multiline-input, for example a text area.

Sample Code
...
define view Product as select from ... {
@[Link]: [ { position: 10 } ]
key ProductID,

@[Link]: [ { position: 20 } ]
ProductName,
@[Link]: [ { position: 30 } ]

@[Link]: true
Description,
...
}

Example 11: @[Link]

The annotation @[Link] defines a single point of data, typically a number, that can be enriched with business-relevant
data, for example if a high or low value is desired, or if the value is increasing to decreasing.

The simplest variant of a data point consists of a value and a tile. In this case, only the value itself is exposed, without
additional information.

Sample Code
...
define view ZExample_SalesOrdersByCustomer as select from ... as so {
key so.buyer_guid as BuyerGuid,

@[Link]: true
so.currency_code as CurrencyCode,

@[Link]: { title: 'Gross Amount' }

@[Link]: 'CurrencyCode'
so.actual_amount as ActualAmount

}
ABAP News for Release 7.51 – Meta Data Extensions in
ABAP CDS
[Link]/2016/10/25/abap-news-release-7.51-meta-data-extensions-abap-cds

In the CDS News for 7.50 I blogged about annotations. Annotations enhance the technical
properties of a CDS entity defined in an ABAP CDS DDL source with metadata. We
distinguish ABAP annotations and framework-specific annotations. These annotations can
have a technical or a semantic meaning. And, boy, there are a lot of them. Sometimes (or
as a rule?) the DDL source of a CDS view contains more annotations than SQL statements.
Two questions might arise:

What about SOC (Separation of Concerns)?


What about adding or changing semantic annotations later on without having to
activate the CDS entity (and all its dependent entities!) again?

With ABAP 7.51 SAP begins to tackle these questions. With the so called Meta Data
Extensions you can transfer the definition of strictly semantic annotations (that are those
that are not needed during activation) from the DDL source of a CDS view into a separate
DDL source. You can do so when defining a CDS view for the sake of SOC and a partner
or customer can define Meta Data Extensions for existing CDS views and thus override
existing annotations.

With a CDS Metadata Extension (MDE), you define CDS annotations for a CDS view
outside of the corresponding data definition. A CDS metadata extension is always assigned
to a layer such as core, industry, partner or customer. MDEs are possible for CDS views
but not yet for CDS table functions.

Defining MDEs

An MDE is an own transport object that is defined in an own DDL editor of the ADT. The
ADT even allow you to extract annotations from existing view definitions into MDEs.

Look at the following simplistic CDS view from the example library.

@[Link]: 'DEMOCDSVIEWMDE'
@[Link]: #NOT_REQUIRED
@[Link]: true
define view Demo_Cds_MDE
as select from
demo_expressions
{
@[Link]: 'View, title'
@[Link]: 'View, description'
@[Link]: 'View, longdescription'
'X' as element
}
where
id = 'X'

1/3
It is delivered by SAP with semantic @UI annotations for it’s element element. Now an
industrial solution wants to override some of the annotations without changing the DDL of
the view. It can do so, because the original view allows that with its
annotation @[Link]: true. All the industrial solution has to do is to
define and ship an MDE:

@[Link]: #INDUSTRY
annotate view Demo_Cds_MDE with
{
@[Link]: 'MDE INDUSTRY, title'
@[Link]: 'MDE INDUSTRY, description'
element;
}

The DDL statement to define an MDE is ANNOTATE VIEW. The annotation


@[Link] defines the layer of the MDE. The MDE simply adds annotations or
overrides exisiting annotations for the whole view, elements or parameters of lower layers.
Only element annotations are shown here.

If a partner or customer wants to override again, here she goes:

@[Link]: #PARTNER
annotate view Demo_Cds_MDE with
{
@[Link]:'MDE PARTNER, title'
element;
}

The possible layers are #CORE ,#LOCALIZATION, #INDUSTRY, #PARTNER,


#CUSTOMER, where the prioritty increases from left to right. Annotations that are
currently allowed in MDEs are @EndUserText, @Consumption, and @UI annotations.

Analyzing MDEs

The central API for analyzing annotations is the documented system


class CL_DD_DDL_ANNOTATION_SERVICE. The frameworks delivered by SAP that
work with their own framework-specific annotations use the methods
of CL_DD_DDL_ANNOTATION_SERVICE to analyze the CDS views defined for usage
with their framework.

With release 7.51, the methods of CL_DD_DDL_ANNOTATION_SERVICE take the MDEs


into account. They collect the annotations, depending on the priority of the layers,
according to the following hierarchy:

1. The metadata extensions that are defined for a view are evaluated first. All
annotations are taken from these metadata extensions, according to the layers
defined by the annotation @[Link]. Annotations found in a higher layer are
no longer searched for in a lower layer, so any annotation that exists there is
overridden.
2. The annotations of the CDS view itself that are not found in a metadata extension are
added. These can be annotations from the source code, derived annotations (from
data elements) and inherited annotations. For annotations inherited from other CDS
2/3
entities, any metadata extensions are again evaluated first.

If you do nothing, MDEs are automatically considered:

cl_dd_ddl_annotation_service=>get_annos(
EXPORTING
entityname = 'DEMO_CDS_MDE'
IMPORTING
element_annos = DATA(element_annos) ).

An excerpt of the resulting table element_annos looks like:

The evaluation of MDEs can also be switched off by passing metadata_extension =


abap_false to the methods of CL_DD_DDL_ANNOTATION_SERVICE.

For more information see:

Metadata Extensions
Evaluation of Annotations
Modularizing CDS Annotations - extraction

3/3

Common questions

Powered by AI

Annotating a field with @UI.selectionField enables it for selection, such as through filter bars. This enhances user interaction by allowing easy filtering and searching of data within the CDS view, helping users to efficiently navigate and manage data .

CDS Metadata Extensions help address the Separation of Concerns by allowing semantic annotations to be separated from the CDS view's technical definition. Developers can manage annotations independently from the core data structure, thereby enabling updates or customizations without reactivating the entire CDS entity, maintaining clear separation between different layers of responsibility .

The @UI.chart annotation is structured with several components, including 'title', 'description', 'chartType', 'dimensions', and 'measures'. The 'title' and 'description' provide a narrative for the chart. 'chartType' specifies the type of chart, such as #LINE. 'dimensions' references elements like 'CompanyName' that categorize the data, and 'measures' references numerical elements like 'GrossAmount' that are plotted .

Annotations in ABAP Core Data Services can be extended using metadata extensions (MDE), which allows new annotations to be added or existing ones to be overridden without altering the original CDS view. MDEs can be defined at different layers: #CORE, #LOCALIZATION, #INDUSTRY, #PARTNER, and #CUSTOMER, with increasing priority from left to right. MDEs allow separation of semantic information from the technical definition of CDS views .

Using the @UI.hidden annotation is beneficial when fields should be available for backend logic but should not be visible in the UI, such as technical keys or fields necessary for internal calculations. It prevents fields from being displayed on the UI while still making the data available to the client-side application for processing or calculation purposes .

Metadata layers in MDEs dictate the order of annotation evaluation. Annotations from metadata extensions are evaluated first based on the priority of layers defined by @Metadata.layer. Annotations in higher layers override those in lower layers, which prevents annotations in lower layers from being considered if they exist in higher layers. This layering ensures that customer-specific annotations have precedence over industry-specific ones, and so forth, according to predefined priorities .

The @UI.masked annotation marks sensitive fields, ensuring data within these fields is not displayed in clear text on the client side. While it does not alter data transmission to clients, it enhances security by preventing unauthorized viewing of sensitive information in the UI .

The @UI.badge annotation combines features of @UI.headerInfo and @UI.identification to create a business card view. @UI.headerInfo provides main information like title, while @UI.identification offers detailed data like company name or currency code. Together, they offer a comprehensive overview of key details for quick reference on a card-like UI element .

The methods of CL_DD_DDL_ANNOTATION_SERVICE handle annotations by first evaluating metadata extensions according to their defined layers, prioritizing higher layers over lower ones. This approach ensures that overridden annotations in MDEs are applied first, impacting the system's evaluation by prioritizing customer and partner extensions over core or localization ones, thus allowing flexible adaptation without altering core entities .

The @UI.multiLineText annotation is used to mark fields that should be displayed in controls supporting multiline input, like a text area. It allows long text fields to be shown appropriately, improving text readability and editability in user interfaces .

You might also like