Nuevas demostraciones – Visualización de información de Gasolineras

Se han añadido nuevas demostraciones de visualización para Sofia2.

Desde la página principal de sofia2 se puede acceder a dos versiones: normal y desarrollador (dev):

Featured image

A continuación explicaremos el funcionamiento de la versión de desarrollo (la otra es una versión simplificada):

En la primera sección “Datos de conexión” se pueden ver los datos de conexión con el KP, así como introducir queries manuales (SQL o Nativo) y ver el resultado en el panel “Log”.

Featured image

La siguiente sección nos permite hacer búsquedas de gasolineras dentro de un radio desde un punto establecido y/o hacer búsquedas por provincia, localidad y calle:

Featured image

Para establecer el punto y radio basta con hacer click en el mapa y ajustar las medidas:

Featured image

Una vez se han cumplimentado los criterios deseados para la búsqueda, haciendo click en “Generar Query” podremos ver la query resultado generada. Si no se quieren hacer más cambios sobre la query (se permite modificación de la misma) haciendo click en “Enviar query” se envía dicha consulta y se muestran los resultados en el panel “logs”:

Featured image

Por último, hacemos click en “Generar Charts” y podremos ver las gasolineras marcadas en el mapa, así como una gráfica de barras donde se muestran las gasolineras ordenadas por precio del carburante seleccionado:

Featured image

Si hacemos click en una marca de gasolinera (o en una barra del gráfico inferior) se nos mostrará la ruta a seguir y el tiempo y kilometros de recorrido para llegar a ella.

Featured image

Además se mostrará el precio de todos los carburantes de la gasolinera seleccionada en un gráfico de radar:

Featured image

Por último se mostrará una tabla con las 100 gasolineras más caras y las 100 más baratas de toda España para el día seleccionado (hoy por defecto):

Featured image

Nuevas demostraciones – Visualización de información de Gasolineras

Soporte creación de índices desde la consola

En la última versión de Sofia2 se ha incluido una nueva funcionalidad que permite a usuarios con ROL ADMINISTRADOR gestionar los índices de las ontologías a través de la Consola BDTR y BDH del menú de Herramientas .

A través de esta nueva funcionalidad se podrán crear, modificar o eliminar índices para una colección en modo nativo, es decir con la sintaxis de MongoDB.

Se podrán crear índices simples, compuestos y con opciones a través de utilizar la operación ensureIndex()

  • Índices simples (de un solo campo):

db.SensorTemperatura.ensureIndex( { “SensorTemperatura.identificador”: 1 } )

db.SensorTemperatura.ensureIndex( { “SensorTemperatura.medida”: -1 } )

  • Índices compuestos (varios campos):

db.SensorTemperatura.ensureIndex( { “SensorTemperatura.identificador”: 1,”SensorTemperatura.medida”:1 } )

  • Índices compuestos y con opciones:
 db.SensorTemperatura.ensureIndex( { "SensorTemperatura.identificador": 1,”SensorTemperatura.medida”:1 },{unique: true, sparse: true })

Para eliminar un índice, se hará uso de la operación dropIndex y como parámetro se deberá indicar el nombre del índice, sin comillas dobles, un ejemplo:

db.SensorTemperatura.dropIndex(SensorTemperatura.identificador_1);

Y finalmente para consultar los índices se hará uso de getIndexes() que nos retornará todos los índices para la ontología indicada.

db.SensorTemperatura.getIndexes();

Para aquellos que lo desconozcan, una ontología equivale a una colección en MongoDB y la estructura en la que se crean los índices es como la que se muestra en la imagen

Tanto al crear un índice como al eliminarlo en pantalla se mostrarán los índices que tiene la ontología tras realizar de esas operaciones

Soporte creación de índices desde la consola

Nuevo API SSAP Python

Una de las novedades de la versión 2.14 de Sofia2 es la nueva implementación Python del API SSAP. Está escrita para soportar indistintamente intérpretes de Python de las ramas 2.7.x y 3.x, y se comunica con la plataforma utilizando websockets.

