Application Development Blog Posts
Learn and share on deeper, cross technology development topics such as integration and connectivity, automation, cloud extensibility, developing at scale, and security.
cancel
Showing results for 
Search instead for 
Did you mean: 
AndreaUS
Product and Topic Expert
Product and Topic Expert

With ABAP release 7.55, a new type of CDS view is available: in official terminology, it's called CDS view entity. And it has come to replace the "classic" CDS DDIC-based views that have been around for years.


This blog post provides the following information:

  1. Motivation: why has SAP developed a new type of CDS view?
  2. Key differences between DDIC-based views and CDS view entities
  3. Outlook: transition from DDIC-based views to CDS view entities

Motivation: why has SAP developed a new type of CDS view?

A CDS DDIC-based view is defined using the statement DEFINE VIEW. This kind of CDS view was first released with release 7.40, SP05 and it was for many years the only available kind of CDS view.
Since release 7.55, CDS view entities are available. They are defined using the statement DEFINE VIEW ENTITY. They have evolved from CDS DDIC-based views, serve the same purpose and have the same structure as their predecessor. But they offer several advantages over the "classic" CDS DDIC-based views, such as the following:

  • No additional ABAP Dictionary view is created on activation.
  • Improved performance during view activation.
  • Optimization and simplification of syntax.
  • Stricter syntax checks indicate problematic situations more explicitly, for example, annotation checks.

Key differences between DDIC-based views and CDS view entities

CDS view entities are a new and improved version of CDS DDIC-based views. Although very similar, CDS view entities are easier to use, and offer many small improvements and enhanced features.
Here are some principal ways in which CDS view entities differ from CDS DDIC-based views:

  • There’s no DDIC view. The annotation @AbapCatalog.sqlViewName is not required and each view has only one name.

Please note that the name of the annotation is a bit misleading. Of course, a view entity has an SQL view on the database, but now the intermediate DDIC view is not needed any more.

  • Fewer annotations are required. For example, client handling takes place implicitly and doesn't require any development effort.
  • Overhauled buffer handling by means of CDS tuning objects offers more flexibility (see Buffering CDS View Entities | SAP Blogs for further details).
  • Overhauled extension concept with CDS view entity extends (EXTEND VIEW ENTITY) offers much faster activation performance, see ABAP Core Data Services: New syntax for extending CDS entities | SAP Blogs for further details.
  • Annotations are checked to ensure that only annotations defined as CDS objects in a CDS annotation definition can be used.
  • Expressions can be nested within each other. Situations that previously required a view stack can now be implemented within a single view.
  • Operand positions, such as the WHERE-clause, allow a greater variety of operands.
  • Some features that haven't been widely used are no longer supported in view entities. Here are some examples (but the list is not exhaustive):
    • In DDIC-based views it is possible to assign alternative element names to elements of a SELECT-list using a name list. CDS view entities don't support name lists.
    • The syntax SELECT * to select all elements from the data source is supported in CDS DDIC-based views, but not in CDS view entities.
    • Domain fixed values in front of literals cannot be defined in CDS view entities.

Additional features, such as typed literals to enhance type safety, and optimized buffer handling, are planned for future releases.
The following example compares a CDS DDIC-based view with a CDS view entity:

CDS DDIC-based viewCDS view entity

@AbapCatalog.sqlViewName: 'DEMO_CDS_JOIN'

@AbapCatalog.compiler.compareFilter: true

@ClientHandling.algorithm: #SESSION_VARIABLE

@AbapCatalog.preserveKey: true

@AccessControl.authorizationCheck: #NOT_ALLOWED 

define view demo_cds_scarr_spfli

  as select from spfli

    join scarr on scarr.carrid = spfli.carrid

{

  key spfli.carrid     as id,

  key scarr.carrname   as carrier,

  key spfli.connid     as flight,

        spfli.cityfrom as departure,

        spfli.cityto   as destination

}




.

.

.

.

@AccessControl.authorizationCheck: #NOT_ALLOWED

define view entity demo_cds_scarr_spfli_2

as select from spfli

      join scarr on scarr.carrid = spfli.carrid

    {

      key spfli.carrid      as id,

      key scarr.carrname    as carrier,

      key spfli.connid      as flight,

             spfli.cityfrom as departure,

             spfli.cityto   as destination

    }

