Sofia2 participa en el Laboratorio Virtual SESIAD

labVirtual

 

El Laboratorio Virtual de la Secretaría de Estado para la Sociedad de la Información y Agenda Digital (SESIAD) nace bajo la norma UNE 178104 “Sistemas integrales de gestión de la ciudad inteligente” con el objetivo de convertirse en una referencia de plataformas a nivel nacional e internacional, siendo un lugar de experimentación en el que empresas y desarrolladores puedan evaluar la compatibilidad de sus productos con diferentes plataformas Smart Cities.

 

labVirtual

 

Actualmente, plataformas que participan en el Laboratorio Virtual son Sofia2, de Minsait by Indra, SmartBrain de Cellnex y Thinking City de Telefónica. Éstas colaboran con SESIAD aportando su expertise y participando en la mejora de la interoperabilidad entre plataformas.

 

plataformas

 

Como vimos en IoT Data Models: Iniciativas y Sofia2 Data Modelexisten diferentes Iniciativas de estandarización de un Data Model en IoT. Un Data Model representa la estructura de tus datos y relaciones, y por tanto, organiza los elementos y estandariza como se relacionan unos con otros.

 

gsma1

 

Los Data Models GSMA y FIWARE se definen en JSON por lo que su representación como Ontología Sofia2 es inmediata. Vimos cómo se soportan y de qué manera tan sencilla se puede trabajar con estas entidades en Sofia2

 

Para conseguir una mejor interoperabilidad entre plataformas, se seleccionó NGSI 9/10 v2 como protocolo común para la Capa de Interoperabilidad. Vimos en este documento cómo se soportan y cómo consumir APIS modeladas conforme semántica FIWARE Data Model y publicadas en Sofia2 siguiendo el protocolo NGSI 9/10 v2.

 

En nuestra experiencia con el Laboratorio Virtual, además de realizar recomendaciones de nuevos atributos y modificaciones en los Data Model, hemos tenido la posibilidad de realizar una Prueba de Concepto (PoC) creando un Flujo de conexión y transformación de datos reales provenientes de Smart City A Coruña a GSMA/FIWARE Data Model en la Plataforma Sofia2.

 

En este ejemplo, se recogen datos de parkings de Smart Coruña y se ingestan en la plataforma Sofia2 a una Ontología. Cada vez que se recibe una instancia de esta ontología se lanza un Script que transforma estos datos adaptándolos a los Data Model y, consultándolos, vemos como efectivamente, se cumple con los Data Model.

 

flujodeconexion

 

También, en esta Prueba de Concepto, pudimos publicar estos datos por medio del API MANAGER de Sofia2, para posteriormente, ver que cualquiera con los debidos permisos, puede acceder a estos datos vía API, Curl o mediante el portal del Laboratorio Virtual.

 

consumodatos

 

Todo este proceso queda explicado en el post Adquisición, transformación y consumo de datos GSMA/FIWARE Data Model, y ha sido plasmado en el demostradorque, además de los datos de parkings, recoge datos de playas y museos.

 

demostrador

 

Puedes encontrar toda la información relativa al Laboratorio Virtual SESIAD aquí, así como todas las herramientas (Data Model, APIs, Tokens de seguridad, ejemplos…) necesarias para desarrollar en las plataformas cumpliendo con este modelo de interoperabilidad aquí

Sofia2 participa en el Laboratorio Virtual SESIAD

Integration of Lora and Sofia2

The communication between Lora and Sofia2 is done through the Multitech kit, formed by a test node that simulates the transmissions between a Lora device and a Gateway. This Gateway is needed to communicate this type of devices within the network and to send the captured data.

Kit
Used Multiconnect Conduit Kit.

Before the integration in Sofia2, the configuration between the Gateway and the test node is needed. In this brief tutorial, the steps to develop both configurations are collected, as well as all the information needed in Sofia2 to receive and store the data sent by Lora.

