(Glue-2408) Best Practices for (not) Replicating Data from Compatibility Views

Owned by SNP
Last updated: Sept 03, 2024 by Marian Vidra
3 min read

SAP has partially redefined the ERP data model 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, for example, transactions, reports and APIs. You can find some examples 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.

This chapter examines what compatibility views mean from the perspective of data replication and, in particular, replication by SNP Glue. You 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. Is it static? Mostly – usually leftovers from the S/4HANA upgrade.

2. Are the views easy to handle? (complexity)

Some CDS compatibility views are quite easy to work with. For example, the CDS compatibility view MSEG is just a selection from MATDOC with a 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 a 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.

Examples:

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

3. How can I find out?

Proceed as follows to check if the underlying object you are trying to access is a compatibility view:

  1. Start transaction SE16N.

  1. In the Table field, enter the table name.

  1. Press Enter.
    You will see the Proxy Object field populated, which indicates a replacement object is used instead of a table directly.

  1. Double-click the proxy object to navigate to transaction SE11.

  1. Double-click the data definition to view the logic behind the compatibility view.

Example:

4. Progress or regression? (data modelling)

You have just implemented the newest and the latest innovations from SAP. S/4HANA heavily simplifies the data model as well as reporting functions. Relying on old structures in your target platform means actively increasing your architectural debt.

Summary

In most cases, no data changes are made to the original tables, and therefore no delta is required. For some of these objects (see point 2 above), it is even impossible to define a reliable delta mechanism that would capture all changes and deliver the data in an “at least once” fashion. Considering the differences between the data models of ECC and S/4HANA, the S/4HANA migration should also include adjustments in the reporting layer.

In summary, the SNP recommendation is generally to avoid data replication from CDS compatibility views unless it is necessary. If it is necessary, SNP recommends only full loads for this purpose for smaller tables, e.g. master data tables.