Funcionalidad soporte multi-BDTR

image0141

En la Release 4.2 de Sofia2 IoT Platform se introdujo el concepto de multi-BDTR. Hasta ahora una instalación de Sofia2 sólo podía funcionar con una BDTR y con una BDH, es decir, si se usaba MongoDB como base de datos BDTR entonces todas las ontologías se almacenaban en esta base de datos.

En esta versión hemos añadido la capacidad de que en una misma instalación de Sofia2 se puedan gestionar diferentes BDTRs, de esta forma cuando creamos una ontología podemos seleccionar la base de datos sobre la que queremos que trabaje. Esta opción la podemos encontrar en Opciones Avanzadas > Seleccionar instancia BDTR en todas las pantallas de creación de ontología:

image0132

Esta funcionalidad nos permite tener tanto bases de datos relacionales como no relacionales en nuestra instancia de Sofia2. Para trabajar con bases de datos relacionales ,como puede ser un PostgreSQL se ha añadido una nueva funcionalidad que nos permite crear ontologías sobre este tipo de base de datos, a la cual podemos acceder desde el menú Ontologías > Crear Ontología > Crear Ontología en Base de Datos Relacional

image006

Lo que nos llevará al formulario para crear la ontología paso a paso, donde nuevamente en Opciones Avanzadas encontraremos el listado de BDTRs relacionales disponibles en la instancia de Sofia2:

post

La configuración de todas las BDTRs las realiza el administrados del sistema de la instancia de Sofia2, para ello se ha creado un nuevo rol SYS_ADMIN. Si accedemos a la instancia de Sofia2 con este rol podremos ver en un primer momento un listado de las BDTRs disponibles para la instancia:

post2

Si accedemos a Crear Instancia tenemos un formulario con todos los campos necesarios para configurar nuestras BDTRs:

post3

Cabe destacar que solo podemos tener una BDTR por defecto y que será en la cual se creen todas las ontologías si no seleccionamos ninguna BDTR en concreto en el apartado de Opciones Avanzadas de creación de ontologías.

Funcionalidad soporte multi-BDTR

Integración instancia GIT en GitLab con instancia de Plataforma Sofia2

asoc-git-01
Se ha incorporado una nueva funcionalidad a la plataforma consistente en la asociación de una instancia de SCM GIT sobre GitLab con la instancia de plataforma Sofia2 para poder utilizar dicho repositorio como repositorio SCM de nuestros desarrollos sobre plataforma, además de futuras incorporaciones de automatizaciones para la gestión de funcionalidades como la exportación e importación de configuración y datos, proyectos web, etc.
No todas las instancias de plataforma tendrán disponible la funcionalidad, puesto que está pensado más bien para su uso con instancias que se utilicen como entorno de desarrollo o pruebas, más que con instancias productivas. Para que la funcionalidad esté disponible se debe de habilitar por configuración en la propia instalación de la instancia.
Lo primero que hay que hacer para poder hacer uso de la funcionalidad es crear la asociación. Para ello, accedemos con usuario administrador a la consola de plataforma y en el menú de administración, pulsamos sobre la opción repositorio GIT
asoc-git-01
Y creamos la asociación:
asoc-git-02
Introducimos los datos de URL del repositorio GIT, usuario, password y el private token del usuario administrador para la integración y marcamos la integración como activa:
asoc-git-03
Para poder realizar el enlace correctamente en el repositorio GIT debe de existir un usuario “project_sofia2” (del que debemos conocer su password y el private token) con rol administrador y un grupo llamado “ProjectSOFIA2” con el usuario administrador anterior como propietario.
asoc-git-04asoc-git-05
Solo se permitirá una configuración de Repositorio GIT por instancia y su activación/desactivación, pero no el borrado:
asoc-git-06
En la ventana de visualización se pueden ver los proyectos existentes en el grupo “ProjectSOFIA2”
asoc-git-07
A partir de este paso, cuando un usuario crea un proyecto en Sofia2, automáticamente se crea un proyecto en el repositorio GIT dentro del grupo ProjectSOFIA2 y el usuario correspondiente al usuario Sofia2 que crea el proyecto como owner del proyecto y añadido al grupo, además de crear una estructura base de proyecto a partir de un template.
Creamos el proyecto en Sofia2 Control Panel:
asoc-git-08
Y se crea proyecto en GIT, en el grupo ProjectSOFIA2:
asoc-git-09
Cada proyecto creado en Git se define con:
asoc-git-10
Finalmente, se crean los usuarios asociados con el proyecto:
  • Un usuario con rol owner en Git para el usuario que crea el proyecto
  • Un usuario con rol developer en Git por cada usuario asociado al proyecto Sofia2
  • Todos los usuarios quedarán asociados al grupo de usuarios del proyecto
