CDS view entities are feature complete, Part ll: Improvements

[AndreaUS]

Since ABAP release 7.88, SAP BTP ABAP Environment 2205, CDS view entities are feature complete. In this blog series, you find a complete list of new features, improvements, and differences of CDS view entities compared to CDS DDIC-based views.

Introduction and Overview

Part l: New features

Part ll: Improvements

Part lll: Differences

Part ll: Improvements

Learn about the improved design and architecture of CDS view entities.

1. No CDS-managed DDIC view created in ABAP Dictionary.
2. CDS view entities are generated as SQL views on the SAP HANA database.
3. Stricter syntax and semantic checks.
4. Automatic and implicit client handling.
5. Improved activation performance.
6. Currency and quantity handling in expressions.
7. Improved expression matrix.

1. No CDS-managed DDIC view created in ABAP Dictionary

For each CDS DDIC-based view, a CDS-managed DDIC view is created in ABAP Dictionary upon activation. The name of this CDS-managed DDIC view is defined using the annotation @AbapCatalog.sqlViewName: 'name'.

A CDS view entity does not have such a DDIC view attached and this entails the following advantages:

• Improved performance during activation.
• One object less which can become inconsistent.
• Simplified syntax. Only one name, not several names.

2. CDS view entities with input parameters are generated as SQL views on the SAP HANA database

CDS DDIC-based views with input parameters are created as table functions on the SAP HANA database. The reason is that table functions were the only artefacts that were able to deal with input parameters at the time when CDS views were first introduced.
However, table functions have a different scope than views, because inside a table function, you can write arbitrary SQL script, whereas in CDS views you can only define a SELECT statement.
By now, the SAP HANA database has extended SQL views so that they directly support input parameters. And CDS view entities make use of this. A CDS view entity, whether it has parameters or not, is always generated as SQL view on the database. ­­

3. Stricter syntax and semantic checks

In CDS view entities, stricter syntax and semantic checks have been implemented in many places where this is considered beneficial. Here are a few examples:

• Annotations must have a CDS annotation definition in a DDLA file. Otherwise, a syntax error occurs.

Example: In a CDS DDIC-based view, you may write @bla.bla: true as header annotation. Even if no annotation of name @bla.bla exists, no syntax check error occurs.

In a CDS view entity, by contrast, this is not possible. If you write an annotation which is not registered as DDLA file, a syntax check error occurs.

• In comparisons, stricter type compatibility checks apply.

Example: cast(111 as int1) = 256

This comparison is allowed in DDIC-based view, but not in a CDS view entity. 256 is not within the value range of data type INT1 and therefore, a syntax check error occurs in a CDS view entity.

• Prefixing: if a CDS view entity selects data from more than one data source by means of an explicit join, each single element in the SELECT list must have a source prefix. Otherwise, a syntax check error occurs. Each element must be uniquely identifiable to avoid later inconsistencies, for example in an extension scenario.

4. Automatic and implicit client handling

In CDS DDIC-based views, client handling can be configured via header annotations:

• ClientHanling.type
• ClientHandling.algorithm

In CDS view entities, these annotations are not supported. Client handling is handled completely internally in CDS view entities. If a view entity is client-dependent, the session variable $session.client is used to locally filter the client for this view. This reduces the complexity of client-handling and developers do not have to take care of it.
For further details, see ABAP Keyword Documentation on SAP Help Portal: ABAP CDS - Client Handling in CDS View Entities.

5. Faster activation performance

CDS view entities have a much faster activation performance than CDS DDIC-based views. The main reason is that they don’t have any DDIC view attached. Instead of two objects, there’s only one object to be activated.
The following table shows examples for CREATE and CHANGE scenarios:

• For a view stack of 10 or 20 views which are built on each other, activation time in a CREATE scenario is reduced to half.
• For a view stack of 10 or 20 views which are built on each other, activation time in a CHANGE scenario has been reduced by factor 0,7.

View Stack / Scenario	Activation time DDIC-based view	Activation Time CDS view entity
10 / CREATE VIEW Stack	20,19 s	10,61 s
20 / CREATE VIEW Stack	40,56 s	21,37 s
10 / CHANGE FIELD	32,68 s	22,11 s
20 / CHANGE FIELD	68,88 s	48,09 s

6. Currency and quantity handling in expressions

