Skip to Content

ABAP News for 7.40, SP08 – ABAP Core Data Services (CDS)


With ABAP 7.40, SP05 the ABAP Core Data Services, short ABAP CDS,  were introduced. The ABAP Core Data Services implement the general CDS concept of SAP (that is also available for HANA as HANA CDS) for AS ABAP. They use a DDL to define CDS views that implement a semantic data model in the ABAP Dictionary.

The power of ABAP CDS is, that it is open, meaning database independent (with some exceptions if the databases do not yet cover all the functionalities as e.g. views with parameters). You can use the DDL of ABAP CDS in Eclipse based ADT to create rather complex views that exceed the capabilities of the classical database views created in SE11 by far. Technically, from the source code of a CDS view, a classical database view is generated. We call this the CDS database view. You can display the fields of this view in SE11 but not change them. Especially, you can see the real database object – the SQL view – that is created from the view definition on the database in SE11. But this CDS database view serves mainly the internal technical purpose to realize the view in the dictionary. You can, but you should not use it in ABAP programs. Instead, you work with the CDS entitiy, whose name is defined behind DEFINE VIEW. Only the entity carries the full capabilities of the CDS view, like semantical information, client handling, connection to authority checks (planned), and so on. You can use the CDS entity behind TYPE for declaring work areas and in Open SQL in ABAP programs.

You use these views for the famous code push down in order to put more analytic work to the database. If the functionality of a view is only needed once, of course you can still use Joins, SQL expressions, subqueries, … in Open SQL for this code push down. But if you want to reuse a view, need semantical or technical capabilities of CDS that exceed those of Open SQL (but we try to keep the technical capabilities on the same level, e.g., CDS knows UNION, Open SQL will know UNION with an upcoming release) or you just want to push down the full data model to the database, you use CDS. And in fact I’ve seen very, very extensive sophisticated views already now (oh boy …).

But I’m a simple mind, not a business modelling guru. In order to understand the basics, I work with simple examples. Just to give you two of those:

@AbapCatalog.sqlViewName: ‘DEMO_CDS_JOIN’

define view demo_cds_scarr_spfli

  (id, carrier, flight, departure, destination)

  as select from spfli

            join scarr on scarr.carrid = spfli.carrid

     { key spfli.carrid,

       key scarr.carrname,

       key spfli.connid,


       spfli.cityto }

This is a simple join as you could also define it in classical SE11. The name of the CDS entity is demo_cds_scarr_spfli and the name of the generated CDS database view is DEMO_CDS_JOIN. One difference to a classical view is the fact, that a CDS entity that uses client dependent data sources is client dependent by default but never has a client field. The client handling is done implicitly without shining through here.

Another view, that does exactly the same as the above one but shows a new kind of modelling capability:

@AbapCatalog.sqlViewName: ‘DEMO_CDS_ASSOC’

define view demo_cds_association

  (id, carrier, flight, departure, destination )

  as select from spfli

            association [1..1] to scarr as spfli_scarr

              on $projection.carrid = spfli_scarr.carrid

     { key spfli.carrid,

       key spfli_scarr.carrname,

       key spfli.connid,


       spfli.cityto }

The join is replaced by an association, which is a more elegant way to code reusable joins. Associations can be adressed inside the view using path expressions (spfli_scarr.carrname is the most simple one) and can be published (not shown here) for usage in other views and in Open SQL (planned for SP12).

In an ABAP program you can read the views with Open SQL:

       FROM demo_cds_association
       ORDER BY id, carrier, flight
       INTO TABLE @DATA(result1).

       FROM demo_cds_scarr_spfli
       ORDER BY id, carrier, flight
       INTO TABLE @DATA(result2).

ASSERT result1 = result2.

To find out more, see the CDS documentation (it contains an authorization concept already, but the release of that was postponed to SP12).

After this recap, now the most important

News for CDS with 7.40, SP08

Besides many smaller enhancements, the most important news are:

Many new built-in functions

Besides the function already introduced with SP05, you can use standard functions as COALESCE, CONCAT, REPLACE, ABS, DIV, DIVISION, FLOOR, MOD and ROUND now and as in Open SQL the searched CASE was introduced.

Special functions  CURRENCY_CONVERSION, UNIT_CONVERSION und DECIMAL_SHIFT allow you to deal with data of the (in)famous SAP specific dictionary types CURR, CUKY, QUAN and UNIT.

@AbapCatalog.sqlViewName: ‘DEMO_CDS_CRRCNV’

  define view demo_cds_currency_conversion

   with parameters to_currency:abap.cuky(5),


   as select from demo_prices

   { id,

     currency_conversion( amount => amount,

                          source_currency => currency,

                          round => ‘X’,

                          target_currency => :to_currency,

                          exchange_rate_date => :exc_date,

                          error_handling => ‘SET_TO_NULL’ ) as amount,

     :to_currency as currency }

Parameter views