Para instalar el API, tendremos que contar con una instalación de Python 2.7.x o 3.x operativa, y también será necesario tener instalado el gestor de paquetes pip.

El proceso de instalación es muy sencillo:

  • Instalamos las dependencias del API:

$ pip install ws4py
$ pip install six

  • Descargamos y descompimimos el API desde sofia2.com > Desarrollo.
  • Incorporamos el API a nuestra instalación de Python, ejecutando el script ssap-python/setup.py:

$ python setup.py install

A partir de este momento, ya podremos usar el API desde nuestros scripts. Por ejemplo, esta clase de prueba cuenta con métodos que envían mensajes SSAP JOIN, LEAVE e INSERT:

Para probarla, bastará con usar un método __main__ como el siguiente:

Método __main__ que usa la clase de prueba
Método __main__ que usa la clase de prueba

Al ejecutarlo, se imprime esta traza:

Ejecución de la prueba del API Python
Ejecución de la prueba del API Python

Como podemos observar, nuestro ejemplo ha abierto una sesión con un mensaje SSAP JOIN, ha enviado datos con un mensaje SSAP INSERT y se ha desconectado utilizando un mensaje SSAP LEAVE.

Por claridad, en este post hemos utilizado un ejemplo muy sencillo, pero el API Python cuenta con una batería completa de pruebas unitarias que muestran el funcionamiento de todos sus métodos. Estas pruebas se encuentran en el directorio ssap-python/src/ssap/tests/websockets.

Nuevo API SSAP Python

Sofia2 certificada como solución MongoDB Enterprise / Sofia2 certified on MongoDB Enterprise

Tras varios meses de trabajo el pasado viernes se completó el proceso de certificación de Sofia2 como solución MongoDB Enterprise 2.6 en el ámbito M2M/IoT.

After a few months of work last Friday Sofia2 certification process was completed as MongoDB Enterprise 2.6 solution in the area M2M / IoT.

Sofia2 certificada como solución MongoDB Enterprise / Sofia2 certified on MongoDB Enterprise

Sharding de ontologías en la BDTR

En la release 2.14 de Sofia2 hemos añadido una nueva funcionalidad muy útil para aumentar el rendimiento de la plataforma: el sharding (o “particionado”) automático de ontologías en la BDTR.

¿Pero por qué implementar el sharding manualmente cuando MongoDB ya nos lo ofrece? Fijaos en la configuración de un shard típico:

Shard típico de MongoDB
Shard típico de MongoDB

Como veis, para utilizar sharding necesitamos, como mínimo,

  • tres servidores de configuración
  • tres replica sets, con tres máquinas cada uno.
  • un proceso balanceador, mongos.

Así, para distribuir los datos entre tres shards, necesitamos la friolera de 13 máquinas, y algunas deberán estar en datacenters distintos. En muchos casos, la dificultad del mantenimiento y el propio coste de las máquinas hacen que esta solución no sea asumible.

Otra alternativa para mejorar el rendimiento de MongoDB es utilizar muchas colecciones pequeñas en el mismo servidor. Por el simple hecho de tener menos registros, todas las operaciones que se hagan sobre esas colecciones (como inserciones, borrados,…) serán mucho más rápidas. Además, el mantenimiento de los índices será mucho menos costoso, ya que el tamaño de estos será mucho menor.

Esto es precisamente lo que buscamos con el sharding automático de ontologías en la BDTR. Al activarlo, para cada ontología se generarán n colecciones en la BDTR de acuerdo a dos posibles estrategias:

  • usar la identificación de usuario, de forma que haya una colección para cada usuario que manipule la ontología.
  • usar la instancia del KP, de forma que haya una colección para cada instancia de KP que manipule la ontología.

La estrategia que se usará para particionar los datos puede configurarse editando la ontología en modo administrador (en la sección Configuración BDTR y BDH Particionar datos en BDH):

