Vistas ABAP CDS

Una vista ABAP CDS es código fuente que el sistema ABAP convierte en una vista de base de datos:

1. Un desarrollador crea una definición de datos en ABAP Development Tools y escribe una sentencia DEFINE VIEW ENTITY: fuentes de datos, campos seleccionados, cálculos, joins y asociaciones con otras entidades CDS.
2. Las anotaciones añaden metadatos: etiquetas, semántica como campos de moneda o de unidad, roles analíticos, indicaciones de UI y ajustes de exposición OData.
3. Al activarla, el sistema crea la entidad CDS y la vista correspondiente en la base de datos, de modo que la lógica se ejecuta donde están los datos.
4. Los consumidores leen la vista: ABAP SQL en programas, servicios OData construidos con RAP, consultas analíticas y API liberadas.
5. Si existe un control de acceso CDS para la vista, sus condiciones se aplican a cada lectura de la vista.

Las asociaciones son una diferencia clave frente a las vistas de base de datos clásicas: declaran una relación una sola vez, y el join solo se construye cuando un consumidor sigue la ruta de la asociación. Una vista ABAP CDS es, por tanto, un modelo de datos semántico reutilizable, no un simple SELECT almacenado.

La documentación de SAP cita una activación más rápida, una sintaxis más sencilla y comprobaciones más estrictas entre los motivos para usar view entities. Las vistas basadas en DDIC existentes siguen funcionando, y ABAP Development Tools ofrece un asistente de migración, documentado en on-premise a partir de SAP S/4HANA 2023 FPS00. RAP en strict mode también espera view entities como fuentes de datos. Para cualquier desarrollo nuevo, las view entities son la variante de vistas ABAP CDS que debe usarse.

SAP S/4HANA incluye miles de vistas CDS organizadas como el modelo de datos virtual (VDM). Las basic interface views exponen entidades de negocio cercanas a las tablas, las composite interface views las combinan y las consumption views sirven a una aplicación o consulta concreta. El prefijo del nombre indica la capa: I_ para las interface views, como I_SalesOrder, y C_ para las consumption views.

Lo que importa a los clientes es el estado de liberación de una vista:

• Liberada para la extensibilidad key user (contrato C1): utilizable en herramientas de key user como la app Custom CDS Views.
• Liberada para el desarrollo en la nube (contrato C1): utilizable por los desarrolladores en ABAP Cloud, incluida la extensibilidad para desarrolladores.
• No liberada: visible en el sistema pero sin contrato de estabilidad; SAP puede modificarla en cualquier actualización.

Un key user de Alder Manufacturing que necesita los pedidos de compra abiertos por proveedor, por ejemplo, construye una vista CDS personalizada sobre vistas de compras liberadas en lugar de leer tablas. En el modelo de datos virtual, el estado de liberación decide si es seguro construir sobre una vista ABAP CDS.

Una vista CDS aporta datos y metadatos; otros objetos la convierten en una aplicación:

1. Camino actual (RAP): las CDS view entities forman un business object, una behavior definition añade operaciones, las projection views lo adaptan, y una service definition junto con un service binding lo exponen como OData V2 o V4.
2. SAP Fiori elements lee las anotaciones de UI de ese servicio y genera un list report o un object page.
3. Las aplicaciones analíticas consumen consultas analíticas CDS, definidas como transient view entities en los releases recientes y con la anotación obsoleta @Analytics.query en los más antiguos.

Los sistemas más antiguos usan caminos anteriores: la anotación @OData.publish del ABAP Programming Model for SAP Fiori, o un proyecto de SAP Gateway que usa la vista CDS como fuente de datos referenciada; compruebe cuál de ellos sigue admitiendo su release. En todos los caminos, la vista ABAP CDS define qué son los datos; el comportamiento transaccional proviene de RAP o, en el modelo predecesor, de BOPF.

Los puntos fuertes son considerables. Un único modelo sirve por igual a OData, al análisis y a ABAP SQL; los cálculos se ejecutan en la base de datos; las anotaciones aportan una semántica que todos los consumidores entienden; y el control de acceso se declara junto a los datos.

Los límites se derivan de lo que es una vista:

• Solo modelo de lectura. Una vista CDS no crea, modifica ni valida datos. Las transacciones necesitan un business object RAP por encima.
• SQL declarativo, no lógica procedimental. Los algoritmos complejos pasan a CDS table functions implementadas en AMDP, o a ABAP.
• El rendimiento depende de la pila. Las vistas construidas sobre vistas que a su vez se basan en otras vistas pueden producir un SQL pesado; las asociaciones usadas sin cuidado multiplican los joins.
• Ligadas al release. Las funcionalidades de sintaxis llegan release a release; una vista escrita para el SAP BTP ABAP environment puede no activarse en un release on-premise más antiguo.

Las vistas ABAP CDS son el lugar adecuado para la semántica de los datos, no para la lógica de procesos o de transacciones.

1. Crear nuevas vistas basadas en DDIC. Son obsoletas; empiece con view entities.
2. Construir sobre vistas SAP no liberadas. Funciona hasta que una actualización modifica la vista. Compruebe primero el contrato de liberación.
3. Olvidar el control de acceso. Sin un control de acceso CDS, cualquier persona autorizada a leer la vista ve todos sus datos. Añada un control de acceso y mantenga también las autorizaciones de inicio de la aplicación.
4. Escribir anotaciones de UI en la definición de datos. Las metadata extensions mantienen legible el modelo y permiten que los metadatos de UI cambien a su propio ritmo.
5. Confundir ABAP CDS con CAP CDS. Misma idea y sintaxis similar, runtime diferente: un modelo CAP no se activa en un sistema ABAP.

La mayoría de los problemas con las vistas ABAP CDS provienen de decisiones de ciclo de vida, no del SQL.