A partir de este paso, cuando se añaden usuarios al proyecto Sofia2 con repositorio asociado, se crean y añaden usuarios al repositorio y grupo en GIT.
     – Los datos de los usuarios de Git se tomarán de los datos de usuarios de Sofia2.
     – Datos de usuario en Sofia2: Usuario, Nombre Completo, Email
     – Datos de usuario en GitLab: Usuario, Nombre, Email
     – Contraseña: se envía link al mail desde el API de GitLab con contraseña autogenerada para repositorio.
Si un proyecto ya existiera previa a la asociación del repositorio GIT con la Plataforma se tendría que editar el proyecto para que se realizara todo el proceso igual que si se creara de cero con el enlace a GIT activado.

En posteriores versiones se evolucionará la funcionalidad con algunas mejoras:
  • Marcador a nivel de proyecto para indicar si se quiere asociar o no el proyecto a repositorio GIT.
  • Visualizado de datos de enlace a Git con los datos de Grupo/proyecto y usuarios en Git dentro de la ventana de proyecto.
  • Visualización datos básicos de información de repositorio: Branches, Tags, Files, Activity, Commits, Graph, Compare, etc.
  • Funcionalidades para poder guardar contenidos desde consola en dicho repositorio por cada usuario de proyecto. Se hará especifico en cada una de las funcionalidades, por ejemplo, export/import, proyecto web, notebooks, etc.
Integración instancia GIT en GitLab con instancia de Plataforma Sofia2

SOFIA2 Desktops

T_21

The desktop of the platform constitutes the access point of any user of the platform to any of the applications provided in the project and to which the user has access.

At the platform level, different desktops can be created so that a user can access several desktops, each with different purposes and applications.

Desks are Web applications that act as containers for other applications. A platform administrator controls and configures which applications are accessible from each desk, associating them to the desktop from the platform’s own control panel.

At the same time each application administrator, giving it as a project on the platform itself, will control which users have access to the application.

So that each desk, performs the control of access to users of the platform through a login screen, and depending on the permissions that that user has on each of the applications registered, will have access or not to the registered applications as desktop applications.

Next, we will explain how to create and use them.

Seguir leyendo “SOFIA2 Desktops”

SOFIA2 Desktops

Mejoras documentación de ontologías

 doc-ontologias-03
Se incluyen en la plataforma una serie de mejoras de cara a la documentación de nuestro modelo de dominio basado en ontologías.
La primera de ellas consiste en poder incluir una descripción a los atributos de una ontología en la pantalla de creación/edición de la misma y cuyo contenido quede incluido en el propio esquema JSON de ésta.
doc-ontologias-01doc-ontologias-02doc-ontologias-03doc-ontologias-04doc-ontologias-05
Se ha incluido en la pantalla de consulta de las ontologías una vista de documentación para mostrar solamente la información documental de una ontología en un formato más amigable que un json-schema y con posibilidad de exportar como pdf documental.
doc-ontologias-06doc-ontologias-07doc-ontologias-08doc-ontologias-09
En posteriores versiones se evolucionará la funcionalidad de creación de ontologías mediante modelado UML para poder modelar todas las entidades de un proyecto Sofia2 o Space en un único diagrama y poder representar relaciones lógicas entre ellas a nivel de espacio, generando las ontologías a partir de dicho modelo y de forma inversa poder obtener dicho diagrama a partir de los esquemas de las ontologías creados mediante otros modos y del esquema de relaciones. Con esta funcionalidad se dispondrá de una vista del modelo de dominio completo para un proyecto o Space pudiendo generar un reporte completo documental del mismo siempre actualizado.
doc-ontologias-10doc-ontologias-11
Mejoras documentación de ontologías

Gestión avanzada de dispositivos en Sofia2

En Sofia2 somos conscientes de que en los próximos años la importancia de la gestión de dispositivos conectados va a aumentar de forma considerable, sobre todo en el ámbito IoT. Es por ello que desde sus primeras versiones, Sofia2 proporciona una gestión de dispositivos integrada en la plataforma.

