In the last section, you saw how to add completely new elements to the element list of a CDS view using CDS view extensions. However, when you want to add annotations to existing elements or overwrite annotation values, creating a CDS view extension is not the right approach. To add and overwrite annotations, you have to create a CDS metadata extension. The definition of a CDS metadata extension begins with keyword ANNOTATE VIEW followed by the name of the target entity.
Let us have a look at an example: CDS view entity /DMO/C_AgencyTP on the left, defines, among others, an element AgencyID.
The CDS metadata extension on the right, repeats this element name AgencyID in its element list, that is, inside the pair of curly brackets, and adds annotation @EnduserText.label: 'Customer Text'in front of it.
The following restrictions apply for metadata extensions:
- It is not possible to define new elements in metadata extensions. You can only address existing elements of the target entity and add annotations to them.
- Not all annotations are supported in metadata extensions. the list of allowed annotations contains mostly framework-specific annotations related to UI development, analytics, and search functionality.
As a prerequisite for creating a CDS metadata extension the owner of target entity has explicitly allow this by adding @Metadata.allowExtensions: true to the definition.
Inside a metadata extension, it is mandatory to specify a value for annotation @Metadata.layer. This annotation makes it possible to create several metadata extensions for the same CDS entity. It is used to control the priority, in case the annotation values of the different metadata extensions contradict each other. Let us have a closer look.
When there are more than one metadata extensions for the same CDS entity, the syntax check makes sure they contain different values for annotation @Metadata.layer. In other words, because five different values are supported at the moment, you can define a maximum of five metadata extensions for the same base entity. The priority is as follows:
- #CUSTOMER overwrites all other layers.
- #PARTNER overwrites all other layers except for #CUSTOMER.
- #INDUSTRY overwrites #LOCALIZATION and #CORE.
- #LOCALIZATION overwrites only #CORE and
- #CORE has the lowest priority. The metadata on layer #CORE can be overwritten in any other metadata extension.
Note
In the ABAP RESTful application programming model, it is a best practice to place the UI-related metadata in a metadata extension of layer #CORE. This opens up an elegant way for industry solutions, partners, and customers to adjust (overwrite) the UI configuration to their needs.