Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
cancel
Showing results for 
Search instead for 
Did you mean: 
AndreaUS
Product and Topic Expert
Product and Topic Expert
24,263

As of 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.


 For details, see:

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:

Tool nameTechnical nameAvailable since
ADT migration wizard ABAP 7.58 | ABAP Platform 2023
Program that lists all usages of CDS-managed DDIC viewsRUT_WHERE_USE_SQLVIEWSAP Note 3201681
Program for migration analysisRUTDDLS_MIGRATION_CANDIDATESABAP 7.56 | ABAP Platform 2021
Manual migration ABAP 7.56 | ABAP Platform 2021
Program for tool-based migrationRUTDDLSV2MIGRATIONABAP 7.56 | ABAP Platform 2021
ADT migration wizard ABAP quarterly release 7.91

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

General considerations

Continued support for CDS DDIC-based views
SAP will continue to support classic CDS DDIC-based views. CDS DDIC-based views will not be retired, and customers will not be forced to use CDS view entities. SAP protects investments.

The following policies apply:

  • No new features will be added to CDS DDIC-based views. Only CDS view entities are further developed, and new features are added only to CDS view entities.
  • When creating new CDS data models, SAP recommends using CDS view entities to benefit from the new features and enhanced functionality. However, this is optional. Customers can also create new CDS DDIC-based views (today and in the future).
  • There are some contexts that enforce the use of CDS view entities and do not allow CDS DDIC-based views. For example, in the RESTful ABAP Application Programming Model, when a RAP BO is created with strict mode enabled, the syntax check enforces CDS view entities. However, this strict policy only applies to new developments. It does not change existing developments. 

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 view that is attached to each DDIC-based view. This DDIC view is deleted during a migration to a CDS view entity and all scenarios which rely on the DDIC 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
Reverse migration is not possible by yourself. If necessary, open a support ticket on component BC-DWB-DIC.

ADT migration wizard

An ADT migration wizard is available as of ABAP 7.58 (on premise) | 7.91 (quarterly releases), which corresponds to S/4 release 2302.

It covers exactly the same steps and it processes the same rules as the migration tool RUTDDLSV2MIGRATION. It is also available for cloud systems, for example, Steampunk, Embedded Steampunk, and ABAP Cloud systems.

As a first step, you can create a new repository tree that lists all CDS DDIC-based views in a system as follows: right-click on a package and select Derive New Tree.

In the Derive Tree window, you can configure the tree:

  • In the field Tree Name, you can enter a name.
  • In the field Property filter, you can specify a filter, for example: type:ddls sourcetype: ddic_based_view.
  • Then click Finish.

Result: You have created a package that lists all CDS DDIC-based views.
Now you can select one or more of the views, make a right-click, and select Migrate to CDS View Entity ... 


The migration wizard then guide you through the same steps as the migration tool RUTDDLSV2MIGRATION. See the section below for more details.

Program that lists all usages of CDS-managed DDIC views

SAP Note 3201681 provides a tool that lists all usages of CDS-managed DDIC views in ABAP coding. Using CDS-managed DDIC views has been declared obsolete since ABAP release 7.56. If CDS views are migrated to CDS view entities, the corresponding CDS-managed DDIC views are deleted and all objects that use these CDS-managed DDIC views get error messages. This tool helps in adapting your coding to be prepared for CDS view entities.
When planning a large-scale migration of many views at once, all usages of CDS-managed DDIC views should be replaced by the name of the CDS view as preparation.

Tool name: RUT_WHERE_USE_SQLVIEW.

Program for migration analysis

Since ABAP On-Premise Release 7.56, 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 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.

Video clip that demonstrates the migration analysis tool:

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:
    1. Remove the header annotation sqlViewName.
    2. Add the keyword ENTITY.
    3. Perform additional changes if required. The migration analysis report and the syntax check provide feedback on the required adjustments.
    4. 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:

  1. Initial Consistency
  2.  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.

  1. Rule Processing
  2. 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.

Video clip that demonstrates the migration tool:

Conclusion

Keep in mind: Migration is voluntary and “classic” CDS DDIC-based views are still supported, but not further developed.
You are welcome to leave comments and ask questions right here.

Further information

Official documentation of the ADT Migration Wizard: Migrating CDS DDIC-Based Views to CDS View Entities | SAP Help Portal

Embedded help of the migration reports:

  • RUTDDLSV2MIGRATION > More > Program Documentation
  • RUTDDLS_MIGRATION_CANDIDATES > More > Program Documentation.

Blog posts about CDS view entities:

 

21 Comments