Antes de seguir incluyendo lógica en nuestras vistas CDS, hay un elemento básico que modificará el comportamiento de nuestras vistas y aportará valor y funcionalidad a nuestras aplicaciones e informes “desarrollados” en Fiori. Digo desarrollados, entre comillas, ya que muchos informes podrán construirse simplemente con anotaciones CDS sin introducir ninguna línea de código SAPUI5 en nuestra aplicación.
¿Qué son las anotaciones CDS?
Si recordamos el código de ejemplo que vimos en el primer artículo, observamos en la cabecera de nuestra vista ABAP CDS una serie elementos que comienzan con ‘@’.
@AbapCatalog.sqlViewName: 'ZVEJEMBLOG'
@AbapCatalog.compiler.compareFilter: true
@AbapCatalog.preserveKey: true
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'Vista cds ejemplo blog'
define view ZCDS_EJEMPLO_BLOG
as select from sflight {
key carrid,
key connid,
key fldate,
price,
currency
}
Las anotaciones CDS no son más que propiedades de nuestra vista CDS, una forma de enriquecer nuestras vistas. Todas estas anotaciones se evalúan en ejecución y dotan de funcionalidad y definen el comportamiento de nuestra vista CDS.
Hay una serie de anotaciones CDS básicas que se ubican en la cabecera de la vista CDS y que son interesantes conocer su funcionalidad.
@AbapCatalog.sqlViewName: 'ZVEJEMBLOG'
La anotación CDS @AbapCatalog.sqlViewName define el nombre de la vista SQL de nuestra entidad CDS.
@AbapCatalog.compiler.compareFilter: true
La anotación CDS @AbapCatalog.compiler.compareFilter: true especifica como se evalúa en ejecución la condición Where.
Si la anotación tiene valor ‘true’, cuando se dan en nuestro código las mismas condiciones de filtro, el ‘join’ asociado se ejecuta solamente una vez. En cualquier otro caso, se crea y evalúa cada expresión ‘join’ por separado.
@AbapCatalog.preserveKey: true
Cuando la anotación CDS @AbapCatalog.preserveKey tiene valor ‘true’, la vista SQL utiliza los campos clave tal cual se han definido en nuestra vista CDS. Si por el contrario, el valor es ‘false’, se utilizan los campos claves de la tabla de nuestro select en la vista SQL.
@AccessControl.authorizationCheck: #CHECK
La anotación CDS @AccessControl.authorizationCheck define el control de acceso cuando se utiliza Open SQL para acceder a la vista CDS. Esta anotación puede tener tres valores:
- #CHECK ⇒ Se lanza el chequeo de autorización. Se produce un ‘warning’ si no hay rol asignado.
- #NOT_REQUIRED ⇒ Misma función que el valor #CHECK pero suprimiendo el warning.
- #NOT_ALLOWED ⇒ No se realiza chequeo de autorización.
@EndUserText.label: 'Vista cds ejemplo blog'
Descripción de la vista ABAP CDS para el usuario final. Esta anotación se puede emplear para la vista CDS, así como para cada uno de los campos que se proyectan y son mostrados posteriormente por pantalla al usuario.
Otras anotaciones básicas
Además de las anotaciones autogeneradas por nuestro IDE cuando creamos un Data Definition, disponemos de otras anotaciones básicas que debemos entender a la hora de construir nuestras primeras vistas CDS.
@VDM.viewType: #CONSUMPTION
Define el tipo de vista VDM. Simplemente se utiliza para clasificar nuestras vistas ABAP CDS. No tiene ningún impacto en la ejecución de la vista. Esta clasificación es utilizada únicamente por SAP internamente para estructurar e interpretar las vistas CDS. No obstante, es recomendable utilizarlas para tener nuestros desarrollos estructurados. Existen tres tipos de vistas:
- #BASIC : vista que obtiene los datos básicos de nuestra aplicación, sin redundancias.
- #COMPOSITE: vista que obtiene datos derivados y que pueden ser compuestas por diferentes vistas de tipo #BASIC. Son las vistas que tienen la lógica de nuestro desarrollo, donde tendremos la mayoría de joins, asociaciones, cálculos de datos, etc.
- #CONSUMPTION: vista que sirve para una aplicación especifica y que se define en base a vistas de tipo #COMPOSITE y #BASIC.
Para comprenderlo mejor, tenemos que ver las vistas CDS como elementos reutilizables. Una vista COMPOSITE podrá obtener un extensa lista de campos para un objeto concreto calculados a través de enlaces con otras vistas, de extracción de datos de varias vistas BASIC, etc. Esta vista COMPOSITE se debe poder reutilizar en diferentes aplicaciones. La vista CONSUMPTION será la que utilicemos para una aplicación concreta, y será en esta vista, donde realmente expondremos los campos que realmente necesitamos para la aplicación que estamos desarrollando, aunque la vista COMPOSITE que este utilizando pueda contener más datos de los que necesitemos. Es aquí donde tener una correcta clasificación de nuestras vistas puede hacer que nuestros desarrollos sean reutilizables para diferentes aplicativos.
@oData.publish: true
La anotación CDS @oData.publish: true sirve para crear automáticamente nuestros servicio oData a partir de la vista CDS, sin necesidad de acceder a la transacción SEGW en ningún momento. Esta anotación se utilizará para las aplicaciones sencilla de tipo Informe que no requieran ninguna lógica fuera de lo común, agilizando mucho la construcción de nuestra aplicación Fiori.
Es realmente útil para aquellos desarrolladores especializados en el Back-End, desarrolladores ABAP, ya que no tendrán que pelearse con la creación del servicio oData en la SEGW, y simplemente creando la vista CDS y anotándola correctamente, podrán publicar el servicio directamente y crear una aplicación Fiori funcional sin tocar ninguna línea de código adicional. Esta anotación la veremos más en profundidad cuando construyamos nuestras aplicaciones de List Report.
Con estas anotaciones básicas estamos preparados para continuar aprendiendo más sobre las increibles vistas CDS. A veces el código autogenerado parece que no ‘existe’, pero es importante entender que hace nuestro código aunque no lo hayamos insertado manualmente. Si quieres investigar por tu cuenta más sobre las anotaciones CDS, puedes consultar la referencia de SAP para ello hasta que vayamos viendo en el blog tipo a tipo en detalle. En próximos artículos veremos la sintaxis de las vistas CDS, para realiar joins, asociaciones y exponer campos calculados.