Differences:

  • The view entity doesn't require the annotation @AbapCatalog.sqlViewName.
  • The view entity doesn't require the annotation @AbapCatalog.compiler.compareFilter: true, because the filter is implicitly and automatically compared.
  • The view entity doesn't require the annotation @ClientHandling.algorithm, since client handling takes place implicitly.
  • The view entity doesn't require the annotation @AbapCatalog.preserveKey: true, because there's no ABAP Dictionary view attached to a CDS view entity.
  • The view entity is defined using the statement DEFINE VIEW ENTITY.

For a comprehensive description of CDS view entities, refer to ABAP Keyword Documentation (F1 Help in SAP GUI and ADT).

Outlook: transition from CDS DDIC-based views to CDS view entities

Since ABAP Release 7.56, ABAP Platform 2021, it is possible to migrate existing DDIC-based views to CDS view entities. Details are described in the following blog post: A new generation of CDS views: how to migrate your CDS views to CDS view entities. Migration is voluntary and can be done to benefit from the enhanced functionality of CDS view entities. "Classic" CDS DDIC-based views are supported, but not further developed. For new development scenarios, it is recommended to create only CDS view entities.
Info: SAP will continue to support classic CDS DDIC-based views. CDS DDIC-based views will not be retired, and customers will not be forced to use CDS view entities. SAP protects investments.

Update May 2022: Since ABAP release 7.88, CDS view entities are feature complete. An overview of all new features, improvements, and differences is provided in the blog series CDS view entities are feature complete. Overview of new features, improvements, and differences | SA....

Further information:

 

83 Comments
AndreaUS
Product and Topic Expert
Product and Topic Expert
nagaraju20
Discoverer
0 Kudos
HI Andera,

 

I  am getting below while working CDS view entity

DDL soucrce could not be saved .....what i have to do please confirm
0 Kudos
Hi Kathi,

Do you get this error in ADT? It might be efficient, if you can open a ticket/case on component BC-DWB-DIC.

Thanks and Regards,
Harish Mehta
AndreaUS
Product and Topic Expert
Product and Topic Expert
0 Kudos
Hi,

could you please provide more details? Could you provide your source code? Which ABAP release are you working on?

Might be wrong syntax.

If it's a bug, you might open an incident on component BC-DWB-DIC.

BR
nagaraju20
Discoverer
0 Kudos
@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'Define View entity'
@Metadata.ignorePropagatedAnnotations: true
@ObjectModel.usageType:{
serviceQuality: #X,
sizeCategory: #S,
dataClass: #MIXED
}
define view entity ZDDLS_SAMPLE_04
as select from vbak {
key vbeln as so,
kunnr as cust

}
nagaraju20
Discoverer
0 Kudos
This  is my sample code

AndreaUS
Product and Topic Expert
Product and Topic Expert
0 Kudos
Do you see any syntax error?

If not directly in your editor, check the Problems view.

 

I created the same DDL in my development IDE and I could activate it without any issues. Three warning messages, but they do not prevent activation.


 

If there's no error message, maybe try from scratch. Create a new data definition and type the source code.

Or check the release version of your system, maybe your system does not support view entities.

The source code is fine and there shouldn't be any error.
AndreaUS
Product and Topic Expert
Product and Topic Expert
0 Kudos
Hover over the red x in line 10. Do you get any details?

 

Maybe this name is unique, maybe there exists another DDL of the same name.

Maybe DDLS name is different from entity name. This is not allowed in view entities.
AndreaUS
Product and Topic Expert
Product and Topic Expert
Since the word "entity" is not marked as syntax, it might be that you work on a SAP_BASIS release <7.55 and view entities are not supported yet.
AndreaUS
Product and Topic Expert
Product and Topic Expert

mef

sebastien.phan

Dependency Analyzer for CDS view entities has been released with ABAP Platform Strict 2208 | ABAP release 7.89. It will be most likely available with the next big on premise shipment 7.57, ABAP Platform 2022.

freder1k_han
Explorer
0 Kudos
Hi aschlott

Thank you for a great blog. We are in the process of soon upgrading to S4 (the newest version availalbe). Do I understand correctly that all standard content deliveried by SAP has been converted CDS View Entities in the newer versions so that there is no more old DDIC standard content left?
AndreaUS
Product and Topic Expert
Product and Topic Expert
0 Kudos
Hi tjsacjszaddv