En anteriores Post ya hemos visto cómo se entiende en Sofia2 el concepto de dispositivo y de qué manera se realiza su gestión. Podemos repasar algunos conceptos básicos:

 

  • Spaces (Proyectos): Representa un entorno colaborativo virtual donde los usuarios pueden crear sus aplicaciones, por ejemplo creando Things, modelando sus entidades, aplicando algoritmos o creando visualizaciones.
  • Ontología (Entities): Una Entity (Thintology) representa el Modelo de Dominio que maneja una Thing.
  • ThinKP: Un ThinKP (en terminología Sofia2 hablamos de KP: Knowledge Processor o de ThinKP) representa a cada uno de los elementos que interactúan con la plataforma, bien publicando, bien consumiendo información.

En Sofia2 es este ThinKP el que puede representar desde un dispositivo sencillo a un Gateway o un Sistema Empresarial.

Sofia2 contaba ya con una gestión de dispositivos básica. Entre otras funcionalidades, se contemplaban:

 

  • Gestión ThinKPs activos (conexiones activas de dispositivos con la plataforma).

  • Gestión de Conexiones (conexiones físicas y lógicas y actuaciones sobre las mismas).

  • Gestión de Configuraciones SW (configuración del SW instalado en los dispositivos clientes).

  • Gestión de Assets (Inventariado de dispositivos).

En las últimas versiones de la plataforma dicha gestión se ha visto ampliada considerablemente.

 

  • Extensión del API de comunicación con la plataforma. Se han incorporado nuevas directivas:
    • Error: se utilizará para comunicar a la plataforma errores que se hayan producido en el dispositivo y que quieran registrarse en la plataforma.
    • Log: permitirá disponer de un log completo en la plataforma de las operaciones llevadas a cabo en el dispositivo.
    • Location: actualizará la ubicación del dispositivo para poder realizar un seguimiento sobre el mismo.
    • Status: mediante este tipo de mensaje el dispositivo podrá actualizar el estado en el que se encuentra y que quede registrado en Sofia2. Como estado entendemos un grupo de variables y sus valores (pueden extraerse del dispositivo en cuestión: memoria libre, uso de CPU,…).
    • La directiva Command está compuesta por dos operaciones de comunicación:
      • SubscribeCommand: Cualquier Instancia de ThinKP puede subscribirse a la recepción de comandos sin necesidad de tener sessionKey (a diferencia de las subscripciones normales). Desde Sofia2 recomendamos realizar esta suscripción siempre un dispositivo (ThinKP) inicie su actividad.
      • Command:
        • A través de esta operación es posible mandar mensajes de comando a cualquier instancia de ThinKP que se haya suscrito previamente.
        • Para realizar el envío de comandos es necesario estar autenticado en Sofia2 y disponer de una sessionKey correcta. De esta manera se evita el envío malicioso de comandos no autorizados. El mensaje de comandos tiene un campo llamado Args dónde pasar los argumentos necesarios al ThinKP sobre el que se quiera actuar. Ejemplos de uso serían:
          • Pedir a un dispositivo que se reinicie.
          • Pedir a un dispositivo que envíe su estado actual.

Mediante el envío de información a través de estos nuevos tipos de mensajes se obtendrá una visión centralizada del estado y ubicación de todos los dispositivos conectados a la plataforma en tiempo real. Se dispondrá de un histórico en el que analizar los distintos estados por los que haya pasado cada uno de ellos así como los problemas que se hayan detectado. Además se podrá actuar remotamente sobre dispositivos enviándoles comandos a ejecutar.

 

  • Unificación en la consola de toda la operativa referida a dispositivos (ThinKPs)

En la consola de administración y configuración de la plataforma, se ha añadido una opción de menú que engloba toda la gestión asociada a ThinKPs.

 

– Mis ThinKPs: Permite dar de alta nuevos ThinKPs en la plataforma, definiendo el conjunto de datos sobre los que trabajaran, así como modificar o eliminar los ya existentes. Además se permite gestionar sus instancias y sus tokens de conexión con la plataforma.

Estado ThinKPs: Nueva opción que permite visualizar el estado de cada uno de los ThinKPs conectados con la plataforma (la veremos más en detalla a continuación en este post).

– ThinKPs Conectados: Listado de ThinKPs conectados con la plataforma así como detalles de las mismos (identificación, clave de sesión, fecha última conexión).

– Contenedor de ThinKPs: Permite desplegar ThinKPs en la propia plataforma, totalmente gestionables.

– Config SW en ThinKPs: Para asociar distintas versiones de SW y parámetros de configuración con ThinKPs o InstathinKPs.

Además como opción de administración se incluye:

