Upgrade SaaS

Hace unas semanas os hablé sobre la posibilidad de generar aplicaciones para ser consumidas vía suscripción, lo que llamamos Software as a Service (SaaS). En este nuevo post vamos a analizar la forma de desplegar las actualizaciones de nuestra aplicación una vez nuestros clientes están suscritos.

Para las actualizaciones, debemos implementar los cambios en nuestro proyecto, generar una nueva versión del fichero .mtar y hacemos el despliegue en la cuenta proveedora.

Con esto, los tenants suscritos ya recogen las actualizaciones, excepto los cambios que tengan que ver con el modelo de datos, es decir, las tablas de su HDI container no se han actualizado, ya que este paso se realiza en el evento onSubscription (cuando se suscriben) y no al actualizar la aplicación.

Para las actualizaciones que conlleven un cambio en el modelo de datos debemos realizar un paso más, llamando a la API que muestro a continuación:

En el body podemos indicar qué tenants son los que vamos a actualizar su modelo de datos desde el proyecto que hemos desplegado con los cambios. Tenemos la posibilidad de actualizar todos los tenants suscritos indicando “all”.

Además tenemos el parámetro “autoUndeploy” que sirva para indicar cómo va a ser el funcionamiento del HDI deployer para las tablas que han sido borradas. Es decir, el HDI deployer detecta los deltas del modelo de base de datos (los cambios, añadidos y borrados del modelo), pero con los borrados se comporta de manera diferente.

Solo tiene en cuenta el borrado si estos ficheros se encuentran en un archivo llamado undeploy.json,  o si lo forzamos con el parámetro antes indicado “autoUndeploy”. Es decir, si al llamar a la API indicamos este valor a true, el HDI deployer ignorará el fichero undeploy.json y eliminará todas las tablas que ya no vienen indicadas en el modelo de datos de la actualización.

La llamada a esta API nos devolverá el identificador del job que se pone en ejecución, y del que podemos consultar su estado con la siguiente API para saber el resultado de las actualizaciones en cada uno de los tenants ejecutados.

El resultado del estado del job nos devolverá algo del siguiente tipo:

El estado del job puede ser “QUEUED” (no ha comenzado todavía), RUNNING (ejecutándose), FINISHED (ejecutado con éxito) y FAILED (no se ha podido ejecutar).

Y el estado del resultado de la actualización en cada uno de los tenants puede ser RUNNING (ejecutándose), SUCCESS (actualizado con éxito) o FAILURE (ha habido errores y nos mostrará el error en el log). Los logs quedarán almacenados durante 30 minutos antes de que se borren.

Además de cambios en las tablas del modelo de datos, a veces, queremos también realizar cambios en los datos que hay grabados en las tablas. Como ya explicamos, para las inicializaciones de datos tenemos los ficheros .csv en la carpeta “data” con los mismos nombres que las tablas, si en una actualización se quieren cambiar esos juegos de datos se hace de la misma manera que los cambios del modelo de datos.

Es decir, se generan esos csv en el proyecto y al lanzar la API de actualización asíncrona se introducen estos nuevos datos del fichero en las tablas indicadas, pero cuidado porque se van a borrar todos los datos existentes en dichas tablas que queremos cargar.

En este post hemos visto el tema de las actualizaciones del proyecto, pero también existe la posibilidad de que alguno de los clientes pueda realizar extensiones en su tenant y esto lo veremos en el siguiente post.