Aunque ya había escrito algo sobre esto de los Core Data Services (CDS), creo que merece la pena escribir un artículo algo más detallado (sin pasarse), ya que esto cada vez tiene más importancia dentro del mundo SAP.
Los CDS nacen con HANA, como una forma de consumir y definir modelos de datos enriquecidos ya que, como sabéis, con HANA tenemos que meter toda la carga de proceso que podamos a nivel de base de datos.
Antes era al revés, debíamos acceder poco a la base de datos y en el servidor de aplicaciones «marear» los datos hasta tener el resultado que queremos.
Ahora no, ahora HANA nos debería devolver los datos ya «cocinados» y nosotros sólo tenemos que preocuparnos de pintarlos «bonitos».
Al principio, los CDS sólo se podían utilizar con HANA, pero esto fue evolucionando y ahora se pueden utilizar con cualquier base de datos. Me explico…
Desde la versión de NetWeaver 7.4 SP05, podemos utilizar los CDS en ABAP, utilizando las ABAP Development Tools (ADT) y esto lo que hará será crear una vista en el diccionario ABAP y en la base de datos correspondiente (sea HANA o no).
¿Pero vamos a ver, SAP no había apostado por HANA y todos sus productos se estaban rediseñando para aprovechar la potencia de HANA? Sí, y eso sigue siendo así, pero… hasta que todo el mundo pase a HANA, hay que seguir trabajando, ¿no?
Bien, pues lo que podemos tener extendiendo el uso de los CDS es una forma universal de acceso a la información. Es decir, me da igual lo que tengas por debajo, que siempre voy a consumir un CDS, no voy a trabajar nunca contra tablas de la base de datos.
Además, como consumimos la información desde distintos orígenes (dispositivos móviles, aplicaciones analíticas, servicios web…), si conseguimos que todas sean capaces de leer e interpretar un mismo «formato», podríamos tener una única fuente y aquí es donde aparece el concepto Virtual Data Model (VDM).
Estos modelos de datos virtuales son los que nos permiten trabajar con independencia de las tablas físicas que haya por debajo. Por ejemplo, sabéis que en S/4HANA se ha simplificado el modelo de datos, eliminando muchas tablas, pero podemos seguir referenciando a nuestra «tablas de toda la vida», ya que aunque no existan físicamente, si existen virtualmente.
Si queréis profundizar con esto: ABAP Core Data Services – Introduction (ABAP CDS view)
Si queréis que os lo cuenten, aquí os dejo un enlace al curso oficial SAP: S/4HANA embedded analytics and Modeling Basics with Core Data Services (CDS Views)
En definitiva, que si queremos adaptarnos a los tiempos que vienen, conviene que sepamos cómo trabajar con CDS y tiene pinta de que te va a tocar revisar todo tu código para adaptarlo al nuevo paradigma: haz todo lo que puedas a nivel base de datos.
Vamos, que toca darle la vuelta a todo… 😉
Gracias por la información. Perdona, pero no encontré un sitio en Castellano donde hablen o digan Cuando si y cuando no hacer selecciones a CDS. No estoy de acuerdo con esto: «En definitiva, que si queremos adaptarnos a los tiempos que vienen, conviene que sepamos cómo trabajar con CDS y tiene pinta de que te va a tocar revisar todo tu código para adaptarlo al nuevo paradigma: haz todo lo que puedas a nivel base de datos.» Y digo por qué, creo que es un error mandar este mensaje, ya que hay gente que no aplica el sentido común.
Cuando se trata de sacar una Query no demasiado compleja, no me refiero a pocas tablas, puede tener muchas uniones de tablas, vale!! esta muy bien utilizar CDS (más rápido aunque no lo vas a notar apenas vs un inner join en S4), pero si vas a hacer cálculos dentro y en función de los resultados sacas una información u otra, o necesitas meter condiciones en hardcode en la CDS, en estos casos creo que es mejor plantearte o bien dividir la CDS y hacer el calculo visible en el programa (Me refiero en la parte backend, fiori creo que es mas viable) o bien ir a la forma clásica..
Te dice alguien que lleva sufriendo CDS mal hechas, o muy ambiciosas, que luego hay que arreglar o dividir o pasar a un código mas racional. Creo que la CDS mal hecha o mal pensada no te da la posibilidad, de poder en modo DEBUGUER ver que está fallando. Y a un funcional explicale que la CDS falla y vete a saber porqué o que se baje el eclipse.
Para aplicaciones Fiori, informes en BW,BI CLoud y tal si que lo veo, pero querer sustituir toda la logica de un report en una CDS es absurdo.
Carlos,
Como bien dices, la clave está en aplicar el sentido común y, por supuesto, hacer bien los CDS.
Está claro que si quieres crear una vista con 4 campos de 2 tablas, siempre vas a ir más rápido por la SE11, creas la vista y listo, pero… si pensamos en global y queremos establecer un estándar, deberíamos usar siempre CDS.
Bueno, no es que debamos, es que SAP lo hace todo así… por lo que es fundamental entender cómo funciona esto para poder entender cómo va el estándar.
Sobre dividir los CDS, está claro, no es cuestión de hacer todo en un único CDS; al contrario, tienes varias vistas simples que vas combinando en vistas compuestas y con eso ya montas las vistas de consumo que necesites.
Evidentemente, si el modelado de datos que haces es malo, el resultado no puede ser bueno.
Y para debugguear, yo creo que puedes utilizar el AMDP Debugger.
Nadie habla de sustituir toda la lógica de un programa, todo depende del programa, pero lo que sí es cierto es lo que comento: SAP trabaja así desde hace tiempo y si no entendemos cómo está montado todo esto, estaremos un poco perdidos a la hora de mirar qué hace un programa estándar.
La idea de los CDS es tener una forma de modelar datos agnóstica, independientemente de dónde se vayan a consumir esos datos y, en mi opinión, tienen más ventajas que inconvenientes; pero como todo lo nuevo cuesta dar el cambio…
Conozco gente a día de hoy, que sigue utilizando programación estructurada porque dice que lo de los objetos no se usa mucho… cada uno es libre de hacer sus desarrollos como mejor sepa/pueda.
Saludos.