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:
- 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.
- 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:
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?
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:
At what point will that be caught? When the 2nd addon is installed, maybe?
best
Joachim
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.
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
{
}
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
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