No, SAP standard content has not yet been converted completely to CDS view entities.

SAP has started migration and has already migrated about 2000 CDS views to CDS view entities. However, most views  in S/4 are still classic CDS DDIC-based views. Full migration is still in planning, since it must be ensured that there are no incompatibilities and upgrade issues after migration.

For new developments, SAP uses CDS view entities and in some contexts , such as the ABAP RESTful Application Programming Model with strict mode, CDS view entities are enforced.

 
freder1k_han
Explorer
0 Kudos
Hi aschlott

Thanks a lot for your reply. Is there no issue using standard content based upon the DDIC type together with a custom view of type Entitiy? It seems a bit strange that we should use standard content based upon the old type and enhance with the new type. Is there no down side of combining the two types? Also do you advice we migrate the old standard content to the new type by our selves before using it?

 

Thanks!
AndreaUS
Product and Topic Expert
Product and Topic Expert
0 Kudos
Hi,

you can create a custom view of type Entity that selects from a DDIC type. No problem. All new features are available.

Please mind: When working with old CDS DDIC-based views, you should only access them with their entity name. Do not use the sqlViewName defined with the annotation @AbapCatalog.sqlViewNameFrom release 7.56 on, accessing the sqlView leads to a syntax check warning. Reason is that during a migration, the sqlView is deleted and all consumers will have error messages.

There's no need to migrate SAP-delivered content before using it. SAP checks all of its views and if there are no technical constraints, they will be migrated.

Do you mean "enhance" as in extend (EXTEND VIEW) or as wrap an old view with a new view? If you mean a new view as wrapper: just normal evolution of development technique in my opinion. SAP provides a new technique for data modeling, but must ensure downward compatibility as usual, since it is likely that some CDS-DDIC-based views will stay and not be migrated to the new view entities.

Hope this helps.
Sofidel
Explorer
0 Kudos
Hi,

why writing this simple Entity CDS:

@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Test Entity CDS'
define view entity ZENTITY_TEST as select from vbak
inner join vbap on vbap.vbeln = vbak.vbeln
{
key vbak.vbeln,
key vbap.posnr
}
where vbak.audat = $session.system_date

 

I receive these 2 following warnings?

Search help assignment for field 'posnr' is not inherited from base object

Search help assignment for field 'vbeln' is not inherited from base object

 

Thank you very much
AndreaUS
Product and Topic Expert
Product and Topic Expert

Hi,

in CDS view entities, value help assignment is not inherited from a base table field.

There are different types of value help assignments. You can check the assignment as follows: SE11 > table > ->Input help/Check -> Column Origin of Input help.

Both fields in your source code have Origin of Input help set to ‘Explicit search help interface to field’. In this case, the assignment is lost in a CDS view entity. Therefore, you have this warning message.

Solution to have value help for these fields: Assign the required search help to a data element and cast the fields to the data element.

For example:

CAST ( field AS data_element_with_f4 PRESERVING TYPE ) AS field

Hope this helps.

BR

shais
Participant
0 Kudos
What should be done in case of an explicit search help assignment with multiple fields?

Is there any alternative?
AndreaUS
Product and Topic Expert
Product and Topic Expert
If you can modify the database tables, you can change the search help assignment. You can assign a foreign key relation as check table to the fields. For these fields, a CDS view entity inherits the value help assignment and there's no warning message.

If it is a SAP-delivered database table and you cannot modify it, you need to handle each field separately. You should create and cast a data element with the same search help for each field as further attribute.
shais
Participant
0 Kudos
But there are cases in which the search help consists of several fields. e.g. WERKS (plant) + LGORT (storage location). Assignment of search help in LGORT (storage location) data element won't be sufficient because it won't take the plant into account.
pree
Explorer
Cast to data element for each field will not have multiple assignment as only one search help parameter can be mapped to a data element. This only gives an option to have value help for each cds view entity field. There are CDS value help annotations that might help for this case.
sepposassi
Member
0 Kudos
Hi,

I wonder why the CDS view entities are not included in the F4 list for the table-field of the SE16N  transaction.

The CDS views, on the other hand, are included in the F4 list for the same field.
AndreaUS
Product and Topic Expert
Product and Topic Expert
0 Kudos

Hi,

sorry, but does the transaction SE16N even exist? In which system?