– Gestión de conexiones: permite monitorizar y actuar sobre las conexiones, tanto físicas como lógicas que establecen los distintos ThinKPs con la plataforma.

 

  • Nuevo UI para la gestión centralizada de información proveniente de dispositivos (Estado ThinKPs): Esta opción muestra una lista de KPs conectados con la plataforma, así como un listado con la última información recibida desde los mismos.

En un primer listado se mostrarán las instancias de ThinKPs conectadas con la plataforma.

Si se selecciona una de las instancias de la tabla, los componentes de la pantalla quedarán filtrados, mostrando información relativa únicamente a esa instancia de ThinKP seleccionada.

A su lado se mostrará la posición de cada uno de ellos sobre un mapa. Esta información provendrá de los mensajes de tipo LOCATION que cada uno de los dispositivos ha ido enviando a la plataforma. Al mantenerse un histórico de esta información, se podrá mantener trazabilidad sobre la ubicación de cada uno de los dispositivos.

Si se sitúa el cursos sobre uno de los puntos del mapa, se ofrecerá información adicional, como la precisión, velocidad y rumbo del dispositivo.

La opción Ver en detalle, despliega un mapa a pantalla completa para una mejor visualización.

Incorpora un componente de búsqueda para filtrar entre los dispositivos mostrados y el número de dispositivos a mostrar.

Además de este componente visual que permite la localización de los dispositivos, se incorporan tres listados en los que se mostrará información proveniente de los mensajes de ERROR, LOG y STATUS recibidos desde los dispositivos.

El listado de Mensajes de Error mostrará el contenido de los mensajes de ERROR recibidos. Se incluye un campo severidad que indicará la gravedad del mensaje recibido. Como niveles de ERROR están disponibles los siguientes:

 

  • DEBUG
  • INFORMATIONAL
  • NOTICE
  • WARNING
  • ERROR
  • CRITICAL
  • ALERT
  • EMERGENCY

Además se incluye el identificador de la instancia de ThinKP que ha enviado el mensaje, un código de error asociado, el contenido del mensaje de error y la fecha de envío. Tanto el código de error como el contenido del mensaje pueden ser definidos y construidos en el propio dispositivo, siendo configurables completamente por el usuario.

Se incluye además un enlace para mostrar el detalle del log de error. Mostrará, de forma similar al detalle de ubicaciones, un interfaz que permitirá filtrar por distintos criterios y mostrar los mensajes de error en un listado a pantalla completa.

El listado de mensajes de Log, mostrará los mensajes de tipo Log que los dispositivos hayan ido enviando a la plataforma.

El listado muestra como primera columna el nivel de log del mensaje enviado. Sus posibles valores son:

 

  • TRACE
  • DEBUG
  • INFO
  • WARN
  • ERROR
  • FATAL

Se incluye también el identificador de la instancia de ThinKP que ha enviado el mensaje, el contenido del mensaje y la fecha de envío.

Al igual que para la el listado de mensajes de error se incluye un enlace para mostrar el detalle del log que mostrará un interfaz que permitirá filtrar por distintos criterios y mostrar los mensajes de log a pantalla completa.

El listado de mensajes de Status mostrará los mensajes de estado que se han recibido desde los dispositivos. En este caso se mostrará la identificación de la instancia de Thinkp, así como el valor de las variables enviadas desde el dispositivo y la fecha de envío de las mismas.

Se dispone también del mismo enlace Ver en detalle con la misma funcionalidad que en el resto de listados:

 

  • El envío de mensajes de la directiva COMMAND se realiza mediante el api SSAP que proporciona la plataforma. El formato de dichos mensajes sería el siguiente:

SUBSCRIBECOMMAND

{“messageId”:null,”sessionKey”:null,”ontology”:null,”direction”:”REQUEST”,”messageType”:”SUBSCRIBECOMMAND”,”body”:”{“thinkp”:”TestKP”,”thinkpInstance”:” THINKP:INS “,”token”:”XXXXXXXXXXXXXXXXX”,”type”:”STATUS”}”}

COMMAND

{“messageId”:null,”sessionKey”:”XXXXXXXXXXXXXXX”,”ontology”:null,”direction”:”REQUEST”,”messageType”:”COMMAND”,”body”:”{“thinkp”:”TestKP”,”thinkpInstance”:”THINKP:INS”,”type”:”STATUS”,”args”:null}”}

El futuras versiones de la plataforma, se implementará un interfaz que permita el envío de mensajes a dispositivos.

Gestión avanzada de dispositivos en Sofia2