Configuration of Lora technology

  • Gateway configuration

    In order to use the gateway without any connection problem, an initial configuration is needed. First access to the Gateway must be done by means of serial communication, though Putty or another similar tool. Credentials needed to access by console are admin/admin. We can get its IP address with the command ifconfig. Once the IP address is known, we use the explorer to access to the Multitech webpage, where we introduce the same credentials again.

    Acceso web al gateway
    Access to the gateway webpage

    Once we start the session, and only by the first time that we do it, we will find an assistant that requires us to change the password, to select the timezone and to configure the IP address. When the last window appears, we must to configure the static IP, to select the corresponding Gateway, and to add the DNS servers.

    Once we finish the IP configuration, we will configurate Lora. To do that, we have to access to Setup -> Lora. Then, we will see a screen where we will see some configurable fields. Anyway, we only need to modify Name and Passphrases.

    Web
    Lora configuration
  • Node-Red configuration

    Once we activate the Node-Red application, we can access though the “App” menu of the webpage. By default, a program that receives Lora test data and shows them is designed, but we have to modify it in order to send the information to Sofia2. Image shows the final flow diagram, with the option “Sofia2 API WEB encoder” added. This option is uncharged of giving the desired format, adding a header to the send message and an output HTTP.

    Node-Red
    Node-Red diagram
  •  Configuration of test node

    To configurate the parameters of the test node is really simple. We only have to connect the mDot to the PC, by means of a USB, and to connect it to the test node with the kit programming cable. Then, we select the “Configuration” option in the mDot Box and we access to the device by using the Putty serial communication at 115200 baud.

    Tester
    Lora tester

    We only need to configure two parameters, using the following AT commands:

    AT+NI=1,<Name>

    AT+NK=1,<Passphrase>

    AT&W is used to save changes and  AT+Exit to exit the configuration mode.

    <Name> y <Passphrase> fields have to be the same values as used previously in the gateway.

    Configuración del tester
    Test node configuration

    In order to check if the configuration of both devices has been correct, we can do a test with the Node-Red.

Sofia2

Once that the devices have been configured, we have to develop the next steps in Sofia2. We need two new ontologies, an API rest and a rule script to deal with data. This section briefly explains with each of them.

  • Defining new ontologies

    First of all, we have to create an ontology that will receive the data sent by the test node. In this ontology we will insert raw data, without any previously filtering.

    ontologia
    Ontology example with raw data

    As we can see in the previous image, data usually have hexadecimal codifications, undesirable formats or information that needs to be treated before work with it. To do that, we have to create a rule script and a new ontology, where we will insert filtered data with the format required by the data base to correctly store it.

  • API REST

    Once the ontologies are defined, we will create an API REST of type POST, to insert data in the ontology of raw data. To do that, we have to go to the API MANAGER -> APIs, where we will find the option “New API”. There, we write the name of our API, and select the option “Publish Ontology as REST API” and the ontology desired. It is convenient to disable the maximum number of calls per minute, in order to assure that we do not lose information. At the end, we select the “POST” operation and create the API.

    API
    API

    The URL of the “Base Endpoint” field is the one that we have to insert in the Node-Red.

  • Rule script

    Once verified that the data sent directly from the device is correctly inserted in the desired ontology, we must create a script to filter them, extract all possible information and provide them with the corresponding format. To do this, we simply enter Rules-> Wizard New Rules and select the option “Generate rule using a template “. With this type of rules, each time the device sends new data to the ontology, the script will be executed and data will be processed and inserted into the final ontology.

  • Presentation on results

    We can use Sofia2’s visualization tools to show the data we’re storing quickly and easily. To do that, we have to go to the Visualization ->My Gadgets -> New Gadget, where we can select the optimal tool depending on our data. On the basic of measured data from Lora tester, the following representation could be interesting: to drawn the coordinates on a map or Signal to Noise Rate (SNR) along the time.

Mapa
Coordinates shows on a map
SNR
SNR representation.
Integration of Lora and Sofia2

Integración de Lora con Sofia2

Para llevar a cabo la comunicación entre un dispositivo Lora y Sofia2 hemos utilizado un kit de Multitech formado por un nodo de pruebas que simula las transmisiones de un dispositivo con tecnología Lora y un gateway, necesario para que estos dispositivos puedan comunicarse con la red y enviar así los datos que tomen.

