Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Current »

SAP has partially redefined the data model of the ERP with the introduction of S/4HANA.  Certain objects, such as CDS Compatibility Views, have been introduced to ensure backwards compatibility of some core legacy processes, such as transactions, reports and APIs. Some examples can be found in the SAP note 2595627.

Important: It is important to distinguish between CDS views and CDS compatibility views. This article focuses on CDS compatibility views only.

Let’s take a look at what compatibility views mean from the perspective of data replication and in particular, replication by SNP Glue. We will need to consider multiple aspects.

1. Is there any data?

In many cases, compatibility views are unions and/or joins between the “old” ECC tables (no longer accessible to the Netweaver layer) and “new” S/4HANA tables which are actively used in the S/4HANA ERP. Is there any data in the compatibility view? Of course.
Is there any data in the original table? Maybe. Static?  Mostly, usually leftovers from the S/4HANA upgrade.

2. Easy to handle? (complexity)

As with any good technical question, the answer is “sometimes.”  Some CDS Compatibility Views are quite easy to work with.  For example, the CDS Compatibility View MSEG is just a selection from MATDOC with few where conditions.  It only has a single layer, and replication is easily handled.  In SNP Glue, you can source the data from MSEG (as view) and deploy the trigger on MATDOC to provide CDC.

Other CDS Compatibility Views are extremely complex, consisting of many layers, and can include many underlying SAP tables.  CDC is quite difficult to implement in this scenario.

image-20240828-091718.pngimage-20240828-091750.png

3. How to find out?

To check if the underlying object you are trying to access is a compatibility view,  go to SE16N and enter the table name.  You will see the field Proxy Object populated, which indicates a replacement object is used instead of a table directly.

image-20240828-092047.png

A simple double-click on the proxy object will bring you to SE11.

image-20240828-092118.png

and a double-click on Data Definition will show you the logic behind the compatibility view.

image-20240828-092139.png

4. Progress or regression? (data modelling)

You have just implemented the newest and the latest innovations from SAP. It heavily simplifies the data model (besides other reasons, such as simplifying reporting and data modelling).  Relying on old structures in your target platform means actively increasing architectural debt.

Summary

In the majority of the cases, there will be no data changes on the original tables, therefore no delta coming in. For some of these objects (point 2), it is even impossible to define a reliable delta mechanism, which would capture all changes and deliver the data in a “at least once” fashion. Considering differences between the data model of ECC and S/4HANA, investment into S/4HANA migration should also count with adjustments in the reporting layer. Considering all points mentioned, in general, the SNP recommendation is to avoid data replication from CDS compatibility views, unless necessary. If necessary, SNP recommends only Full loads for this purpose for smaller (e.g. Master data) tables.

  • No labels