Hola de nuevo a la comunidad de SAP. Espero se encuentren bien y que hayan tenido tiempo de leer el primer blog que escribi acerca del CAP aqui. Hoy me gustaria agregarle funcionalidad al blog que hice acerca de las aplicaciones full stack en el framework de CAP. Nuevos artefactos de la base de datos como lo son las calculation views y stored procedures para hacerlo ver mas como una aplicación real. Para leer este blog en ingles ve aqui
Empezemos agregando un calculation view. Como ya han de saber, los calculation views representan datos de tablas/views múltiples para presentar un modelo de datos. Recuerda que, cuando creas nuevos objects, debes hacer un build (cds build) a nivel de proyecto para poder hacer el deployment asegurándote de que no haya nada malo en el HDI.
Para agregar un calculation view a tu proyecto de CAP has los siguientes pasos:
- Crea un calculation view dentro del folder db/src del proyecto.
Desde el command palette, escribe >hana: para abrir el menú de sugerencias y seleccionar del drop down “Create SAP HANA Database Artifact”
- Sigue los pasos del wizard para anadir la información correspondiente al tipo de objecto db, nombre, path, etc.
Una vez que hayas creado el modelo de datos, necesitamos que re-construir el proyectoandes de hacer deploying. Para reconstruir el proyecto, desde la terminal, escribe: cds build
*Nota que las tables y el nuevo view seas re-construidos (lo puedes ver desde el output de la terminal)
Una vez que los objectos sean construidos, puedes usar el icono de cohete desde la herramienta BAS para hacer deploy – pon el ratón al nivel de proyecto y no al nivel de objecto.
Una vez que se haga el deployment, puedes verificar si el calc view correctamente se creo desntro de la instancia de HANA usando el explorador de bases de datos (desde la sección de Column views)
Y tambien puedes hacer un query al view desde la consola de SQL
O tambien desde la terminal usando la herramienta de hana-cli
El siguiente paso es agregar el calculation view al archivo de modelos de la DB y hacer referencia a el desde el servicio de OData. Ya que el CV existe en el sistema, debemos includir anotaciones al archivo de cds de la BD para que el sistema sepa que es un objecto ya existente.
Usando la herramiente de hana-cli tool, inspeccionemos el view. Usando el de output cds (-o flag) Podemos genrar este view como si fuera un view de CDS. Como ya lo mencione anteriormente, y que ya existent el objecto, la herramiente de hana-cli incluye esas anotaciones al calculation view (@cds.persistence annotations arriba del nombre de la Entity) juega con el comando para ver que otras opciones puedes usar y también para ver la definición completa del mismo
Con esta definicion de CDS, continua hacia el archive de CDS. Nota los cambios que quitamos el namespace y lo anadimos como context en la estructura abajo. Eso se hace para no tener que poner un namespace en el calculation view.
Una vez que la view se haya incluido en esta definicion, continuemos al servicio de OData.
Lo incluimos aqui para poder exponerlo como un endpoint diferente. La anotacion @readonly se inlcuyo en el servicio pues muestra que solo es para leers y el consumidor del servicio no trate de crear o manipular los datos desde este endpoint.
El siguiente paso es para asegurarnos que trabaje la construccion y deployment de la aplicacion como lo hicimos anteriormente. Despues de que se haya hecho el deployment, corre el servicio desde la temrinal para ver si el nuevo endpoint ha sido expuesto. Recuerda que puede haber caching en la aplicacion y el app watch pudiera requerirse correr de nuevo.
Cuando hagamos click en el endpoint, puedes observer que los datos tambien son regresados desde el servicio de OData como se muestra en la sig imagen.
Otro tipo de objeto muy comun que siempre es requerido en una aplicacion real es un stored procedure. Los Stored procedures son funciones que facilitan el crear/leer/manipular/borrar records en la base de datos. La mayoria de los ejemplos que vi en el internet muestran como se ejecuta el stored proc pero no muestran como pasar inputs hacia el endpoint y sucesivamente hacia un stored procedure. En mi caso, quiero mostrar como un stored procedure se usa para crear vendedores pasando parametros al API y luego a la función de node y luego al stored procedure así podemos mostrar el ciclo completo.
Para empezar, solo tenemos esta lista de vendedores.
Luego, en el codigo del stored procedure se ve asi
En el API, debemos crear una Action (Las Functions son solo para leer datos). Mi definicion (parcial) del API se ve asi (imagina que las requests de GET son functions y los requests de POST son actions) :
Ademas, quiero mostrar una funcion sin inputs, una funcion con un input simple y luego una action con input de tipo complejo lo cual parecera un ejemplo real. Para tener codigo que ejecute estos endpoints, debemos tener una salida, lo cual es un archivo de js con el mismo nombre del servicio de cds. En mi case, yo hize un archivo llamado service.js debido a que mi archivo de servicio es service.cds
Abajo, puedes verificar en el archivo de service.js para ver las diferencias entre las 3 funciones que acabo de mencionar. Construyamos el servicio y hagamos re-deploy usando el #BAS. Quisiera sugerir que cada vez que agregues objectos nuevos que hagas build, deployment y que los pruebes correctamente, para luego incluirlos en el code repo para que no se pierda tu trabajo.
Una vez que termines con el codgo, puedes hacer pruebas del request tipo POST desde la herramienta de postman como sigue:
- Nota el objeto complejo en el body del request POST el cual es el input de la función de js. Fue definido como un tipo en el servicio de CDS
- El request POST require un cookie que se pasa en la seccion de header del request; puedes obtener este valor desde la herramienta de dessarrollo del browser desde cualquier otro GET request (F12 dev tools – Headers – cookie)
** Otros posibles errores que pueden ocurrir en este paso son, ten cuidado cuando hagas el set up del body pues tiene que ser identico al input del action (Vendor), como también la estructura de JSON como es el tipo de dato que se pasa a la action. Si llegara a resultar en un error, puedes decifrarlo rapidamente pues, por ejemplo los errores de http400 inmediatamente te dirán que la estructura no es igual que el tipo de dato esperado en el servicio.
** Si llegaras a tener el url incorrecto para hacer el POST, probablemente recibas un error de tipo 404 – nota que la función require paréntesis al final del url, mientras que la acción no require parentesis.
Voila! Aqui estan los records de la tabla despues de que la accion de insert ha sucedido correstamente.
Mis dificultades:
- Tuve dificultades al tartar de crear el calculation view pues primeramente use mix-case. Tuve que borrar y recrear el view con mayusculas.
- Cuando tienes que hacer el deploy del proyecto – asegurate de re-construir el proyecto desde la terminal usando el comando cds build y asegúrate que no haya errores
- Entender que hay que tener varias terminales corriendo simultaneamente: siempre hay que tener 2 activas(correr el comando watch en una y el comando cds bind –exec npm run app en otra.
- Entender la diferencia entre function y action (para los stored procedures)
Actions: se usan para operaciones que agreguen o modifiquen datos via POST
Functions: se usan solo para leer datos via GET
- El nuevo sintax/funciones disponibles del código nodejs usando funciones de CDS. No estoy Seguro donde encontrat una lista complete de ejemplos de esto.
Otros recursos que lei durante este blog:
https://www.youtube.com/watch?v=yceqr9vycrs&t=2402s
https://www.npmjs.com/package/sap-hdbext-promisfied
Como puedes ver, para construir este ejemlpo simple y tambien para agregar algo mas realista, use un calculation view expuesto via el servicio de OData y otro ejemplo usando un stored procedure para crear un record en la base de datos. Gracias por leer este blog y espero que hayan podido seguirlo. Por favor compartan sus compentarios, dudas o dificultadoes y tambien compartan este blog con otros.