Kit
Kit Multiconnect utilizado.

Es necesario configurar tanto el gateway como el nodo de pruebas antes de integrar estos dispositivos en Sofia2. En esta breve guía se recogen los pasos a seguir para ambas configuraciones y todo lo necesario en Sofia2 para poder recibir y almacenar los datos enviados por Lora.

Configuración de la tecnología Lora

  • Configuración del gateway

    Es necesario hacer una configuración inicial para poder usar el gateway sin problemas de conexión. La primera vez que accedemos a él lo haremos por comunicación serie usando Putty u otra herramienta similar. Las credenciales necesarias para acceder por terminal son admin/admin, y con el comando ifconfig podemos obtener su dirección IP. Una vez conocida esta IP, accedemos a ella mediante un navegador y nos encontramos con una página de Multitech donde podemos acceder usando de nuevo las mismas credenciales que antes.

    Acceso web al gateway
    Acceso web al gateway

    Nada más iniciar sesión, y solo la primera vez que lo hacemos, nos encontramos con un asistente que nos va solicitando en varios pasos modificar la contraseña, seleccionar la zona horaria y configurar la IP. Cuando nos sale esta última ventana debemos configurarla como IP estática, seleccionar el gateway correspondiente y añadir los servidores DNS.

    Una vez terminada la configuración de la IP, configuramos la parte de Lora. Para ello basta con acceder a Setup -> Lora. Aparece una pantalla como la que se muestra en la siguiente imagen donde hay muchos campos configurables de los cuales solo necesitamos modificar Name y Passphrases.

    Web
    Pantalla de configuración de Lora.
  • Configuración de Node-Red

    Una vez activada la aplicación de Node-Red podemos acceder a ella desde el menú “App” de la web. Por defecto viene diseñado un programa que simplemente recibe los datos del tester de Lora y los muestra por pantalla, pero debemos modificarlo para que la información se envíe a Sofia2.  En la imagen se muestra el diagrama de flujos final, en el que ha añadido la función “Sofia2 API WEB encoder”, encargada de dar el formato deseado y añadir una cabecera al mensaje a enviar y una salida HTTP (envío).

    Node-Red
    Configuración de Node-Red
  • Configuración del nodo de pruebas

    Configurar los parámetros del nodo de pruebas es realmente sencillo. Solamente hay que conectar el mDot vía USB a nuestro ordenador y conectarlo al nodo de pruebas con el cable de programación que viene en el mismo kit, de la forma que se muestra en la figura. Una vez hecho esto seleccionamos la opción “Configuration” en el mDot Box y accedemos al dispositivo utilizando la comunicación serie de Putty a velocidad 115200 baudios.

    Tester
    Tester de Lora utilizado

    Solamente es necesario configurar dos parámetros y para ello se utilizan los siguientes comandos AT:

    AT+NI=1,<Name>

    AT+NK=1,<Passphrase>

    AT&W para guardar los cambios realizados Y finalmente AT+Exit para salir del modo configuración.

    Los campos <Name> y <Passphrase> tienen que ser los mismos valores que los fijados anteriormente en el Gateway.

    Configuración del tester
    Configuración del tester

    Para comprobar si la configuración de ambos dispositivo ha sido correcta, podemos hacer una prueba con Node-Red.

Sofia2

