Skip to Content
Author's profile photo Horst Keller

ABAP News for Release 7.51 – Meta Data Extensions in 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'  

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 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:

 

Assigned Tags

      6 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Krishnakumar Padinjhare Marath
      Krishnakumar Padinjhare Marath

      Thanks for the nice blog and explaining how the framework choose among various metadata extension layers.

      I wonder how to address SOC when a custom CDS view, created for a customer app with UI annotation to be used to make another different looking apps using Fiori elements. Both being at customer layer, which one the framework choose? Then the one of the option is to define another consumption view for second app?

      Author's profile photo Joachim Rees
      Joachim Rees

      Hey Horst,

      I think  my mind immediately created a similar question to Krishnakumar's (just on the #Partner Layer instead of #Customer)

       

      What if (staying in your example above) I buy another partner's addon, an it ships this:

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

       

      At what point will that be caught? When the 2nd addon is installed, maybe?

       

      best
      Joachim

      Author's profile photo Horst Keller
      Horst Keller
      Blog Post Author

      From the documentation:

      "If multiple CDS metadata extensions with none or the same CDS variant are assigned to the same layer, a syntax check warning is issued for annotations specified more than one, and the system uses the annotation of the first metadata extension found."

      So to say undefined. That's what the variants are for, alas, not yet shipped.

      Author's profile photo DurgaPrasanth vemula
      DurgaPrasanth vemula

      Hi Horst Keller,

      I am working on Extending the Fiori Element App "Manage Supplier Master Data" which was

      developed using ABAP CDS Views and in the Fiori App library they had provided extension in the

      Back-end For the ABAP CDS View "C_BusinessPartnerPurgOrg" and given Extension include in

      DDIC    structure   "INCL_EEW_LFM1" and I add new Custom Field and same field i am planning to

      use Extend View for the "C_BusinessPartnerPurgOrg" and I am getting error message "Annotation

      'Metadata.allowExtensions' missing in base view 'C_BusinessPartnerPurgOrg'"

      As in the Fiori Library they had provided to extend it but in the CDS View

      'C_BusinessPartnerPurgOrg'" does not have the Annotation "Metadata.allowExtensions:True" and

      then how we can proceed to do extension and could you please help me on this.

      @Metadata.layer: #PARTNER
      annotate view C_BusinessPartnerPurgOrg
      with
      {

      }

      Author's profile photo Olivier Souksamran
      Olivier Souksamran

      Dear Horst Keller

      DurgaPrasanth vemula is right, why is that parameter needed ? Why won’t you let every “Consumable” CDS view ready for metadata extension so we can drive standard Fiori Apps based on Fiori Elements by overriding standard annotations ?

      Moreover, why letting the default value to ‘true’ if the parameter is only set when explicitly present on the CDS view ?

      Appreciate any update on this topic. Thank you.

      Regards,

      Olivier

      Author's profile photo Fabian Gehring
      Fabian Gehring

      Hello Horst Keller

      I wanted to create a CDS View with Metadata Annotions but I can't create the statment

      @Metadata.allowExtenstions: true?

       

      Only the statement

      @Metadata.ignorePropagatedAnnotations: true

      is allowed.

       

      Can you help here?

      Best regards

      Fabian