I don’t understand the question.

shais
Participant
0 Kudos
SE16N is a SAP-standard transaction for general table display.

It was delivered only in ERP (ECC / S/4HANA) systems and isn't part of the ABAP platform / core.
Jakob_Mainka
Explorer
0 Kudos
Dear Andrea,

we have a Z-Field added to MARA, which has a Search-Help assigned via the Data-Element.

MARA-ZZ_PRODFAM, data-element ZZ_PRODFAM_D (with Search-Help ZSHLP_PRDFM_D)

Then we enhanced E_Product by ZX_E_Product to add the field there as well, and renamed it to ZZ_Productfamily, and ehanced I_Product by ZX_I_Product to get the field from the _ProductExt association. But when we now create a new CDS based on I_Product and add our field ZZ_ProductFamily we're getting the warning, that the search help was not inherited.

According to the Element-Info the field has the data-element ZZ_PRODFAM_D but only if we again cast it to the same data-element the warning disappears?

 
pree
Explorer
0 Kudos
Hi Seppo,

Can you create an internal ticket/customer case with the steps to reproduce to the component BC-DWB-DIC-F4?

 
pree
Explorer
0 Kudos
Hi Jakob,

When I tried to reproduce the scenario that you mentioned, I was not able to reproduce the warning in internal SAP system (UIA) and the search help was inherited for the field without any casting and warning.

Can you create an internal incident to search help component with details about the internal system in which you created Z CDS views and extends?

Thanks,

Preetha

 
glensimpson
Explorer
Hi Andrea

Is there any chance this will be backported to lower on-premise versions?
I rely heavily on the Dependency Analyzer for CDS views and the lack of this tool for view entities is a real barrier to adopting the newer view type.

Thanks
Glen
AndreaUS
Product and Topic Expert
Product and Topic Expert
0 Kudos
Hi,

thanks for your feedback. I have discussed this issue with my colleagues. Since a tooling backport is a huge effort, it is rather unlikely that Dependency Analyzer will be backported to 2021. And before 2021, view entities were still in development and more features were missing.

If I hear anything else, I will update this comment.
thomaskusch
Discoverer
0 Kudos

Hi togehter,

I want to do a selection on Hierachy nodes in a CDS View selecting data as in a BW/4HANA.

Is there any blog/solution on how to do this? E.g. to select one hierarchy node of a cost element group?

Until know I found only a solution for single members (with the below annotation) but not a whole node that gathers a group of accounts for example.

 

@AnalyticsDetails.query.onCharacteristicStructure: true

Thank you in advance!

 

Best regards

Thomas

 

 

sap_cohort
Active Contributor
0 Kudos
Hi Thomas, have you been able to make any progress on how to do the selection in a CDS View?
stefan_unnebrink
Employee
Employee
0 Kudos
Hello Thomas,

selecting a hierarchy node is only possible in analytical queries. These are CDS views with annotation Analytics.query:true or transient view entities with provider contract analytical_query.

Hierarchies nodes can't be addressed directly in CDS. You have to introduce a parameter with special annotations and use this parameter in the traditional way (e.g. costElement = $parameters.p_hierarchyNode). It can be used in the filter of the query (WHERE) or in a restricted measure (CASE WHEN ... THEN <measure> END AS).

With the following structured annotation @AnalyticsDetails.variable you can annotate a parameter such that it becomes a hierarchy node at query runtime:

  • selectionType: #HIERARCHY_NODE

  • referenceElement : ... // specify the element name for which the parameter should be used. In the above example it should be 'costElement'

  • multipleSelection: true // use this, if the parameter should represent multiple hierarchy nodes

  • mandatory: false  // use this, if also no hierarchy node at runtime should be possible (optional variable)

  • hierarchyBinding: [ ] // specify the hierarchy to which the nodes belong to


if you just use these annotations, then the user of the query gets at runtime a prompt into which he/she can enter hierarchy node(s) or select them via value help.

In addition you can specify a default value for the parameter or define a derivation such that at runtime a hierarchy node is available. in this case the parameter can be hidden with annotation @Consumption.hidden. For hidden variables the user doesn't get a prompt.

A single default hierarchy node can be specified with the structured annotation @AnalyticsDetails.variable.defaultHierarchyNode. Multiple default values are not possible.

