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:
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.
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:
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:
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:
If you do nothing, MDEs are automatically considered:
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:
- 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:
- SAP Managed Tags:
7 Comments
| User | Count |
|---|---|
| 5 | |
| 5 | |
| 3 | |
| 3 | |
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 1 | |
| 1 |
