Reemplazar una tabla por una CDS liberada puede cambiar el resultado de su informe

El hallazgo más común en la deuda Clean Core es la lectura directa de una tabla de SAP: un SELECT sobre una tabla que SAP considera interna. Para muchas de ellas, la propia SAP indica una CDS liberada como sucesora, y ADT llega a ofrecer el cambio automático. Parece el trabajo más sencillo de la adecuación. Es también el que más riesgo esconde.

El problema no es el cambio en sí. Es suponer que la CDS sucesora devuelve exactamente lo que devolvía la tabla.

Un campo que no existe, o que no es el mismo

La sucesora no siempre tiene todos los campos de la tabla. Cuando el programa usa un campo sin correspondencia, el cambio simplemente no cuadra. El caso más traicionero es otro: el campo existe en la CDS, con un nombre parecido, pero con un contenido distinto, porque la CDS convierte el valor, suma o aplica una regla. El código compila, el programa se ejecuta y el número cambia.

Filtro incorporado

Una CDS puede traer solo una parte de los registros de la tabla. Una tabla que guarda varios tipos de documento puede tener como sucesora una CDS que trae solo uno de ellos. Una CDS de documentos puede dejar fuera los ya eliminados, los archivados o las plantillas. Si el programa necesitaba esos registros, el informe pasa a mostrar menos, sin ningún error.

Control de acceso

Las CDS liberadas suelen venir con control de acceso: según las autorizaciones de quien ejecuta, la misma consulta devuelve menos registros, y los datos personales bloqueados pueden desaparecer. El SELECT original no hacía esa verificación. Cambiar la fuente sin tratar esto crea una regla de acceso nueva dentro de un informe antiguo: un usuario que siempre vio la lista completa pasa a ver solo una parte.

Cómo verificar antes de cambiar

"Compiló" y "el ATC dejó de señalarlo" no bastan como criterio. Lo que importa es que el programa siga devolviendo el mismo resultado. Sea cual sea la forma de hacer el cambio, a mano, con el quick fix de ADT o con alguna automatización, cuatro verificaciones evitan la sorpresa:

1. Enumerar los campos que usa el programa, y no solo los que aparecen en el SELECT: un campo leído al principio puede usarse mucho después, en un cálculo o en una salida. Para cada uno, confirmar que la CDS tiene el equivalente y que el contenido es el mismo, con el mismo elemento de datos y sin conversión por el camino.
2. Leer la definición de la CDS en ADT. Las condiciones del WHERE, los joins y las asociaciones muestran qué registros deja fuera. Si el programa necesita esos registros, la sucesora no sirve tal como está.
3. Revisar el control de acceso. La anotación de autorización y la regla de acceso (DCL) de la CDS indican si la lectura pasa a depender de quién ejecuta el programa. Mantener el comportamiento anterior o adoptar la regla nueva es una elección legítima, siempre que se haga a propósito y no por accidente.
4. Comparar con datos reales. En un entorno con datos representativos, leer la fuente antigua y la nueva con el mismo filtro y comparar registro a registro, en los campos que usa el programa. Que la cantidad coincida no basta: dos listas pueden tener el mismo tamaño y registros distintos.

Después del cambio, activar el objeto, volver a ejecutar el ATC para asegurar que no apareció ningún hallazgo nuevo y dejar la prueba funcional en manos de quien conoce el proceso. Cuando alguna de las cuatro verificaciones falla, el cambio deja de ser solo técnico y pasa a ser una decisión de negocio. Es mejor tomarla antes, con el impacto a la vista, que descubrirla en producción.

Para ver cómo aparecen estas correcciones en el panel de SAP, véase Cómo calcula SAP Cloud ALM la deuda Clean Core.