Extending CDS Views

Objectives

After completing this lesson, you will be able to:

  • Extend CDS entities using CDS view extensions
  • Extend views using CDS metadata extensions

CDS View Extensions

Technically, the extension of CDS entities is very similar to the extension of dictionary objects. Customers or partners create new development objects that refer to the development object that they want to extend. In the ABAP dictionary they create APPEND structures, in CDS they define CDS entity extensions. CDS view entities are extended with CDS view extensions. A CDS view extensions is defined in a dedicated data definition using statement EXTEND VIEW ENTITY. An existing CDS view can have one or more CDS view extensions.

In this example, CDS view entity /DMO/E_Agency on the left contains one element in the element list. The view extension on the right, adds an element, ZZCategoryZAG, to this list. The link between the two data definitions is established through the CDS view entity name after key word EXTEND VIEW ENTITY.

Note
The CDS view entity extension has to specify the data source name when addressing fields or elements. In the example, it uses Agency which is defined in CDS view entity /DMO/E_Agency as an alias name for database table /DMO/AGENCY.

CDS view extensions can also define additional associations. Depending on the extensibility settings (see below), they can expose these associations or use them in path expressions in the element list.

In this example, the CDS view extension defines association _ZZTextZAG and adds it to the element list of CDS view entity /DMO/E_Agency.

Extensibility Control for CDS Entities

Extensibility control for CDS entities is very similar to the extensibility control for dictionary objects. Most of the annotations have a similar syntax and meaning. For a complete documentation, refer to the ABAP keyword documentation.

There are some minor differences though, as shown here:

  • The annotations start with @ABAPCatalog.extensibility. In CDS, they start with @ABAPCatalog.enhancement.
  • There is a simple true/false annotation to allow or disallow extensibility.
    Note

    The annotation AbapCatalog.viewEnhancementCategory specifies how a CDS view can be extended.

    AbapCatalog.viewEnhancementCategory and AbapCatalog.extensibility.extensible can optionally be specified together in the same CDS view. In this case, the annotation values must fit to each other. They must both either allow or forbid extensions.

  • It is not possible to distribute the quota share between customers and partners.
  • You can define an elementSuffix and not a fieldSuffix, because the element list of a CDS entity can consist of more than just fields. Exposed associations are an example.

The most important difference are subannotations allowNewDatasources and dataSources, which have no equivalent in the ABAP dictionary. With these annotations, the owner of a CDS view entity can control from where the extensions can read their data. If allowNewDatasources is set to true, the developer of an extension can read from any data source the original view reads from. If it is set to false, the developer of the extension can only read from the data sources that are listed under dataSources. This can be the direct data source(s) of the original view or the targets of its associations.

SAP often uses this to enforce the use of extension includes, which are a best practice for CDS view extensions.

Extension includes are a best practice for CDS view extensions. The name is a bit misleading because ABAP CDS does not support an include technique like the ABAP dictionary. What SAP uses instead are special CDS view entities, usually identifiable by the prefix "E_". The standard CDS view entity, for example, a view with prefix "R_", is defined with an association to such an E-view.

On the figure, the CDS view definition on the top left contains an association to the extension include view on the bottom left. Both CDS views are extendable, but to enforce the use of the E-view, the main view restricts extensibility to elements of the association to the E-view. The E-view on the other hand, allows extension with the elements of the main data source. As a consequence, extension developers, have to add new elements to the E-view first, before they can add them to the main view.

Let's have a look at an example.

This example illustrates how to extend CDS view entity /DMO/R_AgencyTP (on the top left) with the ZZCATEGORYZAG field from the database table /DMO/AGENCY.

It is not possible to do the extension directly, because CDS view entity /DMO/R_AgencyTP restricts the extension to association _Extension, which has CDS view entity /DMO/E_Agency as target (bottom left).

Therefore, in a first step, the developer extends /DMO/E_Agency (bottom right) and only then extends /DMO/R_AgencyTP addressing element ZZCategoryZAG through a path expression.

CDS View Extension Creation

Like CDS views, CDS view extensions are defined in CDS data definitions.

To define a CDS view extension, proceed as follows:

  1. In the project explorer, locate the data definition of the CDS entity that you want to extend.
  2. Right-click the data definition and choose New Data Definition.
  3. Adjust the package, enter a name and a description for the new object. Then choose Next.
    Note

    Usually, the data definition with the extension does not lie in the same package as the base object. Therefore, it is important to adjust the suggested package.

  4. Enter a transport request and choose Next.
  5. From the list of templates, choose Extend View Entity and choose Finish.

    There is also an Extend View template. It belongs to an older generation of CDS views. Only use this template when you have to extend a view that is defined with define view and not with define view entity.

Metadata Extensions

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.

Metadata Extension Creation

CDS metadata extensions are development objects of their own. They are not defined in CDS data definitions.

To define a CDS metadata extension, proceed as follows:

  1. In the project explorer, locate the data definition of the CDS entity that you want to extend.
  2. Right-click the data definition and choose New Metadata Extension.
  3. Adjust the package if necessary, and enter a name and a description for the new object. Then choose Next.
  4. Enter a transport request and choose Next.
  5. From the list of templates, choose Annotate View and chooseFinish.
    Note

    There is also a template Annotate Entity. This template uses keyword ANNOTATE ENTITY rather than ANNOTATE VIEW. ANNOTATE ENTITY can be used for any kind of CDS entity, but the set of available annotations is smaller. We recommend that you use ANNOTATE VIEW when you create your metadata extension for a CDS view and not for one of the other CDS objects.

Log in to track your progress & complete quizzes