On databases that support it (not all up to now, but SAP HANA does) you can add importing parameters to a view that can be used in the SELECT statement of the view and that can be supplied when using the view in Open SQL.

Example for such a view:

@AbapCatalog.sqlViewName: ‘DEMO_CDS_PARA’

define view demo_cds_parameters

  with parameters p_distance_l:S_DISTANCE,



  as select from spfli         

            { key carrid,

              key connid,




                  distid }

            where distid = :p_unit and

                           distance between :p_distance_l

                                        and :p_distance_o;

Usage in Open SQL:

IF cl_abap_dbfeatures=>use_features(


        requested_features =

          VALUE #( ( cl_abap_dbfeatures=>views_with_parameters ) ) ).


         FROM demo_cds_parameters( p_distance_l = @from_distance,

                                   p_distance_o = @to_distance,

                                   p_unit       = @unit )

         ORDER BY carrid, connid

         INTO TABLE @DATA(result).

      cl_demo_output=>display( result ).



    ‘Database system does not support views with parameters’ ).


Extending views

Classical views delivered by SAP or partners can be extended with the well known clasical append views. In order to achieve the same for CDS views a new DDL statement is introduced:

@AbapCatalog.sqlViewAppendName: ‘DEMO_CDS_EXTENS’

extend view demo_cds_original_view with demo_cds_view_extension

  { spfli.distance,

    spfli.distid as unit };

It adds new fields to the existing view fields. Technically, a classical append view – its name defined behind the annotation @AbapCatalog.sqlViewAppendName – is generated in the ABAP Dictionary for that purpose.

