SOFIA2 RELEASE 2.11.0 PUBLISHED

Sofia2 new release 2.11.0 is now available. This release has also been deployed in the experimentation platform Sofia2 In-Cloud.

This new version adds the following features to the platform:

· API Manager Sofia2 V2

This new version offers, in addition to publishing the Sofia2 Ontologies as REST APIs, the ability to publish External APIs. The API Manager will act as a proxy to other services, allowing external REST services to publish in a consistent manner.

Such APIs may have an associated authentication (to invoke the service) that can be configured on the console:

The Path, Query and Header Params can be included when defining the External API Operations.

On the other hand in this new version of the API Manager, APIs can be public (all platform users can subscribe to them) or restricted to a limited group of users (eg APIs for communication between systems)

Also There are changes in the API`s GUI definition, allowing for example ontologies APIS to publish one or more operations:

· Wizard for defining rules easily:

To make rule creation easier (CEP events and rules and Scripting rules) a new step by step wizard has been created that will guide the user neatly on creating rules without having to navigate through Sofia2 UI.

First choose the type of rule:

After selecting the type of rule the wizard guides us, for example:

Generate rule CEP: Allows to create CEP events and then CEP rules from them.

Generate scripting rule based on one (or several) CEP rules from a CEP rule, allows to create a script rule that will launch whenever an output CEP event is generated:

The generated Rules are available in the corresponding menu option:

· My APIs Acess Management using Sofia2 API Manager

Until now, when an API was created in the API Manager, this was public and any user of the platform could subscribe it.

An additional control to define if an API is public (anyone can subscribe) or private has been incorporated.

In non public APIS the owner will be responsible for authorizing which users can subscribe to the API. For this there is a new interface in the menu:

On this option, the users that can access APIs are defined:

· GIS Asset Viewer:

This new utility integrates a map view of the georeferenced existing Assets of the platform:

Allows to select Asset Types to visualize ,and displays the information associated with each Asset:

Each user will view the Assets depending on roles and ownership.

· Asset query via SSAP Protocol

Until now Assets were available through Sofia2 Console and its Configuration REST API.

This new version adds the ability to query Assets and Asset type information using SSAP Query messages (BDC Type):

{

"body":

{

"query":"{select * from Asset}",

"queryType":"BDC"}",

"direction":"REQUEST",

"messageId":null,

"messageType":"QUERY",

"ontology":null,

"sessionKey":"XXXXX"

}

}

This information is returned in JSON format:

These queries can also be executed from the Web Console:

This functionality allows Sofia2 APPS (KPs) to consult Assets (and Asset Types) involved in their ontologies for composing information, visually representation … using the same API SSAP.

· JMS API available from rules

The Sofia2 operation API offers now the ability to send messages (JSON or XML) to Queues or Topics through a JMS Broker from four simple operations availables on the platform and accessible from the console of scrip creation.

(*)Sofia2 InCloud has an ActiveMQ accessible upon request.

· Web Console menu to make it more usable

To accommodate the new features to the platform’s menu, a restructuration has been considered necessary in order to make access more intuitive.

· Assets Privacy Management:

From now on, the user creating the Assets (Administrator or Collaborator) can define them as public or private. An Asset declared public will be able to be queried by other Collaborator users, whereas a private Asset will only be able to queried by his/her owner or an Administrator.

Asset Management is always performed by his/her owner or an Administrator.

· Custom Dashboards Preview:

In a future version, the ability to create gadgets (Sofia2 Visualization APPS) and customized Dashboards with those gadgets will be included in the Console.

In this preview it is possible to create gadgets of type ‘External HTML’.

· Software versions update in Sofia2 InCloud: our cloud environment has been updated with the latest software versions (e.g., MongoDB 2.6).

· Several bug fixings and improvements in performance and stability

SOFIA2 RELEASE 2.11.0 PUBLISHED

PUBLICADA RELEASE 2.11.0 DE SOFIA2

Ya está disponible la release 2.11.0 deSOFIA2, esta release también se ha disponibilizado en la Plataforma de Experimentación SOFIA2 In-Cloud.

Esta versión añade a la Plataforma las siguientes funcionalidades:

· API Manager Sofia2 V2

Esta nueva versión del API Manager ofrece – además de publicar las Ontologías Sofia2 como APIS REST accesibles de forma transparente – la posibilidad de publicar APIS Externas actuanado el API Manager como proxy a otros servicios REST permitiendo publicar Servicios REST externos de una forma coherente.

Este tipo de APIs pueden tener asociada una autenticación (para invocar al Servicio subyvacente) que puede configurarse en la consola:

A la hora de definir cada operación del API podremos incluir parámetros bien en el Path, como Query Param o como Header Param:

Por otro lado en esta versión las APIs pueden ser públicas (todos los usuarios de la plataforma pueden suscribirse) o bien restringidas a un grupo de usuarios limitado (por ejemplo para APIs de comunicación entre sistemas)

Esta versión también incluye cambios en el interfaz gráfico de definición de las APIs, permitiendo por ejemplo en las APIS sobre ontologías publicar una o varias operaciones:

· Wizard para definición sencilla de Reglas:

Con el fin de hacer más sencilla la operativa completa de creación de reglas (eventos CEP, Reglas CEP y reglas Scripting) se ha creado un asistente que 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:

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.

Generar regla scripting basada en una (o varias) reglas CEP a partir de una regla CPE me permite crear una regla script que se lanzará cada vez que se genere un evento de salida CEP:

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

· Gestión del Acceso a Mis APIs en API Manager Sofia2

Hasta ahora cuando se creaba un API en el API Manager esta era pública y cualquier usuario de la plataforma podía suscribirse.

Se incorpora un control adicional que permite definir si un API es pública (cualquier usuario se puede suscribir) o privada.

En las APIS privadas el propietario es el responsable de autorizar a qué usuarios quiere permitir el acceso. Para ello existe una nueva interfaz en el menú:

Dentro de la opción de menú se definen que usuarios pueden acceder a qué APIS:

· Visor GIS Assets :

Esta nueva utilidad permite visualizar en un mapa integrado en la consola los Assets georeferenciados existentes en la plataforma:

Permite seleccionar los Tipos de Asset a visualizar y mostrar la información asociada a cada Asset:

Cada usuario podrá visualizar los Assets en función de los permisos de estos.

· Consulta de Assets a través de Protocolo SSAP

Hasta ahora los Assets podían consultarse a través de la Consola y del API REST de Configuración/Assets.

En esta versión se incluye la capacidad de consultar la información de Assets y Tipos de Asset a través de mensaje SSAP Query (tipo BDC):

{“body”:

{

“query”:”{select * from Asset}”,

“queryType”:”BDC“}”,

“direction”:”REQUEST“,

“messageId”:null,

“messageType”:”QUERY”,

“ontology”:null,

“sessionKey”:”XXXXX”

}

}

Esta información se devuelve en formato JSON:

Estas consultas también pueden realizarse a través de la Consola Web/Consulta BD:

Esta funcionalidad permite que las APPS Sofia2 (KPs) puedan desde el mismo API SSAP consultar los Assets (y Tipo de Asset) involucrados en sus Ontologías para por ejemplo componer información, representarlos visualmente,…

· API JMS accesible desde reglas

El API de operaciones de Sofia2 ahora ofrece la posibilidad de enviar mensajes (JSON o XML) a Colas o Topics de un Broker JMS mediante cuatro sencillas operaciones disponibles en la plataforma y accesibles desde la consola de creación de scripts.

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

· Reestructuración del Menú de la Consola Web para hacerlo más usable

Para adecuarse a las nuevas funcionalidades incorporadas a la Plataforma se ha considerado necesaria una reestructuración del menúa con el objetivo de hacer más intuitivo el acceso a las diferentes operaciones.

· Gestión de la Privacidad de los Assets:

A partir de ahora el usuario que crea los Assets (Administrador o Colaborador) puede definir sus Assets como públicos o privados. Un Asset declarado como público podrá ser consultado por otros usuarios Colaboradores, mientras que si se declara como privado, únicamente podrá ser consultado por su propietario o un administrador.

La gestión del Asset siempre la realiza su propietario o un administrador.

· Preview de Dashboards personalizados: en una próxima versión se incluirá en la Consola Web la capacidad de crear gadgets (APPS Sofia de visualización)y Dashboards personalizados que rendericen estos gadgets.

En esta preview se permiten crear gadgets de tipo URL externa.

· Actualización de versiones de Software en Sofia2 InCloud: se ha actualizado el entorno en la nube de Sofia2 con las últimas versiones del software (MongoDB 2.6 por ejemplo)

· Resolución de diversos bugs e incorporación de mejoras de rendimiento y estabilidad

PUBLICADA RELEASE 2.11.0 DE SOFIA2

Estimote Stickers o cómo añadir sensores a cualquier objeto

La empresa Estimote ha lanzado al mercado una nueva versión más avanzada de sus Estimote Beacons y Stickers.

El año pasado Estimote introdujo los Estimote Beacons, pequeñas computadoras (32-bit ARM® Cortex M0 CPU with 256kB flash memory, accelerometer, temperature sensor and what is most important – 2.4 GHz Bluetooth 4.0 Smart (BLE o Bluetooth low energy) bidirectional radio) que se usan como balizas para localizaciones estáticas como tiendas, museos,… que permiten interactuar con nuestro móvil:

Pueden adquirirse por 100 dólares 3 Beacons:

Ahora han incluido los Stickers, que permiten extender la funcionalidad de los Beacons a cualquier objeto, ya que voienen en forma de pegatina que puedes añadir a cualquier objeto, envían pequeñas señales de radio que un Smartphone, puede recibir e interpretar.

Estos nuevos Stickers vienen en formato de pegatina (tan sólo 3 mm de ancho) e incluirán un acelerómetro, un sensor de temperatura y un sensor de movimiento en cada una.

Saldrán a la venta en octubre por 99 dólares 10:

Podéis ver cómo funcionan aquí:

Con el Estimote SDKdisponible para iOS y Android las aplicaciones pueden interactuar con estos stickers y Beacons:

En este video presentación podéis haceros una idea de cómo funcionan y casos de uso típicos:

link

Se te ha olvidado el bolso?

Tengo que regar las plantas:

Cuánto ha paseado el perro:

En la web de Estimote aparecen muchas ideas más donde aplicarlos.

Estimote Stickers o cómo añadir sensores a cualquier objeto

Funcionamiento Buscador de Tweets Sofia2

El Buscador de Tweets presenta una demo de integración entre el servicio de Twiter con el SIB Sofia2.

Se halla en la sección de desarrollador de la web sofia2, en el visor geográfico

http://sofia2.com/Examples/Geographics.html

En la cuarta solapa de la columna izquierda se encuentra el icono de Twiter, que da acceso al Buscador de Tweets.

Pantalla del Buscador de Tweets

El buscador permite buscar tweets que contengan palabras específicas dentro de un área localizada.

Funcionamiento del Buscador

La operativa del buscador se puede representar según el esquema siguiente

 

1. Desde el visor, accedemos mediante una petición http a un controlador específico de búsqueda de tweets en el Smart Space Sofia2.

2. El controlador realiza una llamada mediante las API de Twiter (Tweet4J) al servicio público de acceso a datos de http://twiter.com

3. La respuesta es procesada por el SIB. Se realiza un tratamiento de datos, un análisis semántico que determina la valoración del cada tweet.

4. Se insertan los datos procesados en la BDTR a través de un servicio rest, como instancia de ontología TweetsDemo. Se abren múltiples posibilidades de explotación y decisiones posteriores partiendo de los datos de las búsquedas.

5. Petición de los datos procesados de la última búsqueda al KPTweetsDemo

6. Pintado sobre el visor de las respuestas mediante tecnología HTML5

Detalles de la Llamada al Controlador

Para las llamada al controlador es necesario tener la URL del controlador (controllerURL, paso 1), la url del servicio del SIB Sofia que consumirá los datos de http://twiter.com (serviceURL, un servicio rest Sofia2, paso 4), ontología, kp, token para la inserción de la instancia de ontología, y demás parámetros listados en el cuadro:

 

En los parámetros (params) se compone la geoposición con el centro de la busqueda, el radio, lenguaje, palabras clave, etc.

La llamada del servicio es una llamada asíncrona de jquery ajax:

Es interesante destacar el parámetro sincronía (false por defecto en el visor).

  • Cuando es true, la respuesta success de la llamada ajax esperará el procesado completo de todos los mensajes y devolverá todas las instancias de ontología insertadas. Dependiendo del máximo de respuestas aceptadas, esta búsqueda puede conllevar una espera considerable.
  • Cuando es false, la respuesta del success se devolverá instantáneamente tras ser aceptada la petición por parte del controlador. Será necesario realizar una o más querys (por polling o suscripción) a la ontología TweetsDemo mediante ajax o websockets, lo que permite una actualización dinámica de los resultados de la búsqueda.
Funcionamiento Buscador de Tweets Sofia2

Nuevo Gateway Websocket en sofia2.com

Otra de las funcionalidades incluidas en la Release 2.10 de Sofia2 es el Gateway WebSocket.

El protocolo WebSocket (https://www.websocket.org/) es parte de la especificación HTML5. Ofrece conectividad full-duplex vía http entre el cliente y el servidor, permitiendo el envío de mensajes tanto desde el cliente hacia el servidor, como desde servidor hacia cliente por iniciativa del propio servidor.

El Gateway WebSocket de Sofia2 aprovecha la conectividad bidireccional para ofrecer el juego completo de operaciones SSAP incluyendo la suscripción. Por lo que puede ser utilizado por cualquier KP cuyo lenguaje de programación permita conexiones de este tipo.

El endpoint del Gateway WebSocket de Sofia2 es público en la dirección: ws://sofia2.com/sib/api_websocket, respondiendo a cualquier mensaje SSAP enviado por método GET. Por lo que cualquiera que abra una conexión, registre un listener para recibir respuestas desde servidor, y envíe mensajes SSAP, estará construyendo un KP, comunicando con el SIB de Sofia2 por este protocolo.

Por ejemplo, desde un navegador con soporte para HTML5, el código javascript seria:


//Abrir conexión al Gateway

ws = new WebSocket("ws://sofia2.com/sib/api_websocket");

//Registrar un listener para recibir respuestas SSAP y notificaciones

ws.onmessage = function (evt) {

var received_msg = evt.data;

if(received_msg!=''){

console.log(received_msg);

}

};

//Enviar mensajes SSAP al SIB

ws.send(‘{"{ ···········}"’);

No obstante, para facilitar la creación de KPs así como permitir a otros ya existentes la utilización de este protocolo, se han incluido conectores WebSocket en las APIs de programación de KPs para los lenguajes Java y Javascript.

Como se puede consultar en la Guia de APIs de Sofia2 (http://sofia2.com/docs/SOFIA2-APIs%20SOFIA2.pdf) en la sección Desarrollador, en ambos casos, se ha mantenido la interfaz de operaciones existente para comunicar mensajes con el SIB y tan solo hay que modificar los detalles de la conexión.

En concreto, en el API Java, hay que instanciar la interfaz Kp con un objeto de la clase KpWebSocketClient, que recibe su configuración mediante una instancia de la clase WebSocketConnectionConfig, donde se informa:

· endPointUri: URL donde escucha el Gateway Websocket del SIB.

· method: Metodo HTTP utilizado por el Gateway Websocket del SIB (por defecto en sofia2.com GET).

· timeOutConnectionSIB: Timeout para recibir la respuesta desde el SIB.

Una vez instanciada la interfaz Kp, su utilización es como hasta ahora, de manera independiente del protocolo.


WebSocketConnectionConfig config=new WebSocketConnectionConfig();

config.setEndpointUri("http://sofia2.com/sib/api_websocket");

config.setMethod(METHOD.GET);

config.setTimeOutConnectionSIB(5000);

KpWebSocketClient kp=new KpWebSocketClient(config);

Para el API Javascript, basta con declarar la variable pathToWebsocketServer con el endpoint del Gateway de sofia2.com, en vez de la variable pathToDwrServlet como hasta ahora, y que es válida para utilizar el Gateway Ajax Push. Una vez declarada, todas las operaciones del API utilizarán el Gateway indicado:

<script type="text/javascript">var pathToWebsocketServer="ws://sofia2.com/sib/api_websocket";</script>

Es posible obtener ejemplos de código funcional, descargando las APIs Java y Javascript disponibles en la sección Desarrollador de sofia2.com.

Nuevo Gateway Websocket en sofia2.com

Definición de Reglas CEP (Ejemplos)

Para comprender el uso y definición de Reglas CEP vamos a crear un caso de ejemplo.

El ejemplo trata de definir una Regla CEP que cuando cierta medida supere un umbral se ejectute la regla. Para ello nos vamos a basar en la ontología existente en Sofia2, pt_espira.

Para esta ontología nos vamos a crear un Evento CEP para indicar los valores con los que vamos a trabajar en nuestra regla CEP:

EventoCEPA continuación definiremos la regla CEP como sigue:

ReglaCEPPara probarlo nos podemos implementar un Test Consumidor que esté suscrito a esta regla CEP:

TestConsumidorEspira

Es importante que el nombre de la salida de la regla coincida con lo que se definió en el Insert Into de la Regla CEP.

En el caso de que necesitemos insertar datos en la ontología podemos simular un proceso que los inserte de forma aleatoria:

TestProductorEspira

Si ejecutamos el test Consumidor obtendremos el siguiente resultado:

Mensaje REspuesta:com.indra.sofia2.ssap.ssap.body.SSAPBodyReturnMessage@1496fc2
>Suscripcion–>
{“body”:”{\”Subscription\”:\”SALIDAESPIRA-16751328-C870-4026-9E4D-604FEF2790D8\”,\”inEvents\”:{\”ID\”:\”guid_sec_3164\”,\”MEASURE\”:70.0,\”VELOCIDAD\”:\”70\”}}”,”direction”:”RESPONSE”,”messageId”:”d8702ac8-ceea-468c-9e8b-179d3f3aee75″,”messageType”:”INDICATION”,”ontology”:null,”sessionKey”:”4a009b3d-1a78-4dd9-aec0-0f0d2c6e121b”}
>Fin Suscripcion…

>Suscripcion–>
{“body”:”{\”Subscription\”:\”SALIDAESPIRA-16751328-C870-4026-9E4D-604FEF2790D8\”,\”inEvents\”:{\”ID\”:\”guid_sec_3164\”,\”MEASURE\”:30.0,\”VELOCIDAD\”:\”30\”}}”,”direction”:”RESPONSE”,”messageId”:”d8702ac8-ceea-468c-9e8b-179d3f3aee75″,”messageType”:”INDICATION”,”ontology”:null,”sessionKey”:”4a009b3d-1a78-4dd9-aec0-0f0d2c6e121b”}
>Fin Suscripcion…

>Suscripcion–>
{“body”:”{\”Subscription\”:\”SALIDAESPIRA-16751328-C870-4026-9E4D-604FEF2790D8\”,\”inEvents\”:{\”ID\”:\”guid_sec_3164\”,\”MEASURE\”:58.0,\”VELOCIDAD\”:\”58\”}}”,”direction”:”RESPONSE”,”messageId”:”d8702ac8-ceea-468c-9e8b-179d3f3aee75″,”messageType”:”INDICATION”,”ontology”:null,”sessionKey”:”4a009b3d-1a78-4dd9-aec0-0f0d2c6e121b”}
>Fin Suscripcion…

Como podemos observar, tenemos tres casos en los cuales se ha cumplido la regla CEP.

Continuando con el ejemplo podemos hacer que al cumplirse nuestra Regla CEP salte una regla Script que inserte en una ontología que nos creemos (en nuestro caso AlarmaEspira) los valores recibidos del evento y además envíe un correo electrónico.

Nuestra ontología AlarmaEspira tendrá el siguiente Schema XML:

AlarmaEspira

Nuestro Script de tipo Regla CEP asociado a la regla que hemos creado anteriormente, será el siguiente:

ScriptEspira-If

ScriptEspira-Then

Si volvemos a lanzar el test y todo va bien se habrá insertado los datos en la ontología AlarmaEspira. Si vamos a Herramientas -> Consulta a Base de Datos y lanzamos la query podemos observar que efectivamente los datos se han almacenado:

QueryAlarmaEspira

Definición de Reglas CEP (Ejemplos)