Una vez configurada toda la parte de los dispositivos, solamente queda desarrollar la parte necesaria en Sofia2. Necesitamos dos nuevas ontologías, un API rest y un Script de reglas para tratar los datos. En este apartado se explica brevemente cómo crear cada uno de ellos.

  • Definir las nuevas ontologías

    Lo primero que debemos hacer es crear una nueva ontología que recibirá los datos que envía el nodo de pruebas. En esta ontología se insertarán los datos “en crudo” (data RAW) tal y como los envía el dispositivo, sin aplicar ningún filtrado previo.

    ontologia
    Ejemplo de ontología con datos sin tratar.

    Estos datos suelen contener tramas con codificaciones en hexadecimal, formatos no deseados o información que debe ser tratada antes de trabajar con ella. Por ello es necesario crear un Script de reglas y una nueva ontología donde se insertarán los datos ya tratados y con el formato requerido por la base de datos para su correcto almacenamiento.

  • Api Rest

    Una vez definidas las ontologías, crearemos una API REST de tipo POST a la ontología de datos sin tratar para que los datos puedan ser insertados en ella.

    Para ello debemos entrar en API MANAGER -> APIs donde encontramos la opción “Crear API”. Una vez aquí, escribimos un nombre para nuestra API, seleccionamos la opción “Publicar ontología como API REST” y la ontología deseada. Es conveniente desactivar el número máximo de peticiones por minuto para asegurarnos de que no perdemos información. Por último, seleccionamos la operación “POST” y creamos nuestra API.

     API
    Pantalla de creación de API

     La URL que aparece en el campo “EndPoint base” es la que se debe insertar en Node-RED.

  • Script de reglas

    Una vez comprobado que los datos enviados directamente desde el dispositivo se insertan de forma correcta en la ontología deseada, debemos crear un Script para tratarlos, extraer toda la información posible y dotarlos del formato correspondiente. Para ello simplemente entramos en Reglas->Wizard creación de reglas y seleccionamos la opción “Generar regla script ontología”. Con este tipo de reglas, cada vez que el dispositivo envíe nuevos datos a la ontología se ejecutará este script en el que se tratarán los datos para luego insertarlos en la ontología final.

  • Representación de resultados

    Utilizando las herramientas de visualización de Sofia2 podemos representar de manera rápida y sencilla los datos que estamos almacenando.  Para ello entramos en visualización ->Mis Gadgets-> Crear gadgets, desde donde podemos seleccionar el tipo de herramienta que más nos conviene en función de los datos. Atendiendo a los datos que se obtienen del tester de Lora, dos tipos de visualizaciones interesantes podrían ser la representación de coordenadas en un mapa y los valores de la relación señal a ruido (SNR) a lo largo del tiempo.

    Mapa
    Representación de coordenadas en un mapa

    SNR
    Representación del parámetro SNR
Integración de Lora con Sofia2

Generación Código Cliente en TEst&Doc APIS

54

Esta nueva utilidad consiste en un editor de código cliente para las APIs de las Ontologías en los principales lenguajes de programación, de esta forma solo tendremos que copiar el código que genera e insertarlo en nuestras aplicaciones.

 

Para ello debemos acceder a la API de la Ontología que queremos invocar. En este ejemplo será “AparcamientoPublicosMadrides”. Así que accederemos al menú de “API MANAGER”, y al submenú “APIs”:Image 003

Una vez aquí, vamos a la pestaña de “Mis Suscripciones”:Image 006

Y elegimos la API que queremos probar. Y clickamos sobre el botón “Test & Doc”:Image 009

Aquí tenemos información de la API y de las funciones que expone para su consumo. Nosotros vamos a elegir la función “getAll”:Image 012

A continuación se nos muestra la información referente a dicha función, y en la parte derecha aparecerá un menú desplegable llamado “Invocación al API”, en el elegiremos el lenguaje que queremos usar para invocar a la función:Image 015

Y esto generará el trozo de código necesario para invocar a la función. Solo tendremos que completar dicho código usando el token del usuario con el que estamos logados en la parte del “x-sofia2-apikey”:Image 018

He creado una pagina de ejemplo en HTML usando JQuery, para insertar el código que nos genera para el método del API,  el codigo HTML utilizado para el ejemplo seria:

<code>

<!DOCTYPE html>
<html>

<head>
<meta charset=”UTF-8″>
<title>Test API</title>
http://code.jquery.com/jquery-2.2.3.min.js

