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.
- No CDS-managed DDIC view created in ABAP Dictionary.
- CDS view entities are generated as SQL views on the SAP HANA database.
- Stricter syntax and semantic checks.
- Automatic and implicit client handling.
- Improved activation performance.
- Currency and quantity handling in expressions.
- 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
- SAP Managed Tags:
8 Comments
