@UI.

-- can add only 1 column in the annotation

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

Sample Code
...
@UI.headerInfo: { typeNamePlural: 'Sales Orders' }
define view ZExample_SalesOrder as select from sepm_cds_sales_order as so {
...
}

Example 2: @UI.lineItem
elements in table-columns

The annotation @UI.lineItem 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 {
@UI.lineItem: [ { position: 10 }, { qualifier: 'ValueList', position: 10 } ]
key so.sales_order_id as SalesOrder,

@UI.lineItem: [ { position: 20 }, { qualifier: 'ValueList', position: 20 } ]

so.customer.company_name as CompanyName,

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

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

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

If the CDS view is annotated as @Search.searchable 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,

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

The annotation @UI.Identification 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 {
@UI.identification: [ { position: 10 } ]
key so.sales_order_id as SalesOrder,

@UI.identification: [ { position: 20 } ]
so.customer.company_name as CompanyName,

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

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

Example 5: @UI.fieldGroup so.customer.email_address,

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

GLQ {grouplabel: label: qualifier}

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

@UI.identification: [ { qualifier: 'GeneralInformation', position: 20 } ]

so.customer.company_name as CompanyName,

@UI.identification: [ { qualifier: 'SalesData', position: 30 } ]

so.currency_code as CurrencyCode,

@UI.identification: [ { qualifier: 'SalesData', position: 40 } ]

so.gross_amount as GrossAmount
}
CDS View level:-core - top level
Example 6:@UI.badge

The annotation @UI.badge represents the view of a business card. A badge can be considered as the combination of the
annotations @UI.headerInfo and @UI.identification. The properties ImageUrl, TypeImageUrl, and Title correspond to the
properties from the annotation @UI.HeaderInfo. In addition to the Titleproperty, the
properties HeadLine, MainInfo and SecondaryInfo of the same format can be specified.
@UI.badge: T H M S label,value
Sample Code title headLine mainInfo SecondaryInfo
@UI.badge: {
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,
so.customer.company_name as CompanyName,
so.gross_amount as GrossAmount,
so.billing_status as BillingStatus,
...
}

Example 7: @UI.chart
Title Description ChartType Dimensions Measures

The annotation @UI.chart 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

...
@UI.chart: {
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,
so.customer.company_name as CompanyName,
so.currency_code as CurrencyCode,

@Semantics.amount.currencyCode: 'CurrencyCode'
so.gross_amount as GrossAmount,
...
}

Example 8: @UI.hidden Technical keys : Guids

The annotation @UI.hidden 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 {
 @UI.hidden
key so.buyer_guid as BuyerGuid, numeric fields - datapoint
...
@UI.dataPoint: {
criticality: 'AmountCriticality', -- Reference to element
trend: 'AmountTrend', -- Reference to element
}

so.actual_amount as ActualAmount,

@UI.hidden
so.criticality as AmountCriticality,

@UI.hidden
so.trend as AmountTrend
}

Example 9: @UI.masked password fields

The annotation @UI.masked 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 @UI.masked, dataof this field is still
transferred to the client like any other property.

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

@UI.identification: [ { position: 30 } ]
BasicAuthUserName,

@UI.identification: [ { position: 40 } ]

@UI.masked
BasicAuthPassword,
...
}

Example 10:@UI.multiLineText multiple lines field : Description

The annotation @UI.multiLineText 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 ... {
@UI.identification: [ { position: 10 } ]
key ProductID,

@UI.identification: [ { position: 20 } ]
ProductName,
 @UI.identification: [ { position: 30 } ]

@UI.multiLineText: true
Description,
...
}

Example 11: @UI.dataPoint

The annotation @UI.dataPoint 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,

@Semantics.currencyCode: true
so.currency_code as CurrencyCode,

@UI.dataPoint: { title: 'Gross Amount' }

@Semantics.amount.currencyCode: 'CurrencyCode'
so.actual_amount as ActualAmount

}
ABAP News for Release 7.51 – Meta Data Extensions in
ABAP CDS
blogs.sap.com/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.

@AbapCatalog.sqlViewName: 'DEMOCDSVIEWMDE'
@AccessControl.authorizationCheck: #NOT_REQUIRED
@Metadata.allowExtensions: true
define view Demo_Cds_MDE
as select from
demo_expressions
{
@UI.dataPoint.title: 'View, title'
@UI.dataPoint.description: 'View, description'
@UI.dataPoint.longDescription: '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 @Metadata.allowExtensions: true. All the industrial solution has to do is to
define and ship an MDE:

@Metadata.layer: #INDUSTRY
annotate view Demo_Cds_MDE with
{
@UI.dataPoint.title: 'MDE INDUSTRY, title'
@UI.dataPoint.description: 'MDE INDUSTRY, description'
element;
}

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

@Metadata.layer 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:

@Metadata.layer: #PARTNER
annotate view Demo_Cds_MDE with
{
@UI.dataPoint.title:'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 @Metadata.layer. 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