$(document).ready(function() {
$(“#myButton”).click(function() {

var settings = {
“async”: true,
“crossDomain”: true,
“url”: “https://sofia2.com/sib-api/api/v1/aparcamientospublicosmadrides/getAll&#8221;,
“method”: “GET”,
“headers”: {
“x-sofia2-apikey”: “********************”
}
}

$.ajax(settings).done(function (response) {
console.log(response);
var num = response.data.length;
$(“#apiTestDiv”).html(“Request URL: https://sofia2.com/sib-api/api/v1/aparcamientospublicosmadrides/getAll
Num Result: ” + num);

});

});
});

</head>

<body>
<button id=”myButton”>Test API</button>
</br>
</br>

</body>

</html>

</code>

 

resultado sería asi:

Image 028

Generación Código Cliente en TEst&Doc APIS

Despliegue y monitorización de Aplicaciones Spring Boot desde Control Panel de Sofia2

Introducción

Se ha integrado en el componente Contenedor de ThinKPs la posibilidad de desplegar aplicaciones basadas en Spring Boot. Para simplificar la integración de estas aplicaciones con Sofia2 se ha avanzado con la funcionalidad del módulo Sofia4Boot descrito aqui.

Las aplicaciones desplegadas dentro del contenedor de Sofia2 pueden ofrecer cualquier tipo de funcionalidad, incluso si no requiere de Sofia2 más que el contenedor y el sistema de gestión (en entornos desplegados tras un Nginx puede requerir cierta configuración, como abrir puertos).

Autorización

Las aplicaciones Spring Boot que usen en contenedor de ThinKPs necesitan proporcionar ciertos credenciales a la plataforma Sofia2. Para esto es necesario disponer de un ThinKP asociado a una ontología, y proporcionar como propiedad el token de acceso (ver sección de propiedades más adelante).

Creando una aplicación nueva

Para crear una aplicación basada en Spring Boot para Sofia2 se debe empezar con incluir en el POM las dependencias necesarias. Sofia2 dispone de un repositorio Nexus con las dependencias requeridas.

Atención! Sofia4Boot requiere de una versión de Java igual o superior a 1.8

Repositorio Nexus de Sofia2

<repositories>
     <repository>
    <id>SOFIA2</id>
    <url>http://sofia2.org/nexus/content/groups/public/</url>
    </repository>
</repositories>

Dependencias de Sofia4Boot

<dependency>
    <groupId>com.indra.sofia2.boot</groupId>
    <artifactId>sofia4boot</artifactId>
    <version>1.3</version>
</dependency>

Además hay que incluir las dependencias propias de Spring Boot (en esto no hay diferencias respecto a una aplicación SpringBoot típica). Es particularmente importante asegurarse que la aplicación que generamos es autocontenida (y ejecutable). Para esto lo más normal es usar el plugin de Spring Boot:

<build>
    <plugins>
        <plugin>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>
        </plugin>
    </plugins>
</build>

Durante el diseño de la aplicación hay que tener en cuenta que a la hora de arrancarla, el contenedor añadirá elementos adicionales a la configuración, como por ejemplo, limitación de memoria y propiedades de configuración. Un ejemplo de comando de arranque puede ser: -Xmx256m -Dspring.boot.admin.url=http://127.0.0.1:8101 -Dspring.boot.admin.prefer-ip=true. Esto incluye por ejemplo la configuración interna necesaria para registrar la aplicación en la instancia spring boot admin de Sofia2.

Clase principal

Para la clase principal usaremos una plantilla habitual para Spring Boot, a la que añadiremos el soporte para que se integre con el sistema de administración (esto se consigue añadiendo la anotación @EnableSpringBootAdminRegister).

@SpringBootApplication
@EnableSpringBootAdminRegister
public class S4BApp 
{
    public static void main (String [] args) {
        new SpringApplicationBuilder(S4BApp.class).run(args);
    }
}

La anotación @EnableSpringBootAdminRegister se encargará de registrar la aplicación en la consola, con lo que se podrá gestionar en una ventana de la consola de Sofia2:

Modelado de una ontología

La forma más fácil de modelar una ontología es descargarse las clases generadas desde el Control Panel de Sofia2. Para esto hay que ir a la opción de menú ‘Mis Ontologías’, buscar la ontología que se quiera, pulsar sobre el botón ‘Ver Ontología’ (con un icono representando un ojo), y al final de la ventana deberemos ver un botón con el texto ‘Clase Java de la Ontología’. Esto nos descargará un fichero comprimido con las clases de la ontología.

