CDS metadata extensions are transportable development objects of technical type DDLX.
In principle, CDS metadata extensions allow you to enrich and override the existing active annotations of a CDS model, which supports metadata extensions. There may potentially be a plurality of CDS metadata extensions for a single CDS entity.
CDS metadata extensions are organized in layers. They overlay one another according to the layer that they are assigned to. The table below gives you an overview of the overlaying relationships between the layers.
For example, CDS metadata extensions of layer PARTNER overlay all CDS metadata extensions of layer INDUSTRY. This applies to all CDS metadata extensions of subordinated layers LOCALIZATION and CORE of layer INDUSTRY too. Within the same layer, the overlay order of CDS metadata extensions isn’t defined and therefore isn’t guaranteed.
Improve Readability: Transferring annotations into CDS metadata extensions can help make your CDS models easier to read. However, make sure that you avoid unnecessary overlays and nontransparent distributions of relocated annotations.
If you want to use CDS metadata extensions, avoid distributing annotations of the same domain over multiple CDS metadata extensions of the same layer. Instead, you should move, for example, all UI annotations of a CDS model to the same metadata extension.
You can create CDS metadata extensions in the same way as other CDS models in the ADT environment. To do this, choose File > New > Other… > ABAP > Core Data Services > Metadata Extension.
Names of CDS metadata extensions are defined in their own namespace, which means their names can, in principle, match the names of the annotated CDS models.
Naming CDS Metadata Extensions: Adapt the name of your CDS metadata extension to the name of the annotated CDS model for establishing a corresponding relationship based on the chosen naming. However, you should always use your customer namespace, such as a suitable prefix for preventing naming conflicts with CDS metadata extensions delivered by SAP.
In the source code of the CDS metadata extension, you first specify the layer that the CDS metadata extension will be assigned to via annotation @Metadata.layer. Then, you name the CDS view whose annotations are to be changed after the introductory key words annotate view. Afterward, you can start entering annotations for the specified CDS view at the header and detail level.
Below shows an example of CDS view ZC_SalesOrderItem, which will be equipped with annotations from a CDS metadata extension. It therefore has annotation @Metadata.allowExtensions:true.
@Metadata.allowExtensions: true
define view entity ZC_SalesOrderItem
as select from ZI_SalesOrderItem
{
@EndUserText.label: 'Sales Order'
key SalesOrder,
key SalesOrderItem,
Product
}
Below shows an example of the CDS metadata extension of this CDS view.
@Metadata.layer: #CUSTOMER
annotate view ZC_SalesOrderItem with
{
@UI.lineItem: [{importance: #HIGH}]
SalesOrder;
@UI.lineItem: [{importance: #HIGH}]
SalesOrderItem;
}
This CDS metadata extension is assigned to the customer layer by means of Example analysis annotation @Metadata.layer:#CUSTOMER.
Choose Layer Assignment: If you want to annotate SAP-delivered CDS view models in your customer system, you should assign your CDS metadata extensions to layer CUSTOMER. Layer PARTNER is intended for corresponding enhancements by partners. When defining metadata extensions for your own models, you can choose layer CORE.
In the illustrated CDS metadata extension, key fields SalesOrder and SalesOrderItem of CDS view ZC_SalesOrderItem are enriched with annotation @UI.lineItem:[{importance:#HIGH}]. This annotation marks the annotated fields as particularly important when showing the data of the CDS view in a tabular display. If possible, the corresponding columns should still be displayed, even if there isn’t sufficient space for displaying all the columns of the table.
The other annotations of CDS view ZC_SalesOrderItem remain active because they aren’t explicitly overlaid by corresponding annotations of the CDS metadata extension. For example, field SalesOrder retains its active annotation @EndUserText.label:'Sales Order'.
CDS metadata extensions are only allowed to annotate such CDS views that have been prepared explicitly for them. These CDS models have annotation @Metadata.allowExtensions:true. You can’t define CDS metadata extensions for other CDS views.
In general, only a subset of all the specified annotations can be used in CDS metadata extensions. Those annotations won’t require any ABAP Data Dictionary activation. As an example, annotations of domain UI, which incorporate controlling information for the presentation and interaction options of UIs, are allowed to be used in metadata extensions.
Identify Permitted Annotations: The annotation definition specifies whether an annotation may be used in CDS metadata extensions. The annotations admissible to be used in CDS metadata extensions are annotated with @MetadataExtension.usageAllowed: true.
If you define metadata extensions for CDS models that you’re not responsible for, you should always carefully evaluate their effect and dependencies, especially if you change the metadata of CDS models delivered by SAP.
Changing SAP-Delivered CDS Models: You always have to evaluate the effects of changing the metadata of SAP-delivered CDS models carefully. Even though from a technical perspective, you may change the annotations of SAP-delivered CDS models without formally applying modifications by leveraging CDS metadata extensions, the applied changes can result in severe functional issues in the application logic. Due to the inheritance mechanism, this may hold true even for application logic that doesn’t directly consume the annotated CDS model but consumes models derived from the CDS model.
In addition, even if an SAP-delivered CDS model was enabled for metadata extensions, there is no guarantee of the lifecycle stability of the corresponding extensions. In other words, the annotated CDS model might be changed in an incompatible way or even be deleted, requiring adaptions of existing metadata extensions.
If in doubt, avoid defining metadata extensions for SAP-delivered CDS models. Instead, define your own CDS models.
Editor’s note: This post has been adapted from a section of the book Core Data Services for ABAP by Renzo Colle, Ralf Dentzer, and Jan Hrastnik.
Comments