You must be Logged on to comment or reply to a post.
  • In regard to parameter transactions, up until now if we define a view in SE11 which joins, say, VBAK and VBAP and call the view ZV_SALES_ORDERS.

    We could then write the following:-

    SELECT *

      FROM zv_sales_orders

      INTO lt_sales_orders

      WHERE werks EQ p_werks

      AND       erdat  IN  s_erdat.

    I take it you cannot do this with a CDS view ?

    Is this because it is not a "real" SE11 view?

    You have to do the trick with the parameters instead?

    Cheersy Cheers


    • You can pass parameters without any problem for the select statement.

      This is an example in 7.40 SP4 (so very limited functionality):

      CDS definition in Eclipse:


      Actually it can be displayed in SE11:


      And you can write SELECT with WHERE condition:



      • it is recommended to only use the CDS entity ZPI_TEST in Open SQL statements (instead of the CDS database view ZPI_TEST_CDS).

        In your simple case, the only difference is that the CDS entity does not have a MANDT field; you can select with WHERE conditions directly on the CDS entity ZPI_TEST.


        Jacques Nomssi

        • Hi Jacques,

          Thanks for the info.

          Do you mean "SELECT * FROM zpi_test ...." statement?

          In our system (only SP4) it doesn't seem to work.



          • Hi Peter,

            I am on SP05 and the following works:


            @AbapCatalog.sqlViewName: 'Y_CDS_PO_DATA'

            define view y_po_view

            as select from ekko as po

                inner join ekpo as item

                on po.ebeln = item.ebeln

                left outer join lfa1 as vendor

                  on po.lifnr = vendor.lifnr

            { key po.ebeln as ebeln,

              key item.ebelp as ebelp,

              po.bukrs as bukrs,

              po.bstyp as bstyp,

              vendor.name1 as vendor_name



            REPORT y_cds_consumption.

            DATA gs_sel TYPE ekko.

            SELECT-OPTIONS so_bstyp FOR gs_sel-bstyp.

            DATA lt_result TYPE STANDARD TABLE OF y_po_view WITH NON-UNIQUE key ebeln.

               SELECT * UP TO 100 ROWS

                 FROM y_po_view

                 INTO TABLE @lt_result

                 WHERE bstyp in @so_bstyp.

               cl_demo_output=>display_data( lt_result ).

            DATA lt_data TYPE STANDARD TABLE OF y_cds_po_data WITH NON-UNIQUE key ebeln.

               SELECT * UP TO 100 ROWS

                 FROM Y_CDS_PO_DATA

                 INTO TABLE @lt_data

                 WHERE bstyp in @so_bstyp.

               cl_demo_output=>display_data( lt_data ).

            best regards,


          • Hi JNN,

            Thanks a lot for the detailed answer.

            Probable testing in SP04 is not a good idea, I should somehow get to SP05 or even better to SP08,



          • CDS for ABAP was released with SP05. Before it was an undocumented pre-release for SAP-internal use only. And yes, no access to the CDS entities before SP05. As of SP05 this access is possible and the generated database views visible in SE11 are regarded as internal technical necessities but shouldn´t be used in Open SQL.

            A mixing of CDS entities with classical SE11 databases and views in one Open SQL statement will be possible in an upcoming SP and the usage of the CDS DB views in Open SQL will be declared as obsolete.

            Pls see the comprehensive explanation here:


    • I´ve chosen a simple example.

      You can use the parameters at many operand positions in CDS view definitions, not only behind WHERE. E.g., you can pass parameters to functions of the view in order to control their behavior.

      In fact, I´ve shown that in the currency conversion example above ...

  • And whilst I am asking questions.....

    A CDS view is written in "DDL" (data defintion lanaguage)

    whilst a stored procedure is written in SQLScript?

    Have I got that correct?

    They look a bit the same, but I presume that SQLSCript has a much greater depth of functionality available than something written in DDL?

    Cheersy Cheers


    • Hello Paul,

      1) you can restrict the selection from a CDS view with additional conditions in the WHERE conditions (I tested this on SP05).

      2) you should be able to use both parameters and WHERE conditions in a HANA system with SP08  (I have not tested this).

      3) CDS is database indepedent. My understanding is that you should be able to do:

        - DDL (Data Definition)

        - QL (Query)

        - DML (Data Manipulation)

        - DCL (Authorization)

      on any supported database in the same way, with the aim is to eventually cover the SQL-92 functionality. (cf. opensap course ABAP on HANA slides)

      4) AMDB is stored in the language of the database. Currently only HANA DB is supported, i.e. the language is SQLScript or the SAP internal L language.

      So in my view it is native SQL, but with a much better ABAP integration:

      - it is in your transport request

      - you just call an ABAP method (with VALUE parameters)

      Special Disclaimer: I am not Horst Keller, so I might be wrong on all counts.



      • First off, thanks very much for responding.

        I had hoped that you could use WHERE conditions when referring to a CDS view. My undertanding is that a CDS view has two faces - the name that appears in SE11 which is the SQL view, and the "entity" name which is the one you are supposed to use in your SELECT statements in your ABAP programs.

        It would seem logical that when referring to the SQL view you could use extra WHERE coditions, but in all the examples I have thus far seen, when referring to the "entity" in an ABAP SELECT no parameters are even supplied.

        If you can in fact use WHERE conditions when referring to the "entity" (sounds like an alien monsters) or a mixture of WHERE conditions and parameters, then I am finding it difficult to work out the reason for the parameters in the first place - why not just use more WHERE conditions? Could this be something to with referring to a CDS view within a stored procedure or something? I am just guessing.

        In a presentation by Rich Heilman from SAP he seemd to imply that the CDS view was the DDL subset of SQLSCRIPT (which might explain why you create an artifact called  a "DDL" from the ABAP in Eclipse when creating a CDS view) but I may have totally misunderstood. Again, in all the examples I have seen of CDS views they look like one big SQL statement, albeit with tons of fancy features. And Horst seems to imply that one day the new extended Open SQL capabilities in ABAP will catch up with wat is possible in a CDS view, which would seem to make it redundant in the long term. Again, I have probably got all this wrong.

        Now, moving on to ADMP, I thought the only language possible was SQLSCRIPT at this time but you mention also the internal SAP "L" language.

        On reading this I thought "what the L?"

        Is this just a language SAP use in-house?

    • Hi Paul,

      Most of your questions are answered by JNN and Peter.

      To summarize:

      • CDS views are entities of the ABAP CDS in the ABAP Dictionary that are much more advanced than the classical SE11 views. E.g., you can influence CDS views with parameters that can be used at different positions of the DCL. As for classical SE11 views, for a CDS view a platform dependent runtime object is generated at the database that you can examine in SE11. When accessing a (CDS) view with Open SQL, the database interface accesses this runtime object. As always ST05 can be used to analyze such accesses further. A CDS view is created with a source code based editor in Eclipse using a DDL (that has nothing to do with SQLScript). For technical reasons, from the source code a classical DB view is generated in SE11 that you can access like any classical view, but you shouldn't. Instead the so called CDS entity should be accessed because it carries more meaning than the mere technical DB view and involves new kind of client handling. In an upcoming release the direct acces to the DB view of a CDS view will be declared as obsolet.

        You use CDS to model large parts of your application in the Dictionary and use simple Open SQL SELECTs in ABAP for read access instead of having to create the respective  joins and subqueries in each ABAP program over and over again. One day Open SQL might have the same power like CDS but it doesn't mean that those are redundant. Already before CDS you had the choice between creating a reusable view in SE11 or programming a join in Open SQL. As a rule of thumb you created a view if it is used in more than one program and programmed a join when you needed it only once. That is very similar for CDS, but with much more possibilities for modeling semantically rich models for reuse in ABAP programs.

        CDS is mainly open. It is not restricted to HANA (but performance can be different!).

      • AMDP is simply a frame work that facilitates the handling of Native DB procedures. Up to now only DB procedures of HANA written in SQLScript are supported (the low level language L is for SAP-internal use only; parts of SQLScript are implemented in L). Other platforms might follow.

        Have a look at my From ADBC to AMDP example, that shows the evolution. From generating a DB procedure yourself wih ADBC over calling it with CALL DATABASE PROCEDURE we finally can generate and call it purely in ABAP. Of course, the functionality of that example is nonsense, because you can do the same with the same or even better performance in Open SQL. Another example is more realistic in showing how a SQLScript currency conversion function is used on the database instead of calling an ABAP function module. It is clear, that working directly on the database should perform better here.



      • thanks to Horst Keller, documentalist extraordinaire!

        and some questions πŸ™‚

        1) Will CDS view with parameter be supported on all certified DB soon?

        I mean, checking the underlying database for available features is idiosyncratic for custom developments.

        2) Should I expect a change in performance while fetching data from a base CDS entity when I

        a) consume the base CDS entity in an ABAP SELECT statement with WHERE clause, compared to when I

        b) extend the CDS entity with a WHERE restriction and then consume the extended CDS entity without WHERE clause.

        best regards,


        • 1) The database colleagues are working on it and it seems that with the next major release 7.40, SP12 all database systems will support parameter views.

          2) I do not expect different performance. I expect the database systems do carry out the same SELECT in both cases.

  • OK, from the replies that Jacques and Peter have been kind enough to share it looks like - in the higher levels of 740 - we can address the "entity" (view name) with  not only variables in the WHERE parameter, but in SP08 view parameters as well.

    The question I still have is why do we need both? SAP would not have introduced parameters to CDS views as a joke (I hope) so there must be some sort of use case for them which cannot be acheived by the normal WHERE parameters in ABAP.

    My guess remains that this is something to fo with using a CDS view in a stored procedure.

    Also I am still wondering about this "L" language.....

    • Even before CDS you had the possibility to add conditions to the view in SE11 (Selection Conditions tab) or do it via ABAP WHERE condition in the SELECT statement, so it doesn't really bother me.

      CDS views are also used for naive HANA development, this could be also a reason why parameters are added.

      Guidelines would be good, which case to use them as in CDS or which case outside the CDS.

    • >Also I am still wondering about this "L" language.....

      It's mentioned in the "ABAP Development for SAP HANA" book.

      Once it's mentioned that it's for SAP internal use only (just like Language R).

      Somewhere it's mentioned that it's an intermediate representation for translating SQLScript into C++ language.

      • Hi Peter,

        information about L and even a code sample can be found in the AMDB section of the online help (Thanks Horst Keller).

        OTOH the R environment is a powerfull suite for data manipulation and display. It is a free GNU project not related to SAP. I understand you can install an R server on a linux machine and connect it to a HANA system.

        My understanding is that the DDL part of CDS (Views) will completely replace the definition of views in SE11. You can extend views (Append), create associations (joins on demand) and use expressions, so I can imagine a use case where the parameter is not part of the projection list, so you cannot pass it as a WHERE condition.

        best regards,


        • So, when you define a CDS view you start off with a list of the fields for export, which matches the list of fields you would define on the left hand side of an SE11 view.

          Thereafter these fields are available for use in WHERE condtiions after a SELECT statmement against the "view entity".

          If you declared a parameter that was NOT in that list, then that parameter could be used somehow inside the "code" of the CDS view in a way that a value passed in via a WHERE clause could not?

          If so, could you be kind enought to give some sort of example, even if this is not actually possible at the moment in the current level of HANA?

          • from the ABAP on HANA online course (Week 03, Filtered Association):

            1) normalized view of the EPM text table

            @AbapCatalog.sqlViewName: 'ZDDLS_CDS_33A'

            define view zcdsv_adv_filter_example_base

            as select from snwd_texts


            parent_key as product_text_guid,




            2) Association between the product table and the text information encoded in first view

            @AbapCatalog.sqlViewName: 'ZDDLS_CDS_33B'

            define view zcdsv_adv_filter_example_l1

            as select from snwd_pd as pd

            association [1..*] to zcdsv_adv_filter_example_base as texts

            on texts.product_text_guid = $projection.text_guid


            key pd.product_id,

            pd.desc_guid as text_guid,



            3) consume the association texts exposed in second view, filtering the language to the given input parameter value or a default value

            @AbapCatalog.sqlViewName: 'ZDDLS_CDS_33C'

            define view zcdsv_adv_filter_example_l2

            with parameters lang : abap.lang

            as select from zcdsv_adv_filter_example_l1 as product


            $parameters.lang as langu_filter_param,

            coalesce (

            product.texts[1: language = $parameters.lang ].text,

            product.texts[1: language = 'E' ].text

            ) as product_description


            The following is untested, but I assume the consumption of the 3rd view could look like

            SELECT * FROM zcdsv_adv_filter_example_l2( lang = p_langu )

               WHERE product_id IN so_prod

               INTO TABLE @DATA(lt_result)

            where P_LANGU and SO_PROD could be selection screen parameter / select-options.

          • As I suspected, the parameter gets passed into some sort of fucntion, which naturally cannot be the case with a value in a WHERE clause.

            You say this is a standard SAP example - it has to be said they are struggling to find a practical use for this, examples should really be along the lines of

            1. Here is how we do it now

            2. Here is a new way to do it

            3. The new way is better because of XYZ

            The SAP language example does not cut the mustard as you can pass in SY-LANGU in a WHERE clause.

            If the example is trying to do something more than just pass back the product description twice then maybe I am barking up the wrong tree.

          • For each selected product the example should return a single product description in the desired language if maintained, otherwise the product description in the default language english.

            Since SP08 you can use SQL expressions in the CDS view to implement logic that cannot be achieved with a mere WHERE clause. COALESCE( A, B ) returns A if not NULL, otherwise B.

            I guess we could use COALESCE( ) again on the result to return a Constant text if the description is not maintained in any language.

            This is IMO a very practical example. I can remember having to implement this logic for MARA - MAKT queries more than once. With this the ABAP logic is much simpler and Code Push Down is achieved.


  • If I understand correctly - I am a bit unsure, so please confirm - transporting of the CDS-object and the ABAP coding accessing it remain separate?

    What about the other way around, i.e. the possibility to utilize a classical ABAP dictionary object in HANA SQL?

    In my particular case I am working with an .hdbprocedure and would like to declare a table of a type already existing in the ABAP-dictionary. Is that possible?

    Great post BTW πŸ™‚

    • Hi,

      A CDS view as an ABAP program or any reposiory object is a normal transport object governed by the classical transport tools. Of course they are different objects but they can be transported together. Nothing has changed here compared to classical dictionary objects.  In fact, that´s one reason, why ABAP CDS is embedded in the ABAP Dictionary.

      Also the same as before. In Native SQL you cannot access the ABAP Dictionary as a meta data repository, but you should be able to access the runtime object generated from the dictionary definition on the database.


      • Horst,

        thank you for your answer and clarification.

        Unfortauntely it is not clear to me what you mean with "you should be able to access the runtime object generated from the dictionary definition on the database".

        Does it mean that local variables can be declared in the procedure based on e.g. the types of the procedure parameters? Would it thereby be possible to declare local table variable based of type BOOKINGS and CONFIRMATIONS in the example below?




            READS SQL DATA




        Thanx πŸ™‚

        • Hello,

          Database tables and database views defined in the ABAP Dictionary are created on the database in the database schema SAPsid. For this, native DDL statements are passed from AS ABAP to the database by the Database Interface (DBI).

          You can examine these objects using the database's tools and interfaces and you can use the programming language(s) of the database to access them. In case of SQLScript, please refer to the respective documentation (, how you can access the native views generated from an CDS source.

          But maybe it is a better idea to use AMDP in that case. When creating an AMDP method, in ABAP, you have direct access to the Dictionary types used in an CDS view and you can let the AMDP framework generate the actual database procedure for you.



          • Thanks for your answer Horst.

            please refer to the respective documentation (, how you can access the native views generated from an CDS source.

            I searched the guide for 'CDS' and 'native' but found nothing. Are you refering to ADBC?

            Also: I am not using AMDP because I have understood that from an AMDP generated procedures only other AMDP generated procedures can be called (i.e. not stored procedures). This is one of the reasons why I am not going down the AMDP-route.

          • I searched the guide for 'CDS' and 'native' but found nothing.

            Of course. SQLScript is DB level. DB level is native from the ABAP point of view. DB level doesn't know anything about 'native' and CDS, since it is native itself so to say. You have to look up the artifact generated by the AS ABAP in HANA studio and find out, how to handle it with DB means if you really want to do so. But this is not a question to ABAP.

            I have understood that from an AMDP generated procedures only other AMDP generated procedures can be called (i.e. not stored procedures).

            Who told you so? An AMDP procedure can call other DB procedures.

            • When calling another AMDP procedure, the latter must be listed behind USING.
            • When calling a native DB procedure of the same DB schema, it must be in the name space /1BCAMDP/ (see example). But his should be restricted to temporary procedures.
            • There are no syntactical restrictions in calling native DB procedures of other DB schemas. But of course, you have to take care yourself, that the procedures are available in any system and that's why it should be done in exceptional cases only.

            So the questions remains, why you want to access ABAP features from DB level at all and why you do not want to use a supporting framework (AMDP) for doing so.

          • Thanks for your many answers to my questions.

            The scenario I am struggling with is: I have several BW-DSO tables (ABAP generated artifacts, right?) whose content I need to manipulate by AFL/PAL functions (thru calls to catalog procedures).

            There are various of these procedures requiring different combinations of input and output parameters (always at least an IN and an OUT table).

            The reason behind my questions is that I am searching for a solution where I can avoid defining the structure of the DSO-tables manually on a DB level. Why? Double work AND if the DSOs changes their structure in BW (ABAP AS) somebody must remeber to make the change also on a DB level.

            Initially I tried AMDP, but found it a bit limited for the reasons you mentioned above AND the fact that the syntax seems to be restricted vis-a-vis normal procedures (e.g. no local temporary tables permitted and other restrictions). This was the reason that I have been looking for an alternative by using stored procedures (thru BW's HANA Analysis Process) from which the idea was to call the AFL/PAL procedures.

            I will take a look at the simplest option: user-exit logic in BW transformation with loop over an ITAB inside which I first prepare the data and then execute calls to the AFL/PAL functions (which are located in another schema) by means of AMDP. As you state this should be done only in exceptional cases (I normally try to avoid those), but in my case it seems as if it could be the 'right thing' to do.

            Thanks again for your assistance.

  • I'm currently playing with the association example of the ABAP Keyword Documentation and getting a warning "Association & can influence the cardinality of the resulting set". This also happens in all of my own examples.


    Do you know what this warning means and how to prevent it?

    (I'm on 7.40 SP9)

    • The purpose of such warnings in CDS source code is to point out properties of a view that might be unexpected for the programmer. Warnings can come either from the syntax but also from the ABAP Dictionary, where the respective database view is generated. An example for the latter would be "all fields are key fields". Unfortunately up to now, there is no way to hide such warnings (no CDS pragmas yet) but the problem is known and work is in progress.

  • Hi,

    I have created a simple ABAP CDS view, using one input parameter for date. But I need to use it in 2 different places in the 'where' condition. But I am getting this error.

    Can anyone help here please?


  • Hi everyone,

    I'm having cosmetic problems with my CDS-Views. I created them with EN as my default language; though I work for a german company in which everyone signs in using DE as default language.

    I provide the short description for my views using the following annotation:

    @EndUserText.label: '<Short Description>'

    When I try to look up my views in SE11 using F4-Help in DE-language, there are no short descriptions (due to them being written in English?), whereas when displaying the view in SE11, the short description is available.

    Do you have any idea on how to provide said F4-Help short descriptions in DE?



    • Hi,

      You shouldn't look up your views in SE11, at least not the semantical properties  ...

      The database views created from the CDS source code are merely "for technical" reasons. The CDS source code and the CDS entity defined there should be the "real thing".

      Nevertheless, the behavior should be improved in an upcoming release.


  • Hello,

    sadly I just fail to see the advantage of a "CDS view" when it comes to SAP HANA compared to an "informatioon view" in SAP HANA built with "SAP HANA Studio". Sure, if one only knew the SE11 Transaction to create a view...

    So what are the benefits of using "CDS views" in an SAP HANA environment compared to using the "SAP HANA Studio" for modeling and creating the views instead, please?

    • Dear colleague,

      The CDS concept is far more than simple view building but describes a DDL for building a meta model repository involving database tables, database views, functions, and data types.

      CDS was invented by SAP, because the modeling capabilities of  the ABAP Dictionary and of the "SAP HANA Studio" are not sufficient for the needs of all fully blown business applications with nowadays needs.

      With "HANA CDS", CDS is availbale for SAP HANA in the SAP HANA studio. With "ABAP CDS", the CDS concept is also made available for the AS ABAP, where the features of CDS surpass the modelling capabilities of SE11. ABAP CDS is open and not restricted to SAP HANA.

      See also CDS- One Concept Two Flavors.

      If you don't need a meta model as it can be build with CDS for your application, well, don't use it. Others seem to need it. Meanwhile there are 10,000s of CDS entities around in SAP S/4 HANA applications ...

  • Hello,

    I am (was) assuming that CDS could do all things I can in ABAP OPEN SQL, and more. But I am starting to doubt this ...

    In an ABAP program I can use this OPEN SQL:

    select *

    from tablex as a

    where a~field1 = ( select max( field1 ) from ... )

    In the DLLS/CDS it seems I am not able to use a subquery on the righthandside of the where-condition.

    In CDS I get these errors ...

    where a.field1 = ( select max( field1 ) from ... ) ==> Unexpected word (

    where a.field1 = select max( field1 ) from ... ==> Unexpected word SELECT

    Is this (still) a limitation of CDS, or am I doing something wrong?

    PS: I am working on 7.40 SP9



      • Wow Horst, very swift reply. Thanks!

        I encountered that docu-page but just couldn't believe subqueries would not be supported (yet). Anyway, something to look forward at.

        Thanks again.



        • I also do not find immediate 'proof' of subqueries in HANA CDS in the docu

          I do find the usage of subqueries in the SAP HANA SQL and System Views Reference (HANA Native SQL), on 2 places: Comparison Predicates and SELECT (scroll down to the WHERE clause)

          When reading Horst's CDS - One Concept, Two Flavors: << The DDL of CDS allows you to define database tables, database views, data types by wrapping the according native HANA SQL statements and enriching them with semantical properties. >>

          So in the end it think it should be possible to use subqueries in HANA CDS.

          I cannot verify this currently, as I am not into HANA CDS (yet ;-), but only into ABAP CDS



          • Well, well, I asked the HANA CDS colleagues ...

            No, subqueries are not yet supported in HANA CDS either.

            They are planned in an upcoming HANA SP (a fact that might raise the ambitions of the ABAP CDS colleagues 😈 ).

          • Horst, thanks for asking around.

            Getting proof/confirmation of things that are NOT possible is never easy.

            For me that always comes down to searching/scanning all things that ARE possible, and when not found, throw in the towel and admit/conclude it will (probably) not be possible.



    • When I was in SAP TECHED in Las Vegas in October 2015 there were lots of talks about CDS views, by Karl Kessler and many other speakers.

      More than one speaker indicated there seemed to be some sort of unofficial contest going between the team that were enhancing the Open SQL in ABAP so that it could reach the 1992 standard, and the team adding features to CDS views.

      It seems that if a new feature is added to a CDS view then the Open SQL guys will then try to not be outdone and add that to the next release of their functionality.

      I would imagine then that as a corollary if there is a feature in Open SQL that is not available in a CDS view as yet, the CDS team will do a tit for tat, and try and get that feature in their next release.

      This sort of healthy competition is good for everyone involved, and for us ABAP developers most of all!

      Cheersy Cheers


  • Hi very off the topic and sorry to every one because I have no intentions to interrupt the ongoing conversation but I am very curious to knoe waht will happen to the classical

    SAP ALV and dynpro stuffs in future, will they be deprecated or in future we shall see even more powerful ABAP dynpro capabilities.

    Please help address my question.



    • It is 100% off topic but I cannot stop myself replying.

      I cannot say for sure, but I would guess the last enhancement to the GUI based DYNPRO was round about 1999 and ever since 4.6 came out SAP have been trying to migrate us away from using this, with a notable lack of success, until UI5 came along.

      The ALV on the other hand keeps getting new features added e.g. the IDA SALV class designed to work with HANA and CDS views (whoo-hoo, I managed to get back on topic), so the ALV is in with the in crowd, and poor old DYNPRO is a dead parrot.

      Web Dynpro, IMHO, was dead on arrival, but in the very recent past SAP have strapped it to the operating table, shouted "CLEAR" and pumped ten billion volts through it in an attempt to bring it back to life, this time looking like UI5 rather than the uglier version of the GUI DYNPRO which it has been thus far.

      • Hi Paul, Thanks for the reply and sorry yes i was off the topic.

        I am taking a forced liking to the Fiori apps and the UX given it's the way forward but in my humble opinion dynpros are a killer tool, and very recently from 2011- 2014 i was involved in an implementation project where we had hundreds of complex dynpro screens and honestly i enjoyed writing those screens. May be my comments are because of my relative inexperience with fiori and ui5 in general but i find dynoros more suited to handle complex transactional needs of companies because not every business needs fancy fiori apps that have so many views and separate apps when i can do so much in any ecc system with classical dialog programming. With a little screen personas we made many classical transactions look cool without sacrificing the raw power.

        Thanks for your expert comment because that's how people like us get to learn  from your experiences rather than reinventing the wheel.



        • I like writing DYNPRO screens as well, but your exact question was along the lines of "are SAP adding new features to classical DYNPROS" and the answer is no they are not.

          Amazing as it may seem SAP has come under fire for many years for having a hideous user unfriendly user interface. They tried to address this with the wrongly named "enjoy" transactions back in the year 2000, and when it turned out no-one actually enjoyed these along came Web Dynpro which was even worse to look at.

          From a purely technical point of view the problem with DYNPROS is the business logic all being tied up with the UI logic, but no-one can doubt that you can do a lot with such technology a la VA01.

          It may be easy to disparage new things like UI5 as "fancy" but as the saying goes you need to use the right tool for the right job. On a desktop an SAP GUI type screen may be perfect, on a smart phone maybe twenty tabs with a hundred fields each might not work so well.

          Moving to UI5 is scary for a lot of people as it is outside of the "comfort zone" but, as someone somewhere once said "the sleeper must awake". The future is here whether we like it or not, and to be honest the learning curve for things like JavaScript is not actually that steep.

  • Hello Volker, Hello Paul

    I agree, even with my limited knowledge I tried to keep the business logic and presentation in separate classes in our design and then implement the calls accordingly, but that grows complex without native support like web dynpros and may be Paul being a purist won't call it a pure MVC stuff.

    But for me I have got the message loud and clear, can't keep treating UI5 as the step child πŸ˜† need to embrace it as that is our future and that is good for us the developers with long careers ahead of us and the company i.e. SAP because many great technological products like Nokia's Symbian failed not because of bad core technology rather it was miles ahead but the UI failed them and UI5 addresses that challenge for us in our SAP ecosystem.

    Paul thanks for entertaining my off the topic question.

    Thanks to all.



    • SAPUI5 is an intermediate solution - i believeΒ there will be support for native application floorplans to be downloaded as straight to the OS's of the corresponding devices. Each OS should have an application floor plan support, where you can download sets of the applications that plug into a floor plan pattern and the interfaces are very strict.

  • Hi Horst,

    Is it possible to create ABAP CDS views dynamically ?

    Like in HANA, we were able to create a procedure and we were creating SQL views (definitions) dynamically by passing the source and target schema to that procedure.

    So, can we achieve same kind of functionality in CDS views as well ?


    Say we are creating CDS in DDL with this code:

    @AbapCatalog.sqlViewName: 'ZV_ABAP_ZT96'

    @AbapCatalog.compiler.CompareFilter: true

    @AccessControl.authorizationCheck: #CHECK

    @EndUserText.label: 'DDL Source for ZT96 Table'

    define view ZDDL_ZT96 as select from zt96 {























    So, basically, even say we have generated this code dynamically by concatenating strings. How to execute that code ??

    Please do let me know.



    • It is not possible to create ABAP CDS Entities dynamically.

      For "dynamic view building" in ABAP you can use the dynamic FROM clause of Open SQL.


  • Hi Horst,

    Can I consume ABAP CDS view in ABAP Custom report via Secondary database connection?

    Thanks for your support on this topics.

  • Hi Horst,

    thanks very much for the detailed description. So far it was possible to create a CDS-View (which could be seen in se11) but after that how do we connect to this view with Lumira or Analysis for Office? We don't see our CDS-View, although there're a lot of Content views...

    Could you help?


    Tim Jaschik

    • Hi Tim,

      Basically a CDS-View is an entity that can be adressed by its name

      • in ABAP as a type
      • in Open SQL as a data source

      Seeing a CDS-View in SE11 is kind of a technical artifact and you should not address the database view that is shown there in your ABAP programs. From SE11 you can also navigate to the database object that is generated from the definition. This database object can even be accessed directly with Native SQL.

      This means you can access your CDS Views directly in ABAP programs or from elsewhere. For evaluating the semantic properties (annotations) of a CDS View (stored in system tables) one should use an appropriate API (CL_DD_DDL_ANNOTATION_SERVICE if available in your system).

      And that's as good as all from the technical foundation's point of view. Connecting to CDS Views with "Lumira" or "Analysis for Office" is a task of the corresponding framework. If you cannot access your  CDS views with frameworks that should do so, you must check with those.


      • Lumira is an SAP framework for data exploration and visualisation. At TECHED in Las Vegas in October 2015 one of the evening events was all about using Lumira to save the world. And they gave us free beer as well.

        In short SAP is pushing this really hard.They would not give out free beer otherwise.

        If Lumira does not recognise CDS views that is a serious communication failure between two groups within SAP.

        "Analysis for Office" is part of BW/BI (whatever it is called this week). Surely the SAP Business Warehouse must be able to recognise CDS views? If it does not that is even worse.

        Cheersy Cheers


        • If Lumira does not recognise CDS views that is a serious communication failure between two groups within SAP.

          I wouldn't say so. I'd rather say, if you want to access CDS views using a framework you have to check if it is possible in the framework and the framework's prerequisites. SAP Basis offers the ability to create CDS views , to annotate them, and to use them in an ABAP program. But how to annotate a view for usage in a framework and how to consume them by a framework is a question to the framework and must be looked up there.

          According to  What's new in SAP Lumira 1.30

          Lumira 1.30 supports connecting to SAP S4HANA. You can Acquire data from CDS Views via Transient BEX Queries on BW Analytic Engine

          If you work with Lumira 1.30 and your  CDS views don't show up automatically, I'd guess you have to use the appropriate functions of the framework and your views might also need some @Analytics or other annotations for that. But I'm not a framework expert. Those things ought to be described in the respective framework documentation.


  • You want him to send you a copy of his book for nothing, whereas everyone else has to buy it using money?

    If that works, can I please have a sports car, fifty bedroom mansion, private jet, private island why not, all for nothing please? Surely that is not too much to ask?

  • Hi Horst and other experts,

    I have a trivial doubt. Can someone explain to  the difference between an ABAP CDS view and a HANA CDS view, am not able to differentiate them  clearly. Will  be nice if someone can explain them with an example with screen  shots.

    Thanks in advance...! πŸ˜€

  • Hello Horst,

    I really really really love the possibility of finally creating some kind of "Data-Model" with help of CDS views which can easily be understood and re-used by other developers...

    But explicitly when creating such Data-Models via associating several views there is a huge downside:
    The Cycle-Problem (

    Unfortunately even in the CDS-Demos (Package SABAPDEMOS -> SABAP_DEMOS_CDS_FLIGHT -> DDLS S_AIRPORT & DDLS S_CONNECTIONS) there are a cycling associations - but when we try to transport such kind of CDS it fails..


    So what is the impact on development?

    Developers build several views, test them, everything works, they build an application on top of that, test it, everything works great, they try to transport it to Q -> FAIL!
    Now we have to rework the views, remove associations, move this temp-transport to Q without associations just to activate the CDS, but all other objects fail, then revert the changes, and only then we can move the final (hopefully working) version to Q again (so sad...)

    Is there any plan / possibility to overcome this - from my point of view HUGE - hurdle short or long-term?