Esto también puede hacerse a mano. Un ejemplo de modelado de una ontología sencilla sería la siguiente:

Modelo de la ontología de ejemplo

{
    "$schema": "http://json-schema.org/draft-04/schema#",
    "title": "level Schema",
    "type": "object",
    "required": [
        "Level"
    ],
    "properties": {
        "Level": {
            "type": "string",
            "$ref": "#/datos"
        }
    },
    "datos": {
        "description": "descripcion",
        "type": "object",
        "required": [
            "date"
        ],
        "properties": {
            "value": {
                "type": "integer"
            },
            "date": {
                "type": "string"
            }
        }
    }
}

Y un ejemplo de instancia:

{
    "Level": {
        "value": 1,
        "date": "string"
    }
}

Las clases Java de modelado serían:

Modelo de datos

public class Level {

    private String date;
    private Integer value;

    public Level() {

    }

    public Level(String date, Integer value) {
        this.date = date;
        this.value = value;
    }

    public String getDate() {
        return date;
    }

    public void setDate(String date) {
        this.date = date;
    }

    public Integer getValue() {
        return value;
    }

    public void setValue(Integer value) {
        this.value = value;
    }
}

Y como la ontología tiene un nivel adicional para controlar siempre los valores, tendremos que incluir un wrapper

Envoltorio de ontología

public class LevelOntology extends Ontology<Level> {

    @JsonProperty("Level")
    private Level level;

    public LevelOntology () {}

    public LevelOntology (String date, Integer value) {
        level = new Level(date, value);
    }

    @Override
    public void setData(Level level) {
        this.level = level;
    }

    @Override
    public Level getData() {
        return level;
    }
}

Acceso al repositorio de la ontología

Para operar con la ontología disponemos de un conjunto de anotaciones que nos autogeneran el código de operación necesario. Un ejemplo de repositorio para la sencilla ontología del ejemplo anterior:

@Sofia2Repository("level")
public interface LevelRepository {

    @Sofia2Query("select * from level")
    List<LevelOntology> findAll ();

    @Sofia2Query("select * from level where Level.value=0")
    List<LevelOntology> findAllZeros ();

    @Sofia2Query("select * from level where Level.value=$value")
    List<LevelOntology> findAllWhereValueMatches (@Param("$value") Integer value);

    @Sofia2Insert
    SofiaId save(LevelOntology levelOntology);

    @Sofia2Query("db.level.remove({\"Level.value\":$value})")
    SofiaIds deleteWhereValueMatches(@Param(value = "$value") Integer value);

    @Sofia2Delete
    List<SofiaId> delete(String id);
}

Este repositorio no tiene código, es sólo un interfaz, siendo la librería de Sofia4Boot la encargada de generar y registrar en el contexto de spring la clase de implementación necesaria, con lo cual ya podremos disponer de ella de la forma habitual en spring:

@Autowired private LevelRepository levelRepository;

Añadiendo funcionalidad

Para este ejemplo, simplemente voy a hacer que cada n minutos se genere un nuevo valor aleatorio para la ontología. Para esto implementamos un servicio proveedor de valores que se encargue de hacer inserciones en la ontología:

@Service
public class Provider {

    private static final Logger log = LoggerFactory.getLogger(Provider.class);
    private Random random = new Random();

    @Autowired
    private LevelRepository levelRepository;

    public void sendRandomMessage () {

        try {
            // --- create new level value
            Instant now = Instant.now();
            Integer value = random.nextInt(10);
            LevelOntology levelOntology = new LevelOntology(now.toString(), value);
            log.info("Inserting data ontology: {}, ", levelOntology);
            // --- insert a random value
            SofiaId id = levelRepository.save(new LevelOntology(now.toString(), value));
            log.info("Created new record with value '{}' and id '{}'", value, id.getId().getOid());
        } catch (Exception e) {
            log.warn("Captured exception running app", e);
        }
    }
}