CDS DDIC-based views don’t have any special checks implemented for amounts and quantities in expressions. Amount fields and quantity fields can be combined in expressions without any restrictions, even if the result makes no sense.

CDS view entities do check for currency and quantity fields in expressions. The reference to a unit or currency key is taken into account in the handling of expressions, comparisons, functions, union views, intersect views, and case expressions.

Example

7€ + 13km would be possible in a CDS DDIC-based view, because there is no check for references. In a CDS view entity, a syntax check error occurs, because CDS view entities do check for references and this calculation does not make any sense.

The following matrix shows how amounts and quantities can be combined in arithmetic expressions in CDS view entities and the result type. Depending on the result, the respective reference annotation is required. ‘-‘ means that this combination is not valid and a syntax check error occurs.

operands / operators	/	*	+, -
amount, amount	calculated quantity	calculated quantity	amount
quantity, quantity	calculated quantity	calculated quantity	quantity
calculated quantity, amount	calculated quantity	calculated quantity	amount
amount, quantity	calculated quantity	calculated quantity	-
calculated quantity, number	calculated quantity	calculated quantity	-
calculated quantity, quantity	calculated quantity	calculated quantity	quantity
calculated quantity, calculated quantity	calculated quantity	calculated quantity	calculated quantity
amount, number	amount	amount	-
number, amount	calculated quantity	amount	-
quantity, number	quantity	quantity	-
number, quantity	calculated quantity	quantity	-

Two new functions support amount and quantity handling in expressions:

• GET_NUMERIC_VALUE returns the numeric value of a currency or quantity field without its currency or unit.
• CURR_TO_DECFLOAT_AMOUNT converts a currency field of data type CURR into a currency field of data type DECFLOAT34.

Hint: In CDS view entities, the annotations @Semantics.currencyCode and @Semantics.unitOfMeasure are not required and not supported.

For further details, see ABAP Keyword Documentation on SAP Help Portal: ABAP CDS - Amounts and Quantities.

7. Improved expression matrix

Operand positions of clauses, expressions, and built-in functions have been opened up, that means, they accept a broader range of elementary operands and expressions as input. Nesting of expressions within each other has been enhanced. The following CDS view entity provides some examples:

• Built-in function SUBSTRING:
  • Session variable allowed as first operand.
  • Parameter allowed as second operand.
  • Arithmetic expression allowed as third operand.

• Simple case expression: Cast expressions are allowed as first operand.
  • Arithmetic expressions are allowed as operand after WHEN.
• Searched case expression:
  • Another case expression is allowed as operand after WHEN.

• Join ON condition: a literal is allowed on the left side.
• Arithmetic expressions and case expressions are allowed as operands.
• WHERE clause: Parameters and typed literals allowed as operands.

@EndUserText.label: 'Extended expression matrix'
define view entity zas_v2_extended_expr_matrix
  with parameters
    @EndUserText.label: 'Parameter for dec test'
    p_abap_dec : abap.dec( 8, 2 )
  as select from demo_ddic_types  as a
    inner join   demo_expressions as b on 1 = 1
{
  key a.char1                                  as keyField,
      case cast( a.char1 as char3)
      when substring( cast( 'AA' as char2), 1, 2)  then 'text1'
      when substring( cast( 'BB' as char2), 1, 2)  then 'text2'
      else                                              'OtherText'
      end                                      as CaseExp,
      substring(  $session.user_timezone, $parameters.p_abap_int4,1*2)
                                               as func_session_timezone,
      case when a.int2 * 2 = case 500 when 7 then 1 end
      then 'x'
      else 'y'
      end                                      as Arith_on_lhs_of_case,
      case a.int2
      when 260 * 1 then 0
      else              a.int2
      end                                      as simple_case
}
where
      b.dec3 * 5             = case a.int4 when 500 then 0 else 1 end
  and $parameters.p_abap_dec = abap.d16n'123.45'

The view entity shown above provides some examples for the extended expression matrix, but there are many more combinations which are allowed in CDS view entities, but not in CDS DDIC-based views. For example, the HAVING clause and the ON condition of associations have also been opened up for more different types of operands.

Check the release news and the ABAP Keyword Documentation for further details.

Further information

• Migration: A new generation of CDS views: how to migrate your CDS views to CDS view entities | SAP Blogs
• A new generation of CDS views: CDS view entities | SAP Blogs
• ABAP Keyword Documentation: ABAP CDS – View Entities