This article serves as a reference for migrating a classic CDS DDIC based view (Define View) to CDS view entity (Define View Entity).
In this blog, I will demonstrate the complete practical migration process from a classic CDS Define View to a CDS View Entity. The article covers the migration analysis, pre-checks, post-checks, handling migration issues such as semantic annotations, performing the actual migration, and validating the migrated CDS View Entity.
The focus of this blog is not just on the theory, but on the hands-on steps and screenshots at each stage, making it easier to understand what happens during the migration and how to resolve the issues encountered along the way.
Difference between Define View and Define View entity
Define View | Define View entity |
|
|
Note: Nothing is migrated automatically. SAP explicit states that semantics can change during migration, so every view must be reviewed by a developer – there is no safe default migration path.
There are 2 ways to migrate Define View to Define View Entity:
- By using Classic Report Programs tool
- By using ADT migration wizard tool
Practical Implementation demonstration
- By Using ADT Migration wizard
Example: Sales Order Define View
- Here you can right click on Define View and observe the option to migrate the Define View to Define View entity
- It will prompt you to select CDS DDIC based view
- Click on Next button - it will take us to the Select Migration options screen
- Simulation -> Test First (Will this migration work without errors)
- Trial run / validation
- When you select Simulations:
- ADT analyzes the existing CDS' DDIC-based view.
- It checks whether the object can be migrated to a CDS View Entity.
- It detects potential migration errors or incompatibilities.
- It produces a migration log.
- No new CDS View Entity is created.
- The existing CDS view remains unchanged.
- It is safe to use during analysis/development.
- Migration -> Actual migration (Actual Create new CDS entity)
- Generates CDS entity as inactive objects, the activate manually
- When you select migration:
- ADT performs the actual migration.
- It generates the corresponding CDS View Entity.
- The generated CDS View Entity is initially inactive.
- You can review the generated source code.
- You can correct any issues manually.
- Then you activate the generated object.
- You should test the migrated object afterward.
- Select Simulation radio button -> Click on Next button -> Check the Simulation migration logs once after running
- In the below picture, you can expand and check all the logs to see which objects were impacted by the migration, it also shows the status of each log entry
- Once you have completed the Simulation process, go back, select the Migration radio button, and click Next. It will then ask for transport request (TR), Select TR and click Finish.
- Before that try to resolve all the possible errors.
- Mainly we get warnings and errors related to Currency, Units, Castings, where conditions.
- Once the respective Semantics annotations are added for Net Amount and Order Quantity, the error will disappear automatically,
- So, in this way, we must resolve all the warnings and errors while raised during migration.
- If we execute the data view, we can see the same output
Note: Once a CDS DDIC – based Define view has been successfully migrated to a Define View Entity, it cannot be migrated back to its original view state. So be careful before migrating the view.
By Using Classic Report Program tool
@AbapCatalog.sqlViewName: 'ZIDVPO'
@AbapCatalog.compiler.compareFilter: true
@AbapCatalog.preserveKey: true
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Purchase Order Details'
@Metadata.ignorePropagatedAnnotations: true
define view ZI_DV_PURORDER
as select from ekko
inner join ekpo on ekko.ebeln = ekpo.ebeln
{
key ekko.ebeln as po,
key ekpo.ebelp as poitem,
ekko.bsart as potype,
ekko.ekorg as poorg,
ekko.ekgrp as pogrp,
ekko.lifnr as supplier,
ekpo.matnr as material,
ekpo.werks as plant,
ekpo.lgort as storagelocation,
ekko.waers as currency,
ekpo.menge as quantity,
ekpo.meins as uom,
ekpo.netwr as netvalue,
ekpo.netpr as unitprice,
ekpo.peinh as priceunit,
case
when ekpo.loekz = 'L' then 'DELETED'
when ekpo.elikz = 'X' then 'DELIVERY COMPLETED'
when ekpo.menge = 0 then 'NO QUANTITY'
when ekpo.menge > 0 and ekpo.elikz <> 'X' then 'OPEN'
else 'UNKNOWN'
end as po_status,
case
when ekko.bsart = 'ZSUB' then 'SUBCONTRACTING'
when ekko.bsart = 'NB' then 'STANDARD'
when ekko.bsart = 'FO' then 'FRAMEWORK'
else 'OTHER'
end as po_type_description,
case
when ekpo.netwr >= 100000 then 'HIGH VALUE'
when ekpo.netwr >= 50000 then 'MEDIUM VALUE'
when ekpo.netwr > 0 then 'LOW VALUE'
else 'NO VALUE'
end as value_category,
case
when ekpo.menge >= 1000 then 'HIGH QUANTITY'
when ekpo.menge >= 100 then 'MEDIUM QUANTITY'
when ekpo.menge > 0 then 'LOW QUANTITY'
else 'NO QUANTITY'
end as quantity_category,
case
when ekpo.loekz = 'L' then 'CLOSED'
when ekpo.elikz = 'X' and ekpo.erekz = 'X' then 'FULLY COMPLETED'
when ekpo.elikz = 'X' and ekpo.erekz <> 'X' then 'DELIVERY COMPLETED - INVOICE PENDING'
when ekpo.elikz <> 'X' and ekpo.erekz = 'X' then 'INVOICE COMPLETED - DELIVERY PENDING'
when ekpo.menge > 0 and ekpo.netwr > 100000 and ekko.bsart = 'ZSUB'
then 'HIGH VALUE SUBCONTRACTING PO'
when ekpo.menge > 0 and ekpo.netwr > 100000 then 'HIGH VALUE OPEN PO'
when ekpo.menge > 0 then 'NORMAL OPEN PO'
else 'CHECK REQUIRED'
end as business_status,
ekko.aedat as creationdate
}
where ekko.bukrs = '1000' Analysis: RUT_WHERE_USE_SQLVIEW
- List all usages of CDS managed DDIC views
Analysis: RUTDDLS_MIGRATION_CANDIDATES
- In this phase we need the report RUTDDLS_MIGRATION_CANDIDATES to analyze the Core Data Services in the system that we want to migrate. If we run the report for the two views, we get an assessment of the migration possibility of the views.
- Run report to list every classic DEFINE VIEW in the system
Implementation: RUTDDLSV2MIGRATION
- Main report for Mass migration.
- Select the DDLs source to migrate – directly by name, or by package, system, or user
- Run in 'Simulate Generation' mode first. Review the protocol for errors and warnings without changing anything in the system.
However, we now receive errors when implementing the objects. If we take a closer look at the protocol, we find the error message that the reference fields are not contained in the entity.
- Give DDL name in respective input field and click on F8 execute button
- Here we got error in Post Check logs
Simulation Generation:
- In this mode, the tool does not perform the actual migration but provides a comprehensive analysis of the Classical CDS View. It checks for:
- Consistency: Ensures the CDS View follows the required structure.
- Errors: Flags with potential issues and inconsistencies.
- Pre-checks & Post-checks: Validates whether the CDS View adheres to migration standards before and after processing.
- Rule Processing: Provides insights into the underlying rules that will govern the migration.
Just double-click on the error log to get the complete information. The error indicates that the reference information for the currency and quantity fields is missing. From this, we can understand that, for a CDS View Entity, we need to add the appropriate semantic annotations for amount/currency and quantity/unit fields.
- In the screen below, observe the highlighted code carefully. It shows what needs to be added or which new features are introduced after migrating from a define view to a define view entity.
- Here, we have two options either migrate first and then add the required annotations or add the required annotations before starting the migration process.
Now, select Generate Inactive Version radio button in Execution Mode, click on F8 Execute button
This mode performs the actual migration, converting your Classical CDS View into a CDS View Entity. It generates the new version in an inactive state, allowing for post-migration testing and adjustments before activation. This ensures a smooth transition without disrupting ongoing operations.
Enter the TR here and Click on Execute (F8)/
- Go to, ADT refresh the Package or Project we can see the migrated entity
- If we try to ACTIVATE with error will get an activation error like this
- Once added @Semantics.amount.currencyCode: 'Currency' annotation the activation done successfully.
Why Migrate to CDS View Entities
Migrating to CDS View Entities offers several key benefits:
- Improved Performance: CDS View Entities are optimized for better performance, particularly in SAP S/4HANA environments.
- Scalability: They allow for more flexible and scalable data models that can evolve with your business needs.
- Future-Proofing: The CDS View Entity model is the foundation for future SAP developments, especially for integration with Fiori and other modern SAP applications.
- Consistency and Integration: The migration enhances consistency across SAP systems and improves integration with advanced analytics and reporting tools.
Conclusion:
Migrating the old views to the new entities definitely makes sense, since a second object, the SQL view, is no longer necessary. The activation times for views will also increase significantly, which will speed up our working time.
Bluesky
