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

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
hatrigt
Participant
Excellent blog, Andrea!!. Thanks for bringing this up.
ChristianGünter
Contributor

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

AndreaUS
Product and Topic Expert
Product and Topic Expert
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
petr_kobza
Explorer
0 Kudos
Hi Andrea, do we need to regenerate the the oData services after the migration (tx SEGW)? KR, Petr
AndreaUS
Product and Topic Expert
Product and Topic Expert
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
vonglan
Active Participant
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
AndreaUS
Product and Topic Expert
Product and Topic Expert
0 Kudos
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 - S...

Best

Andrea
vonglan
Active Participant
0 Kudos
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
AndreaUS
Product and Topic Expert
Product and Topic Expert

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.

vonglan
Active Participant
0 Kudos
Hi Andrea,

thanks, that sounds very promising!

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

Best regards,

Edo
vonglan
Active Participant
0 Kudos
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)?
AndreaUS
Product and Topic Expert
Product and Topic Expert
0 Kudos
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
vonglan
Active Participant
Update: this is solved (notes 3240003 and 3245134).
alfred_fritz
Discoverer
0 Kudos

I use CDS-managed DDIC as a source for "generic data sources" (transaction RSO2).

Is it possible to use CDS View Entities in "generic data sources" instead of DDIC directly? Or in connection with Analytics.technicalName?

I use this "generic data sources" in Enterprise Search models because I need generic deltas. Could I use CDS View Entities directly in custom ESH models instead of the generic data sources?

AndreaUS
Product and Topic Expert
Product and Topic Expert
0 Kudos

CDS view entities are supported in ESH models since ABAP release 7.81, ABAP Platform 2020. It is possible to use the CDS view entity name instead of the DDIC name directly without any additional steps.

alfred_fritz
Discoverer
0 Kudos
Thanks, good news.

As far as a understand you I could then create a fulltext index on a certain field in the underlying table.

Then create my CDS-View-Entities and use them in an ESH-model with fulltext search.

There will be no extra index creation inside the ESH Connectors.

Right now I have to use the extra step with the "generic data sources" to create connector indexes with deltas. The connector indices where necessary because of the need of CDS-views instead of tables and because of fulltext search in the models.
AndreaUS
Product and Topic Expert
Product and Topic Expert
0 Kudos
Hi,

I have checked with the dev experts and they say that the procedure and limitations for DDIC-based views and view entities are identical.

"if you want to define fulltext search for a field, you need to define a fulltext index in the underlying table. Same for CDS views and CDS view entities.

However, search views using the annotation @EnterpriseSearch.enabled: true are neither supported for CDS views nor for CDS view entities. This is described in SAP Note 2636156 - Guidelines for the use of @EnterpriseSearch-annotations - SAP ONE Support Launchpad"

Hope this helps. If you face any issues, please open a support incident.

BR

Andrea
yousen_wang
Discoverer
0 Kudos
aschlott

It‘s very nice. I learned a lot here. Now I have two questions, could you give me the answers?

 

1.The program RUT_WHERE_USE_SQLVIEW will not find objects under the home component,general customer developed code is under this component,so what is the meaning for this program.

 

2.How to transfer the migrated objects? When using the migration tool for processing, the transfer request must be local type.What is the correct way to deal with it? After the migration and activation, change the local type to the workbench request? Or release the local first, and then create another workbench request to include it?

 

 

BR

Yosen
0 Kudos
Hi Yosen,

Thanks for your feedback.

  1. If you notice, usages of a SQLVIEW also list local and home objects in a system. We can in addition extend this report to involve customer developed SQLVIEWs in HOME layer too.

  2. Migration Tool asks for a workbench request so that the changes are transported in a normal way. In addition, we have recently (2302 Cloud Release) introduced migration wizard even in ADT to make it comfortable for an user. There also, system asks the user for a respective workbench request so that the changes are released in a normal fashion.


Regards, Harish
yousen_wang
Discoverer
0 Kudos
Hi Harish.

 

Thank you for your reply.

 

As for the transmission request, my question is why to select a local request(not workbench). Please see the screenshot below:


screen shoot

0 Kudos
Hi Yosen,

Thanks for your feedback. As far as i remember, this problem has been fixed and does not exist anymore. If you want, you can open an incident/case so that we can analyze this problem in your system.

Regards,

Harish Mehta