Goodbye CDS View, Hello CDS View Entity – Part 2
This article is the second part of a blog series. It focuses on optimizations and new features. The previous part one explained the differences of the CDS View Entity compared to the legacy CDS View.
1. Optimizations And Simplifications
1.1. Input Parameter Handling
For a legacy CDS View which uses input parameter, an intermediate artifact – a table function – had to be created in the background on the database. That’s because when CDS Views were first introduced, a table function was the only artefact for dealing with input parameters.
Downside of the table function is added complexity and reduced runtime optimization potential. Reason is that the scope is different: inside a table function native HANA SQL Script is used, while it’s simplified SQL within a CDS View.
CDS View Entities can handle input parameters out-of-the-box, so no need for an intermediate artifact or translations from one to another SQL dialect anymore.
1.2. Stricter Syntax Checks
The syntax within a CDS View Entity is much stricter, which is a good thing because it helps to avoid unintended issues. Examples:
- Previously any annotation could be added, even if it was wrongly defined or did not exist at all. Now a check makes sure that the annotation is valid to ensure the desired behavior.
- Previously type issues could occur e.g. when comparing the result of a CAST statement with a literal value. Now the syntax check recognizes such inconsistencies and throws an error.
//please note: 300 is outside the value range of data type INT1
//such comparison is valid in legacy CDS View but not in CDS View Entity
cast(1 as int1) = 3001.3. Currency And Unit Handling
In a legacy CDS View different currencies or units could be mixed-up because there was no proper check. As an example, 10€ + 5kg was a valid calculation, even though the result did not make any sense. A CDS View Entity will recognize the referenced currency or unit and allow only meaningful combinations. If such a mixed-up calculation shall be done on purpose, the new functions GET_NUMERIC_VALUE or CURR_TO_DECFLOAT_AMOUNT may used, to disassociate the value from the unit.
As another example, the calculation 6l / 100km is valid and results in 0,06. This quantity value can easily be assigned to a calculated unit (in this case l/km) via element annotation, see:
//quantity field and unit field in fuel consumption calculation
//assume MyConsumption=6l and MyBaseline=100km
‘l/km’ as MyUnit,
@Semantics.quantity.unitOfMeasure: ‘MyUnit’
MyConsumption/MyBaseline as MyQuantity
Please note: a calculated unit is not registered in check table T006. Instead, it is stored as new domain and data element DD_CDS_CALCULATED_UNIT. In analytical queries, the calculated unit is defined as virtual element.
1.4. Nested Expressions
A legacy CDS View has several technical limitations when it comes to nested expressions. One example is the often-required use case to combine different string functions. However, the following code leads to error “only literals, possibly positive integers allowed”:
//nested left() and instr() functions
left(profit_ctr,instr(profit_ctr,'_')) as left_4With a CDS View entity the code is perfectly valid, enabling much needed functionality.
Similar improvements were also made within the CAST expression, ON condition of joins or associations, WHERE clause and HAVING clause, so those allow a greater variety of operands now. Some examples:
//case with cast as first operand
case cast(char1_value as char3)
//substring with cast, parameter and calculation
when substring( cast( '00' as char2), $parameters.p_MyParam,1*2) then 'text1' end as MyCase,
...
//where with calculation and case expression
where field1 * 5 = case field2 when 500 then 0 else 1 endGone are the days where previously certain calculations required to build a View stack as a workaround or were not possible at all.
2. New Features
2.1. Typed Literals
A legacy CDS View has untyped literals with limited data types, while a CDS View Entity offers typed literals with almost all data types supported. This means it is now possible to set the data type right away when introducing a new field literal, see example:
//Legacy CDS View
'001' as field1, //sets type to NUMC(3) by default
cast('001' as abap.char(3)) as field2, //cast needed if CHAR(3) is desired
// CDS View Entity
abap.char'001' as field3, // same result as above with just one code line
abap.datn'20230101' as field4 // another example with a typed dateLess code is required and at the same time the performance may be improved, because the need for conversions is reduced. Another benefit of typed literals is that the compatibility of certain data types can be checked by the IDE, which ensures more type-safe handling.
2.2. Except and Intersect
When it comes to set operators, a legacy CDS View only offers UNION to merge different result sets. In addition to that, the CDS View Entity also offers the EXCEPT and INTERSECT set operators. EXCEPT returns the first result set minus the second result set. INTERSECT returns just the rows, which are part of both result sets.
2.3. REPLACE_REGEXPR
A frequent requirement is to adjust strings. CDS View Entities offer the new function REPLACE_REGEXPR, which replaces a string pattern within a text with another string.
//In this example all upper case characters are replaced with blank
replace_regexpr( pcre => '[A-Z]', //perl compatible regular expression
value => '1A2b3C', //input value
with => '', //substitute
result_length => 4 ) as MyAdjustedString2.4. $PROJECTION
Within a CDS View Entity the syntax $PROJECTION.element can be leveraged to reuse an expression which was defined earlier as one of the select elements. Example:
//In this example a field and an expression are reused.
select from MyTable
{
username as field1,
cast(‘hello ’ as abap.char(6)) as field2,
concat($projection.field2, $projection.field1) as MyReusedConcat
}This helps to avoid redundancies and keep the required source code small.
3. Summary and considerations
Both CDS View and new CDS View Entity may be used in parallel. However, going forward only the CDS View Entity should be created, because it offers several improvements and even lifts some of the previous technical limitations.
A migration of the existing legacy CDS Views is not mandatory but recommended. Automatic conversion tools are available, also see: https://blogs.sap.com/2021/10/16/a-new-generation-of-cds-views-how-to-migrate-your-cds-views-to-cds-view-entities
New CDS features are still being added. Be sure to check the following document, which gives an overview of supported features per ABAP release: https://help.sap.com/doc/abapdocu_cp_index_htm/CLOUD/en-US/index.htm?file=abencds_language_elements.htm