Y para que se ejecute cada intervalo genero un job con un planificador (un scheduler) que arranque cuando la aplicación haya terminado de cargarlo todo:

@Configuration
public class JobConfig implements ApplicationListener<ContextRefreshedEvent> {

    private final Logger log = LoggerFactory.getLogger(JobConfig.class);
    private final ScheduledExecutorService scheduler = Executors.newScheduledThreadPool(1);

    @Autowired
    private Config config;
    @Autowired
    private Provider provider;

    @Override
    public void onApplicationEvent(ContextRefreshedEvent contextRefreshedEvent) {

        log.info("Scheduling tasks ({} minutes)", config.getIntervalInMinutes());
        Runnable task = new Runnable() {
            @Override
            public void run() {
                provider.sendRandomMessage();
            }
        };

        Integer interval = config.getIntervalInMinutes();
        scheduler.scheduleAtFixedRate(task, interval, interval, TimeUnit.MINUTES);
    }
}

Para cargar la configuración estamos usando una clase Java mapeada por Spring con un fichero de configuración:

@Configuration
@ConfigurationProperties(prefix = "s4b")
public class Config {

    // el valor por defecto es 1, y la property se mapea contra 's4b.intervalInMinutes'
    private Integer intervalInMinutes = 1;

    public Integer getIntervalInMinutes() {
        return intervalInMinutes;
    }

    public void setIntervalInMinutes(Integer intervalInMinutes) {
        this.intervalInMinutes = intervalInMinutes;
    }
}

Configuración de la aplicación

A parte de la configuración habitual de Spring, existen propiedades adicionales referentes a Sofia4Boot, y además están las propias de nuestra aplicación.

La configuración específica de Sofia4Boot que nos aplica está referida a continuación:

Propiedad Valor de ejemplo Descripción
sofia2.host sofia2.com El host del servicio MQTT
sofia2.port 1884 El puerto para MQTT
sofia2.kp levelkp El kp al que se asocia la aplicación
sofia2.instance levelkp-demo El nombre de esta instancia de thinkp
sofia2.token 5118bt0acc2e464782dfwb52af582h9z El token de autorización del thinkp
sofia2.mqtt false Decide si se utiliza rest (false) o mqtt (true)
sofia2.endpoint http://sofia2.com/sib/services/ssap La URL del endpoint SSAP de Sofia2

Las propiedades propias de este ejemplo, junto con las de Spring Boot:

Propiedad Valor de ejemplo Descripción
logging.file ${spring.application.name}.log El nombre del archivo de logs a generar
server.port 0 Si fuera necesario, el puerto en el que se quiere arrancar el servicio. Esto requiere actualizar la configuración de Nginx
management.security.enabled false Esta property se asegura que se utiliza el sistema de autenticación de sofía, y no el que tiene spring boot admin por defecto
s4b.intervalInMinutes 5 inserta un valor nuevo a la ontología cada 5 minutos

Desplegando en el Contenedor de ThinKPs

Para desplegar nuestra aplicación dentro del contenedor de ThinKPs de Sofia2 deberemos haber completado los siguientes pasos:

  1. Generar una ontología en la plataforma, o seleccionar una que ya esté disponible (puede estar vacía si no se necesitan datos).
  2. Crear un KP, y generar un token, que se usarán para autorizar a nuestra aplicación (como cualquier otro dispositivo).
  3. Implementar nuestra aplicación y disponer del archivo ‘jar’ para desplegarlo.

Hecho esto, accedemos a la consola de Sofia2, menú ‘Contenedor ThinKPs’, y una vez allí haremos click en el botón con el texto ‘Nuevo ThinKP en contenedor’. Rellenamos la ventana que nos muestra la consola asegurandonos de:

  • Marcar el tipo de aplicacion como ‘Aplicación Spring Boot’
  • Seleccionar un token de autenticación (que coincida con el que incluimos en la configuración de nuestra aplicación!).
  • Cargamos nuestro archivo jar
  • Seleccionamos un nombre para nuestro contenedor, asegurandonos de incluir la extensión ‘.jar’