With the structured annotation @Consumption.derivation.resultHierarchyNode you can specify a derivation which returns one or more hierarchy nodes. If it might return more than one hierarchy node, the parameter has to be enabled for multiple nodes (...multipleSelections:true).

Remarks:

  1. Annotation @AnalyticsDetails.variable was introduced with Release 2208. The predecessor of it for hierarchy node was the structured annotation @Consumption.hierarchyNodeSelection. All of the explained features are available with almost the same sub-annotations.

  2. When defining a filter with hierarchy node, you can use @Consumption.filter. All of the explained features are available with almost the same sub-annotations. With this an OData service can still be created - this means OData.publish: true is possible together with @Consummption.filter. While it is not possible together with @AnalyticsDetails.variable.

  3. There is a new way of assigning hierarchies to a dimension (>= Release 2308). If the new style is used, the hierarchy binding can't be specified with @AnalyticsDetails.variable.hierarchyBinding. Instead @AnalyticsDetails.variable.hierarchyAssociation has to be used.

  4. For details of all the mentioned annotations please check the documentation of annotations in help.sap.com




Example:





A nice example is the SAP delivered CDS analytical query C_FinStmntWthPrftCtrHierQuery. It shows how to used @Consumption.filter in combination with @Consumption.derivation for profitcenter.

@AnalyticsDetails.query.variableSequence: 10


@Consumption.filter: {


    selectionType: #HIERARCHY_NODE,


    multipleSelections: true,


    mandatory: false,


    hidden: true,


    hierarchyBinding : [ { type: #PARAMETER, value: 'P_ControllingArea' },


                                    { type: #PARAMETER, value: 'P_ProfitCenterHierarchy' } ]


 }



@Consumption.derivation : {


   lookupEntity: 'P_ProfitCenterHierRootNode',


   resultHierarchyNode: {


     nodeTypeElement: 'NodeFieldname' ,


     mapping:[ {hierarchyElement: 'ControllingArea', lookupElement: 'ControllingArea' } ,


                      {hierarchyElement: 'ProfitCenterHierarchy', lookupElement: 'ProfitCenterHierarchy' },


                      {hierarchyElement: 'HierarchyNode', lookupElement: 'HierarchyNode' } ]


   },


   binding:[ { targetElement: 'ControllingArea', type: #PARAMETER, value: 'P_ControllingArea' },


                  { targetElement: 'ProfitCenterHierarchy', type: #PARAMETER, value: 'P_ProfitCenterHierarchy' },


                   { targetElement: 'ValidityEndDate', type: #CONSTANT, value: '99991231' } ]


   }


@AnalyticsDetails.query.displayHierarchy: #FILTER


@AnalyticsDetails.query.axis: #ROWS


@AnalyticsDetails.query.display: #KEY_TEXT


@AnalyticsDetails.query.totals: #SHOW


key ProfitCenter,




The query is filtered by multiple hierarchy nodes which are selected from the lookup view P_ProfitCenterHierRootNode. The user doesn't get a prompt (hidden:true) and it might be that the lookup view doesn't return any data, therefore mandatory is set to false.

The hierarchy is specified with hierarchyBinding. It is the profitcenter hierarchy with first key field of the hierarchy directory determined by parameter P_ControllingArea and the second key field by  P_ProfitCenterHierarchy (see hierarchy directory view I_ProfitCenterHierarchy).

The hierarchy view in this example is I_ProfitCenterHierarchyNode. The results have to be records of that node. The mapping between the field names in the lookup up view and the hierarchy view is specified with Consumption.derivation.resultHierarchyNode.binding. In the field specified with Consupmtion.derivfation.resultHierarchyNode.nodeTypeElement contains a field name which points to the field which is filled.

 

 

 

 
This was particularly helpful to me while trying to run CDS Views using only SAP GUI and not ADT.
T-code SDDLAR. Thank you so much 🙂
I565544
Advisor
Advisor

Hi Andrea,

thanks for the detailed information, I learned a lot!

I have another question about authorization: If our CDS Views no longer have SQLView, how is authorization controlled?

For example, if a customer created a query using View Entity in S/4HAHA (private cloud) and then opens it in AfO (Analysis for Office), How to ensure that only people with the correct authorization can open the correct query in AfO?

Thanks a lot and looking forward to any feedback! 

 

Best regards,

Rundong