A new generation of CDS views: how to migrate your CDS views to CDS view entities

With ABAP release 7.55, a new type of CDS view has been released: the CDS view entity. CDS view entities are an improvement over the “classic” CDS DDIC-based views.

New migration tool available

Now, a new migration tool is available that automates many steps of a migration from a CDS DDIC-based view to a CDS view entity. But that’s not the only helper to facilitate a migration. The following support has been released:

This blog post first provides some general information about migration and then gives details on each helper tool.

General considerations

View entities are by design incompatible with DDIC-based views.

The advantages of CDS view entities can only be realized based on incompatible changes to the concepts and implementation of existing CDS views. The most prominent example is the deletion of the CDS-managed DDIC view, that means, the ABAP Dictionary SQL view that is attached to each DDIC-based view. This DDIC SQL view is deleted during a migration to a CDS view entity and all scenarios which rely on the DDIC SQL view no longer work.

No automatic migration will take place.

During  migration, semantics of a view might change. Because of this, each developer needs to decide whether they want to migrate their views.

Reverse migration

To reverse-migrate from view entity back to DDIC-based view just open a support ticket on BC-DWB-DIC.

Program for migration analysis

Since ABAP On-Premise Release 7.55, an ABAP program is available that evaluates whether a migration from a CDS DDIC-based view to a CDS view entity is possible:

RUTDDLS_MIGRATION_CANDIDATES

You can select DDLS sources to be analyzed directly by name or indirectly by original system, person responsible, package, and so on.

As a result, all DDLS sources specified are classified into one of the following categories (column Overall Status):

Moreover, details on the sources of the errors are provided. Currently, the following aspects are checked for each migration candidate:

• Entity and DDLS name of the migration candidate must be identical. Otherwise, migration is not possible.
• The decimal shift function DECIMAL_SHIFT cannot be used in a migration candidate, since it is not supported in CDS view entities. CDS view entities offer the following functions instead:
• CURR_TO_DECFLOAT_AMOUNT
• GET_NUMERIC_VALUE
• The data source of the migration candidate cannot be a DDIC external view, since DDIC external views are not allowed in CDS view entities.
• Buffering annotations cannot be used, since they are not supported in CDS view entities.
• Certain obsolete data types are not supported in CDS view entities. If the migration candidate uses one of the obsolete types, you need to change this before a migration is possible.
• SELECT * is not supported in CDS view entities. You need to formulate an explicit element list instead.
• The annotation @AbapCatalog.compiler.compareFilter is not supported in CDS view entities. In CDS view entities, this annotation is always implicitly set to true and this default can’t be changed. During a migration, you need to remove this annotation and this might result in a behavior change:
• If the migration candidate uses this annotation with the value false and you remove it as part of your migration, then the value is implicitly set to true.
• If the migration candidate doesn’t use this annotation at all, then the implicit default value is false and during a migration, the implicit default behavior is changed from false to true.
• The annotation @ClientDependent is not supported in CDS view entities. Client handling is done automatically and implicitly in a CDS view entity by filtering the session variable $session.client. You need to remove the annotation @ClientDependent during a migration and this might result in a behavior change.
• The syntax $EXTENSION.* is not supported in CDS view entities.
• The DDIC SQL view of the migration candidate is used by other objects or ABAP programs. These dependent objects will no longer work after a migration.
• If the migration candidate includes input help, the direct assignment is lost during a migration.

For more information on an error, including how to solve it, select an error category and click F1.

Manual migration support

Since ABAP 7.56, ABAP Platform 2021, manual migration from a CDS DDIC-based view to a CDS view entity is supported. To perform a manual migration, follow these steps:

1. Check whether a migration is possible using the migration analysis report RUTDDLS_MIGRATION_CANDIDATES.

2. Open the DDLS source in ADT and perform the following steps:

i. Remove the header annotation sqlViewName.

ii. Add the keyword ENTITY.

iii. Perform additional changes if required. The migration analysis report and the syntax check provide feedback on the required adjustments.

3. Activate the view entity.

