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.

2 comentarios sobre “Upgrade SaaS

Agrega el tuyo

  1. Hola Carlos, muy interesante el blog, con que framework o tecnologia se puede hacer el desarrollo de este tipo de aplicaciones? CAP?

    Sería muy interesante un post de cómo lo consumers se suscriben.

    Gracias por compartir

    Me gusta

    1. Hola Rubén, muchas gracias.
      Sí, en este caso la aplicación es CAP utilizando como base de datos HANA Cloud, Nodejs para la lógica del servicio y SAPUI5 para la interfaz de usuario.
      El proceso de suscripción de los clientes es muy sencillo, en la cuenta global tienes una subcuenta provider donde está la aplicación corriendo y los clientes a través de subcuentas consumidoras en la misma cuenta global se suscriben a la aplicación SaaS que les aparece en su “Service Marketplace”.
      Me lo pensaré para el futuro ya que es verdad que (si no lo haces por código en los eventos onSubscription) conlleva crear/eliminar las rutas.
      Un saludo

      Me gusta

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Salir /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Salir /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Salir /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Salir /  Cambiar )

Conectando a %s

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios .

Blog de WordPress.com.

Subir ↑

A %d blogueros les gusta esto: