Mejoras en el despliegue y operación de la plataforma Sofia2

Captura de pantalla 2017-05-25 a las 17.14.08

 

Durante las últimas releases de Sofia2 se han ido introduciendo mejoras en los despliegues de la plataforma, apoyándose cada vez más en los principios DevOps.

 

La CI/CD se ha adaptado al despliegue con contenedores y se han introducido algunas características nuevas de Jenkins, mejorando significativamente la parte Dev de Sofia2, tales como:

 

  • Pipelines declarativos, estos estrechan aún más la distancia entre los desarrollos y los despliegues mediante un DSL más accesible y/o legible e integrado con Docker.
  • BlueOcean, este nuevo plugin permite visualizar de manera más limpia cada uno de los stages o fases de los pipelines de Jenkins.

Captura de pantalla 2017-05-25 a las 9.51.45

Para la mejora de la parte Ops, cada uno de los módulos (ControlPanel, IoTBroker, Stream Process,…) se ha contenerizado con Docker y mediante Kubernetes se automatizan los despliegues de los mismos en los distintos nodos disponibles.

 

Kubernetes es un sistema Open Source de Google que permite automatizar despliegues apoyándose en la tecnología de contenedores, además, gracias al concepto de Replication Controller de Kubernetes se garantiza el auto escalado de cualquiera de los módulos, manteniendo constante el número de réplicas (pods) de un determinado módulo.

 

La accesibilidad entre los pods de distintos módulos en el cluster se consigue mediante servicios, que además se encargan de realizar el balanceo de carga entre todas las réplicas de un mismo módulo.

 

Captura de pantalla 2017-04-06 a las 15.55.43

Mejoras en el despliegue y operación de la plataforma Sofia2

Adaptador HL7

En esta release se añade una primera versión de un conector para dispositivos que envíen medidas en el estándar clínico HL7, en concreto para los mensajes de tipo ORU (Observation Result Unsolicited)

El Gateway expone mediante un servicio REST en el SIB una operación de envío de medidas con este estándar, transformándolo al formato json y al protocolo SSAP, para de esta manera ser almacenado en una ontología de Sofia2 (HL7ORU01) y devolver el ACK esperado por el dispositivo, también en el estándar HL7.

resthl7       collectionhl7

Adaptador HL7

Soporte a MongoDB como Base Datos Histórica Sofia2

Hasta ahora el motor por defecto de la BDH era Hadoop (+HIVE+Impala). Esta funcionalidad permite que la BDH sea una instancia de Mongo dedicada, esto permite el despliegue de la Plataforma en organizaciones en los que el uso de Hadoop pueda no ser apropiado

Para configurar el paso de la BDTR a la BDH siendo esta última una instancia de MongoDB, hay que añadir las propiedades necesarias que indican la instalación y propiedades de conexión de la  BDH MongoDB. Estas propiedades se encuentran en el fichero database.properties del módulo process.

properties

Además el proceso debe activarse mediante la propiedad

rtdb2hdb.mongodb.enabled=true

Finalmente hay que indicar en que momento desea lanzarse el paso mediante una expresión cron del estilo:

rtdb2hbd.mongodb.cron=0 06 08 1/1 * ? *

Estas propiedades se encuentran en el fichero rtdb2hdb.properties ubicado en el módulo process.

El proceso es exactamente igual que en el caso de Hadoop, es decir, se configura para una determinada Ontología mediante la consola web de Sofia2. Para ello a la hora de crear/modificar una ontología debemos indicar si queremos que los datos sean almacenados en una base de datos histórica, mediante el combo que indica si los datos a pasar son anteriores a uno, dos o tres días. Además podemos agruparlos mediante un script de agregación que deberá dar de alta un administrador de sistema. Por el contrario podemos indicar si simplemente queremos eliminarnos de la BDTR sin pasar a la BDH.

configuracionconsola

Una vez configurado el paso a la BDH, un proceso que se ejecuta de acuerdo a una expresión cron, lanza un comando de exportación de Mongo que almacenará en un fichero temporal los datos que queremos pasar.

mongoexport –db <base_de_datos> -h <host> –port <port> -c <ontologia> -o “<path><nombre_fichero>.json.tmp” -q {‘contextData.timestamp’:{‘$lt’:{‘$date’:<fecha_configurada>}}}

Una vez realizado el export es necesario realizar un import de estos datos en la BDH, mediante el comando “mongoimport” de Mongo.

mongoimport –db <base_de_datos> –host <host> –port <port> –collection <ontologia>  –file “<path><nombre_fichero>.json.tmp”

Soporte a MongoDB como Base Datos Histórica Sofia2

UI de visualización del resultado de ejecución de procesos

Con la release 2.12 de Sofia2 se ha añadido al menú de Herramientas la opción de poder visualizar el estado de los procesos de la plataforma, como por ejemplo las reglas CEP o las reglas de Script.

menu_logprocesos

Con esta opción podremos ver detalles como el tipo de proceso, la hora de inicio y fin de ejecución, el usuario que creó el proceso (la definición de la regla CEP por ejemplo) la ontología asociada si la hubiere, el estado en el que quedó el proceso tras su ejecución , etc…

logprocesos

logprocesos_detalle

 

UI de visualización del resultado de ejecución de procesos

API JMS accesible desde reglas

Una de las características menos “visible” en la release 2.11 de Sofia2 es el API JMS. Este API es accesible desde la consola de creación de reglas, añade a las operaciones ya existentes cuatro sencillos métodos para enviar mensajes, en formato json o xml, a una cola o a un topic de un Broker JMS*.

api JMS
api JMS

De esta manera podremos definir con una sencilla regla que, por ejemplo, para las instancias que lleguen de una determinada ontología (una alarma, una medida de un sensor, etc…) y que cumplan una determinada condición (que una medida supere un cierto umbral) las enviará a una cola disponible en el broker JMS (activeMQ por ejemplo)  en este caso un mensaje “Hola Sofia2”. Los mensajes encolados podrá ser consumidos por otro sistema para ser almacenados o representados visualmente.

regla
regla

broker

(*) En Sofia2 InCloud se ha disponibilizado un ActiveMQ accesible bajo petición

API JMS accesible desde reglas

Wizard para definición sencilla de reglas

Con la release 2.11 de Sofia2 se incluye un wizard cuyo fin es hacer más sencilla la operativa completa de creación de reglas (eventos CEP, Reglas CEP y reglas Scripting) con este asistente paso a paso nos va guiando de manera ordenada en la creación de reglas sin tener que navegar de un lado a otro de Sofia2.

Elegiremos primero el tipo de Regla:

splash

Una vez seleccionada el tipo de regla el asistente nos guía, por ejemplo:
Generar regla CEP: permite crear Eventos CEP y luego reglas CEP desde estos.

En el paso de creación de eventos, podremos crear tantos eventos como nos sean necesarios.

paso_uno_evento

De la misma manera en el paso de creación de reglas CEP podremos dar de alta varias de ellas.

paso_dos_regla

paso_dos_regla_varias

Generar regla scripting basada en una (o varias) reglas CEP, estas pueden haber sido creadas con el asistente o podrán ser aquellas ya disponibles en la plataforma. A partir de una regla CEP me permite crear una regla script que se lanzará cada vez que se genere un evento CEP,

paso_tres_script_cep

También podemos crear reglas scripting temporizadas o basadas en las ontologías existentes en la plataforma

paso_tres_script_ontologia

paso_tres_script_temporizado

Una vez finalizada la creación de una regla el asistente nos dará la opción de finalizar o de volver al inicio y crear otra regla.

finalizar

Las Reglas creadas se ven en las opciones correspondientes de menú:

menu

Wizard para definición sencilla de reglas

Nuevas funcionalidades en el editor de Reglas

Con la release 2.10 de Sofia2 se han añadido nuevas funcionalidades al editor de reglas, además de un nuevo theme que resalta las palabras reservadas del lenguaje. de esta manera la codificación de reglas en lenguaje Groovy resulta mucho más sencilla.

– Operaciones disponibles: Se disponen aquellas operaciones existentes en la plataforma mediante un combo, a la vez que se muestran los métodos de la operación seleccionada mediante un combo o una caja de texto que mostrará los métodos gracias a la ayuda de texto predictivo.

operaciones

textopredictivo

– Generación de código automático para instanciar operaciones e invocar métodos.

instanciación operaciones

– Mediante la combinación de teclas “ctrl+espacio” se muestran los objetos declarados en el editor.

objetos existentes

– Función “autocompletar”: Con la misma combinación de teclas “ctrl+espacio” y siempre antes de un objeto seguido de un punto, podremos visualizar todos los métodos de ese objeto, así como elegir el que más nos interese para invocarlo.

autocompletar autocompletar

– Auto cerrado de paréntesis, llaves y corchetes.

autocerrado

Nuevas funcionalidades en el editor de Reglas