Un ejemplo:

Cuando termine (según nuestra conexión y el tamaño del JAR puede tardar un poco), deberíamos ver una ventana con la descripción parecida a la siguiente:

Aquí tenemos el botón que nos permite arrancar nuestra aplicación (por defecto están paradas nada más crearlas).

Spring Boot Admin

Una vez nuestra aplicación está arrancada y si está configurada correctamente, pasado un rato deberíamos poder verla registrada en el servicio de administración de Spring Boot Admin, en el menú ‘ThinKPs -> Administración de Spring Boot’, como puede verse a continuación:

Pulsando sobre el botón ‘Details’ podemos ver más detalles acerca de nuestra aplicación, como por ejemplo:

Despliegue y monitorización de Aplicaciones Spring Boot desde Control Panel de Sofia2

Notebooks Procesando y representando datos en un mapa Leaflet con los Notebooks Sofia2

Los Notebooks Sofia2 (basados en el proyecto open-source Apache Zeppelin) permiten a los científicos de datos crear diferentes modelos y algoritmos desde el Control Panel de la plataforma Sofia2. Desde este entorno web los Data Scientists pueden cargar datos a HDFS, procesarlos con Spark, Spark o Python, consultarlos con HIVE, visualizarlos de diferentes formas y además de todo esto manejar las ontologías Sofia2 desde este entorno.

En este ejemplo de uso de los Notebooks vamos a ver cómo traernos un fichero de un sitio externo, procesarlo con Spark y representar los datos procesados en un mapa OpenStreetMap con Leaflet.

Concretamente estamos hablando de un fichero que ofrece el servicio OpenData del gobierno francés (https://www.data.gouv.fr/fr/) y que contiene los datos de las estaciones de recarga eléctrica de Francia

https://www.data.gouv.fr/fr/datasets/fichier-consolide-des-bornes-de-recharge-pour-vehicules-electriques-irve/

El fichero tiene este aspecto:

Comenzaremos por descargar el fichero hacia el directorio home de nuestro usuario:

Lo siguiente es subir este fichero de nuestro directorio local al sistema de ficheros HDFS de nuestro cluster Hadoop

Una vez en HDFS ya puedo manejar los datos con Spark, en este caso para procesar el CSV usaré la librería com.databricks.spark-csv. Para cargarla en el classpath de Spark lo más sencillo es hacer esto:

Y de esta forma tan sencilla puedo convertir el CSV almacenado en HDFS (load(“/examples/IRVE-201510.csv”)) a un DataFrame (df) y de ahí a una tabla persistente (df.write.saveAsTable)

Y una vez tengo la tabla ya puedo consultar los datos de esta de forma muy sencilla:

Además de representarlos en diferentes formatos:

Finalmente haremos la consulta que queremos representar en el mapa:

Tras esto voy a convertir los datos de la consulta a JSON para poder representarlos fácilmente, para esto usaré la librería Gson.

Haré la consulta, mapeando las columnas de los datos obtenidos a los nombres que quiero usar en el JSON:

Los datos tienen esta pinta:

Y ya solo me queda hacer el HTML+JS para pintar mi mapa, en Zeppelin para incrustar un HTML basta con empezar el párrafo con:

Mi HTML tiene este aspecto:

En él podemos ver que estamos usando Thunderforest como Layer (y un apikey que debéis generar en http://www.thunderforest.com/docs/apikeys/ para evitar la marca de agua).

El código que maneja mi JSON con las estaciones es este:

Que genera un botón Show me the map que al pulsar muestra el mapa con un marker para cada estación:

Además de ver la representación en el propio Notebook si en las opciones del párrafo selecciono Link this paragrah:

Esto me genera un URL en la que veo el mapa:

https://sofia2.com/console/notebook/#/notebook/2D1Y4DKY7/paragraph/20160519-175034_779917343?asIframe

y puedo ir pinchando sobre los diferentes markers:

Notebooks Procesando y representando datos en un mapa Leaflet con los Notebooks Sofia2

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