Replacing a table with a released CDS view can change your report's result

The most common finding in Clean Core debt is a direct read of an SAP table: a SELECT on a table that SAP considers internal. For many of these tables, SAP itself names a released CDS view as the successor, and ADT even offers an automatic replacement. It looks like the simplest part of the Clean Core adaptation. It is also the part that hides the most risk.

The problem is not the replacement itself. It is assuming that the successor CDS view returns exactly what the table returned.

A field that does not exist, or is not the same

The successor does not always have all the fields of the table. When the program uses a field with no counterpart, the replacement simply does not work out. The trickiest case is a different one: the field exists in the CDS view, with a similar name, but with different content, because the CDS view converts the value, aggregates it or applies a rule. The code compiles, the program runs and the number changes.

Built-in filter

A CDS view may return only part of the table's records. A table that stores several document types may have as its successor a CDS view that returns only one of them. A CDS view for documents may leave out those already deleted, archived, or templates. If the program needed those records, the report starts showing less, without any error.

Access control

Released CDS views usually come with access control: depending on the authorizations of whoever runs it, the same query returns fewer records, and blocked personal data may disappear. The original SELECT did not perform this check. Switching the source without addressing this creates a new access rule inside an old report: a user who always saw the whole list now sees only part of it.

How to verify before replacing

"It compiled" and "the ATC stopped flagging it" are not enough as criteria. What matters is that the program keeps returning the same result. Whatever the way the replacement is made, by hand, with the ADT quick fix or with some automation, four checks prevent surprises:

1. List the fields the program uses, not only those that appear in the SELECT: a field read at the beginning may be used much later, in a calculation or an output. For each one, confirm that the CDS view has the equivalent and that the content is the same, with the same data element and no conversion along the way.
2. Read the CDS view definition in ADT. Conditions in the WHERE clause, joins and associations show which records it leaves out. If the program needs those records, the successor does not work as it is.
3. Look at the access control. The authorization annotation and the access rule (DCL) of the CDS view tell you whether the read will depend on who runs the program. Keeping the old behavior or adopting the new rule is a legitimate choice, as long as it is made on purpose, and not by accident.
4. Compare with real data. In an environment with representative data, read the old and the new source with the same filter and compare record by record, in the fields the program uses. Equal counts are not enough: two lists can have the same size and different records.

After the replacement, activate the object, run the ATC again to make sure no new finding has appeared, and leave the functional test to those who know the process. When any of the four checks fails, the replacement is no longer just technical and becomes a business decision. It is better to make it beforehand, with the impact in view, than to discover it in production.

To see how these fixes show up in the SAP dashboard, read How SAP Cloud ALM calculates Clean Core debt.