Tool-based migration

A migration tool is available since ABAP 7.56, ABAP Platform 2021:

RUTDDLSV2MIGRATION

The migration tool automatically performs many adjustments that are required for a migration and creates an inactive version of the migrated DDLS. It also includes many checks and in case of issues, indicates which lines of the migration candidate must be changed before a migration is possible. The last step of the migration – the final activation of the CDS view entity – must be done by the developer.

When using the migration tool, follow these steps:

1. Start the ABAP program RUTDDLSV2MIGRATION.

2. Select the DDLS sources to be migrated. Objects can be selected directly by name or indirectly by package, original system, person responsible, and so on.

3. Choose the execution mode. We recommend that you first perform a migration in simulation mode and afterwards execute the actual generation of an inactive view entity.

4. Choose Execute.

The migration consists of four phases:

i. Initial Consistency

ii. Precheck

Note: To see the embedded help, double-click on one of the prechecks.

The same checks are performed as with the migration analysis report RUTDDLS_MIGRATION_CANDIDATES. See the explanation above.

iii. Rule Processing

iv. Post Check

The tool provides an overview of the differences between the CDS view before the migration and the CDS view entity after the migration. It also gives feedback on each phase and indicates errors that must be solved manually (if applicable).

5. Activate the view entity.

The following list explains the rules that are applied to a CDS view to turn it into a CDS view entity in chronological order:

• ANNOTATIONS_HEADER_PURIFY: Remove unsupported header annotations.
• SELECT_EXPAND_ASTERISK: Replace SELECT * by explicit data source field list.
• MOVE_SELLIST: Move the selection list behind the FROM clause and embrace it with { }.
• ANNOTATIONS_REFERENCE_ADD: Add @Semantics.amount.currencyCode and @Semantics.quantity.unitOfMeasure if required.
• ANNOTATIONS_REFERENCE_CLEAR: Remove @Semantics.currencyCode and @Semantics.unitOfMeasure.
• LITERAL_BACKSLASH: Add a backslash (\) to each backslash in CL_QLAST_LITERAL.
• PARAMETER_SYNTAX_CORRECT: Change parameter syntax from :ParamName to $parameters.ParamName.
• FUNC_CEIL_FLOOR: Remove superfluous function call for integral parameters.
• NAMELIST_REMOVAL: Remove name list (signature).
• FUNC_AVG_ADD_TYPE: Add mandatory type to function AVG( ).
• BASEOBJ_SQLVIEW_TO_STOB: Change SQLVIEW names to STOB names of migration candidate data source.
• ELEMENT_PREFIX: Add element (associations, fields) prefixes if required.
• ALIAS_ADD_AS: Add keyword AS to aliases.
• ANNOTATION_ANALYTICS_TECHNICAL_NAME: Add the annotation @Analytics.technicalName: ‘SQLViewName’ if required.
• ASSOC_ON_ELEMENT_NAMES_CORRECT: Correct element names in association on conditions: Use expression $projection. ElemName instead of ElemName.
• ANNOTATIONS_ARRAY_SYNTAX_CORRECT: Correct syntactically wrong array annotations.
• DOMAIN_FIX_VALUE: Replace domain fix value with literal value.
• UNION_ADD_ANNO_PREVENT_INHERITENCE: Generate the following mandatory annotation in UNION views: @Metadata.ignorePropagatedAnnotations: true.
• UNION_ALIGN_KEY_DEFINITION: Align key definition in all UNION branches to match the first branch.
• FIRST_ELEMENT_AS_CLIENT: Delete first field if it is a client key field.
• REMOVE_CLIENT_FROM_UNIT_CURRENCY_CONVERION: Remove explicit client column from UNIT_CONVERSION and from CURRENCY_CONVERSION.
• UNION_REMOVE_ANNOS_IN_2ND_PLUS_BRANCH: Delete all annotations from all the UNION branches except of the first one.
• ENTITY_EYECATCHER: Add ENTITY keyword to the DEFINE VIEW syntax.

Source: sap.com