Skip to Content
Technical Articles
Author's profile photo Andrea Schlotthauer

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.

 

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 name Technical name Available since
Program that lists all usages of CDS-managed DDIC views RUT_WHERE_USE_SQLVIEW SAP Note 3201681
Program for migration analysis RUTDDLS_MIGRATION_CANDIDATES ABAP 7.56 | ABAP Platform 2021
Manual migration ABAP 7.56 | ABAP Platform 2021
Program for tool-based migration RUTDDLSV2MIGRATION ABAP 7.56 | ABAP Platform 2021

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

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.
  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:

    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.
    3. Rule Processing
    4. 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 and further information

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.

For more information, see the embedded help:

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

Blog posts about CDS view entities:

Assigned Tags

      12 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo AjeethKumar R
      AjeethKumar R

      Excellent blog, Andrea!!. Thanks for bringing this up.

      Author's profile photo Christian Guenter
      Christian Guenter

      Nice.

      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:

      Unfortunately RUTDDLS_MIGRATION_CANDIDATES is not available in my 7.55 SP01 On-Premise system. Is it shipped with SP02? Is there a note for implementation?

      Best regards

      Christian

      Author's profile photo Andrea Schlotthauer
      Andrea Schlotthauer
      Blog Post Author

      Hi Christian,

      sorry, that's a mistake. I have just learned that there was a delayed delivery. RUTDDLS_MIGRATION_CANDIDATES is available since on-premise release 7.56, ABAP Platform Cloud 2011, ABAP release 7.82.

      Thanks for raising this. I will adjust the info.

      Best

      Andrea

      Author's profile photo Petr Benes
      Petr Benes

      Hi Andrea, do we need to regenerate the the oData services after the migration (tx SEGW)? KR, Petr

      Author's profile photo Andrea Schlotthauer
      Andrea Schlotthauer
      Blog Post Author

      Hi Petr,

      the OData services should work out-of-the-box, no need to regenerate them after the migration. But you need to pay attention to the following:

      • After the migration, make sure there are no ATC errors in your SEGW project.
      • During the migration, the DDIC views specified after @AbapCatalog.sqlViewName are deleted. Make sure that your MPC classes don't access any DDIC view.

      BR

      Andrea

      Author's profile photo Edo von Glan
      Edo von Glan

      Hi Andrea,

      What is the recommendation for BW extractors that use the old CDS-managed DDIC views?

      I suppose these will break when we migrate the corresponding CDS in our ERP system (and the analysis report does not show the external usage from BW).

      Is there a matching migration tool for the extractors in BW that use the old CDS-managed DDIC views?

      Best regards,

      Edo

      Author's profile photo Andrea Schlotthauer
      Andrea Schlotthauer
      Blog Post Author

      Hi Edo,

      during a migration, CDS-managed DDIC views are deleted. Potential consumers of CDS-managed DDIC-views break after a migration.

      There's a report that lists all usages of a CDS-managed DDIC view in an ABAP system: RUT_WHERE_USE_SQLVIEW. Please see the following SAP Note for instructions: 3201681 - Usages of CDS-managed DDIC view - SAP ONE Support Launchpad

      All occurrences have to be changed manually. The following SAP Note provides migration steps: 2998810 - ABAP CDS: Syntax errors for customer views or CDS view extends during or after upgrade - SAP ONE Support Launchpad

      Best

      Andrea

      Author's profile photo Edo von Glan
      Edo von Glan

      Hi Andrea,

      thanks for your answer.

      I was hoping that you could find out SAP-internally about corresponding BW migration processes / tools, for the BW extractors that use the CDS-managed DDIC views.

      I expect no problems in adapting the ERP customer development objects that use them.

      Are you sure about note 2998810? It seems to describe possible problems during the technical upgrade phase (SUM etc).

      Best regards,

      Edo

      Author's profile photo Andrea Schlotthauer
      Andrea Schlotthauer
      Blog Post Author

      Hi Edo,

      I understand the question as follows: What should be taken into account if an extraction enabled CDS view is migrated to CDS view entity.

      Answer from dev team: The annotation Analytics.technicalName must be set to the name of the former DDIC view (specified after @AbapCatalog.sqlViewName). This is done automatically by the migration tool.

      With this name, ODP/CDI is triggered. That is, the extraction doesn't notice anything about the migration (as long as the technicalName is equal to the sqlViewName).

      The migrated view entity returns the same extraction results as before.

      @Analytics,technicalName is used as a dummy to just keep the ODP name same as the non-migrated view and all other metadata is retrieved from the CDS view itself.

      Does that help?

      If not, I suggest you to contact the dev team directly, perhaps via a ServiceNow incident.

      Author's profile photo Edo von Glan
      Edo von Glan

      Hi Andrea,

      thanks, that sounds very promising!

      My BW colleagues will test it, when they have time.

      Best regards,

      Edo

      Author's profile photo Edo von Glan
      Edo von Glan

      Hi Andrea,

      During the S/4 conversion (still in sandbox), we just encountered a similar problem. In a customizing for material classification (component ca-cl-chr), we previously used a CDS-managed DDIC view as source for F4 help. Replacing this with the (now migrated) CDS view entity does not seem to work.

      Are all S/4 components supposed to work with CDS view entities in our release (S4CORE 106 / Basis 756)?

      Author's profile photo Andrea Schlotthauer
      Andrea Schlotthauer
      Blog Post Author

      Hi Edo,

      yes, technically, CDS view entities work as source of F4 Help. From your request, it is not completely clear where the issue occurs.

      Please open a ServiceNow incident on component BC-DWB-DIC-F4 and the dev team will analyze your case.

      Best

      Andrea