Configuración del sharding en modo administrador
Configuración del sharding de ontologías (en modo administrador)

El sharding es totalmente transparente para el usuario, y se consigue parcheando las operaciones que actúan sobre la BDTR antes de enviárselas a MongoDB. Por ejemplo, un mensaje SSAP QUERY que recupera algunos registros de la ontología TestSensorTemperatura contendrá esta query:

db.TestSensorTemperatura.find({…})

Si los datos de la ontología TestSensorTemperatura están particionados en la BDTR por el identificador de usuario y el KP que ha enviado el mensaje es propiedad del usuario lbarrios, al final se enviará esta query a MongoDB:

db.TestSensorTemperatura_lbarrios.find({…})

Como habréis notado, cuando el sharding está activo no es posible consultar sobre todas las colecciones asociadas a una misma ontología, pero esta limitación puede eliminarse fácilmente si es necesario.

Gracias al sharding de ontologías, es posible aumentar inmediatamente el rendimiento de una instalación de Sofia2. Además, de cara a la esperadísima versión 2.8 de MongoDB, el sharding de ontologías mejorará aún más el rendimiento. Hasta la versión 2.6 de MongoDB, los bloqueos de lectura y escritura se aplican sobre toda la BDTR. En la versión 2.8, estos bloqueos se aplicarán a nivel de colección, y puesto que el sharding hace más difícil que dos KPs hagan peticiones sobre una misma colección, el número total de bloqueos se reducirá drásticamente.

Sharding de ontologías en la BDTR

Soporte MQTTS en Sofia2.com

En la Release 2.14 de Sofia2 se ha añadido al gateway MQTT seguridad sobre SSL. De manera que es posible establecer una conexión cifrada entre las App Sofia2 (KP) que utilizan el protocolo MQTT y los SIBs de Sofia2.com.

Los gateways MQTTS de Sofia2.com utilizan la clave privada del certificado de la plataforma Sofia2.com. Para obtener el certificado de clave pública y poder establecer conexiones desde Apps Sofia2, es necesario solicitarlo a los administradores de la plataforma a través de la dirección de correo plataformasofia2@indra.es o bien exportarlo desde el navegador tras haberlo descargado entrando en https://sofia2.com. (Por ejemplo, en Firefox es posible desde Opciones>Avanzado>Certificados>Servidores y exportando el certificado de sofia2.com)

Los puertos expuestos en Sofia2.com para aceptar conexiones MQTTS son:

· 8883: Puerto MQTTS balanceando a los distintos nodos del SIB

· 8884: Puerto MQTTS de la Instancia 1 del SIB

· 8885: Puerto MQTTS de la Instancia 2 del SIB

Para establecer una conexión MQTTS con Sofia2.com desde una App Sofia2 (KP) es necesario que el programador realice en el lenguaje de programación de su aplicación una conexión TCP sobre SSL hacia el puerto correspondiente, utilizando la clave publica del certificado.

En el caso de Apps Sofia2 programadas con el API Java, esta tarea es simplificada por el API informando:

· Variables del keystore con la clave pública a la JVM:

o -Djavax.net.ssl.keyStore: Con la dirección del keystore con la clave publica de sofia2.com

o –Djavax.net.ssl.keyStorePassword: Con la password del keystore.

· Indicando en el prefijo de la url que la conexión es de tipo SSL:

o ssl://sofia2.com

Como ejemplo, vamos a modificar el Test descargable en el API para que conecte por MQTTS:

1. Primero creamos un keystore de tipo JKS importando la clave pública del certificado de sofia2.com
$> keytool –import –file sofia2.com –alias –trustcacerts –keystore mqttkeystore.jks –storepass changeit

2. Añadimos a los argumentos de la JVM las siguientes variables:

3. Indicamos a la configuración de conexión la url con protocolo ssl:// y el puerto MQTTS:

Soporte MQTTS en Sofia2.com