Mejoras en depuración de Reglas Scripting

En la última versión de Sofia2, se añadió una mejora con la que se podrán depurar reglas scripting del lenguaje Groovy de la plataforma. Podremos visualizar cómo ha finalizado la ejecución del mismo, tanto el caso de éxito, como de fallo.

Para ver el estado de la ejecución de un script deberemos de ir al menú Visualización Estado Procesos dentro de HERRAMIENTAS en la consola de Sofia2:

Dentro del mismo tendremos un listado de los scripts ejecutados de la plataforma, así como el estado de su ejecución:

Si pulsamos en el botón de ver detalles, podremos acceder a la traza de ejecución, en caso de que el script se ejecutase correctamente:

En el caso anterior, vemos que la traza de ejecución ha sido If – then.

Si por el contrarío el script falla a la hora de ejecutarse, se nos mostrará un mensaje de error, indicando el bloque erróneo y los detalles en la sección detalles del mismo:

El proceso completo se puede ver también en el vídeo publicado en el canal de Sofia2, sobre las mejoras de depuración de reglas Script: https://youtu.be/a14j9B_ch_8

Mejoras en depuración de Reglas Scripting

API Manager: Metodos Custom Query

En la última versión de la plataforma se incorpora una nueva funcionalidad dentro del módulo API Manager: Métodos Custom Query.

El Api Manager es un módulo que surge con la necesidad de aislar a los usuarios de los detalles particulares de la plataforma a la hora de interactuar con la información almacenada en la misma.

Con el fin de facilitar el acceso a dicha información, se ha ampliado la funcionalidad del Api Manager para hacerlo aún más transparente para su uso.

De esta forma, a la hora de disponibilizar una Ontología como API, se podrá definir un nuevo tipo de Operación que se añade a los ya existentes: Custom Query.

Un método Custom Query almacenará todos los detalles de parametrización asociados a la invocación de un método del API al que pertenezca. Se almacenará tanto la consulta a realizar, sus parámetros, así como las opciones genéricas de la operación, como la BD sobre la que se efectúa la consulta, el tipo de consulta y el formato de los resultados obtenidos.

En el interfaz de la consola, a la hora de dar de alta un nuevo API que disponibilice una Ontología, se mostrará la siguiente opción:

Para añadir un nuevo método CUSTOM query, se pulsará sobre dicho botón. Se mostrará el siguiente diálogo:

Se indicará:

· Método de la operación (en este caso sólo GET).

· Nombre de la operación. Servirá para identificarla y permitir su invocación. Debe ser único para cada API.

· Query a ejecutar. Será la query que se efectuará para recuperar los datos. Debe realizarse sobre la ontología que se disponibiliza. Puede incluirse tanto en formato SQLLIKE como NATIVE (seleccionable en el siguiente componente). Además se pueden definir parámetros a aplicar sobre la misma query. Los parámetros se indicaran entre {}. Ejemplos de querys validas son:

select * from sulfato

select * from sulfato where sulfato.Provincia={$provincia}

select * from sulfato where sulfato.Provincia={$provincia} and sulfato.Resultado={$resultado}

db.sulfato.find()

Una vez introducida la query, si se ha definido algún parámetro en la misma, se cargaran en el panel de Parámetros para asociarles un tipo. Los tipos disponibles son STRING, NUMBER y BOOLEAN.

· Query type: Indica si la consulta a efectuar está en formato SQLLIKE o NATIVE.

· Target DB: Selecciona sobre qué BD se realiza la consulta (BDTR o BDH).

· Formato Resultado: Formato en el que se devolverán los datos. Las opciones disponibles son JSON, XML y CSV.

· Descripción: Se incluye una descripción de la operación para facilitar su identificación.

A continuación se incluye un ejemplo de definición de una operación Custom Query:

customquery

Tras pulsar sobre el botón Guardar, se almacenará la nueva Operación:

El comportamiento de la operación será similar a las existentes hasta ahora. Al incluirse en un API, podrá ser invocada por aquellos usuarios que estén suscritos a ella.

El interfaz WEB de invocación mostrará la nueva operación:

Y para su invocación será necesario indicar el token de usuario (como hasta ahora) y los parámetros que se hayan definido en la query. En este caso:

Los parámetros siempre serán obligatorios, ya que se utilizan para ejecutar la query. Si se definen querys sin parámetros (sin condiciones), sólo será necesario introducir el token de usuario.

De esta forma, el usuario que utilice este tipo de operaciones no tendrá que introducir la consulta a ejecutar en cada petición.

Esta funcionalidad se añade a las anteriores, que siguen estando disponibles como hasta ahora.

API Manager: Metodos Custom Query

Soporte de Arrays de medidas en Gadgets y Dashboards

En la nueva versión de sofia2 se añadió la posibilidad de incluir datos para los Gadgets en formato Array. Debemos tener en cuenta, que los Gadgets aceptarán solo arrays de datos simples, que ese mismo tipo de Gadget pueda soportar, y, que si se tienen varios ejes, se deberán proporcionar la misma cantidad de valores en el array para cada uno.

Para acceder individualmente a los datos de los arrays, se puede acceder de dos maneras:

· Directamente accediendo al elemento (sabemos que siempre está en la posición 1 del array) con $0[1][‘measure’]

· Con la función auxiliar arrayFind(array, nameField, valueField, fieldToFind) quebusca el campo nameField igual a valueField y en ese elemento del array devuelve el campo fieldToFind por ejemplo: arrayFind($0,’name’,’plazasTotales’,’measure’)

Se puede utilizar otra función auxiliar en el caso de arrays de tipo asociativo dentro de un array estándar, como el mostrado a continuación:

“array”: [

{

“Valor1”: “Temperatura”,

“Valor2”: “40”,

“Valor3”: “REAL”,

“Valor4”: “Zona Norte”

},

{

“Valor1”: “Temperatura2”,

“Valor2”: “45”,

“Valor3”: “REAL”,

“Valor4”: “Zona Sur”

}

]

En este caso contamos con la función explodeArray($0,’measure’,functionEachData) que realiza el despliegue de arrays. Permite seleccionar un campo de un array asociativo de un nivel y utilizarlo como un array de datos para el Gadget. El último parámetro “functionEachData” es opcional, se trata de una función que se aplicará a cada dato del array, por ejemplo un conversión a numérico u otra conversión necesaria.

En el caso anterior, dentro del array “userStats” se creará un array simple para la categoría, que tendrá los nombres de los usuarios y uno de datos, para el valor de cada categoría. Nótese aquí que son el mismo número de datos en ambos ejes, al usarse la función auxiliar sobre el mismo array, pero con diferentes campos dentro del array interno asociativo.

Soporte de Arrays de medidas en Gadgets y Dashboards

Exportación de resultados de consultas a múltiples formatos

A partir de esta nueva versión, se ofrece la posibilidad de descargar las consultas sobre BDTR realizadas desde HERRAMIENTAS->Consola BDTR y BDH.

Anteriormente sólo se disponía de los datos devueltos por la consulta a BDTR en formato JSON, ahora se podrá descargar un fichero con toda esa información,con el objetivo de que esta sea más “visual”.

Para realizar la descarga, únicamente hay que realizar una consulta sobre BDTR y pinchar sobre cualquiera de los iconos que aparecerán en pantalla, debajo del botón “Realizar Consulta”.

imag1

Una vez pinchado sobre el icono correspondiente, comenzará la descarga si los datos devueltos por la consulta BDTR son válidos (distintos de nulo), en cuyo caso saltará una alerta avisando de que no es posible la descarga de ficheros.

A continuación se va a explicar el formato interno de cada uno de estos ficheros generados:

  • XLS: En la primera fila y en negrita se pueden ver cada uno de los campos que pertenecen al JSON devuelto. En caso de que un campo contenga a otro, el nombre que aparece será la combinación de ambos nombres, separados por “:”. A partir de la segunda fila se pueden ver los datos contenidos en el campo correspondiente, de manera que habrá tantas filas como la dimensión del array JSON devuelto al realizar la consulta a la BDTR.
  • XML: El nombre de cada campo es la etiqueta, que contendrá el dato correspondiente o etiquetas adicionales en el caso en el que en su interior haya campos adicionales.
  • CSV: Sigue la misma nomenclatura que el EXCEL, con la única diferencia de que los datos se separan con “;”.

Por ejemplo, si tenemos los siguientes datos devueltos por una consulta a la ontología “SensorBasico”

imag2

El formato XLS (Excel) resultante es:

imag3

En CSV:

imag4

Y por último en XML:

imag5

En este vídeo se puede ver un ejemplo completo de la descargar de archivos en diferentes formatos a partir de una consulta lanzada a BDTR:

https://www.youtube.com/watch?v=5TqxeYUWAgw&feature=youtu.be

Exportación de resultados de consultas a múltiples formatos

Capacidad de Escucha activa sobre Twitter

En la versión 2.20.0 de Sofia2 se ha incluido una nueva funcionalidad Social Media. Con esta nueva funcionalidad podemos programar búsquedas en twitter, lo que permite escuchar los tweets durante un intervalo de tiempo configurable e insertarlos en una ontología en Sofia2. Los datos se almacenan en la Base de Datos en Tiempo Real para poder hacer los procesos analíticos y Social Media necesarios.

Ver video demostrativo aquí: https://www.youtube.com/watch?v=nPUllvzeDkI

Se puede acceder desde el menú Social Media>Búsqueda programada desde la consola, desde donde podemos ver una tabla con nuestras búsquedas ya programadas y crear nuevas escuchas.

En la pantalla de creación introducimos los términos de búsqueda, el intervalo de tiempo en el que estará activa y la ontología en la que queremos almacenar los tweets recibidos.

Desde la consola de BDTR podemos consultar los tweets insertados en la ontología:

Esta nueva funcionalidad complementa las capacidades social media de Sofia2 permitiendo recibir en tiempo real durante un intervalo de tiempo información de Twitter para su análisis posterior.

Capacidad de Escucha activa sobre Twitter

Mejoras en el soporte de almacenamiento de binarios

Con la última versión de la plataforma Sofia2, ha llegado la posibilidad de operar con archivos binarios fuera de una ontología, esto permite el envío de binarios con un tamaño mayor al soportado por el tipo de dato Binary.

2015-06-17_17-31-41Como se expone en el gráfico anterior esta nueva funcionalidad consta de los siguientes módulos.

  • APIClient cliente Java que facilita la operatividad de upload, update, delete y recuperación de los binarios depositados en la plataforma.
  • Service exposición de un Servicio REST para subir ficheros a la plataforma.
  • Imeplentaciones Plugables a traves de las extensiones en modo Plugin podemos añadir nuevas implementaciones para el almacenamiento de los binarios, Actualmente se dispone de dos. Almacenamiento en la base de datos de tiempo Real (BDTR) y en sistema de ficheros (File).

El Servicio REST que expone el SIB soporta la subida de binarios a través de multipart, lo que permite adjuntar binarios sin límite de tamaño, la plataforma permite a través de su parametrización configurar el tamaño máximo de los binarios añadidos.2015-06-17_17-38-15

Los métodos que expone el servicio son.

  • Post. Para añadir un nuevo binario en la plataforma, en la respuesta del servicio se nos indicará el ID del Binario que debemos usar en las siguientes operaciones.

2015-06-17_17-42-07

  • Put. Para modificar un binario ya gestionado por la plataforma.

2015-06-17_17-44-26

  • Delete. Nos permite dar de baja un recurso gestionado por la plataforma (Será una baja lógica)

2015-06-17_17-45-17

  • Get. Podremos recuperar el Binario gestionado por la plataforma.

2015-06-17_17-46-25

Podemos observar que en todas operaciones se nos solicita un SessionId que obtendremos a través de un Join previo en la plataforma, para obtener un SessionId válido deberemos solicitar al administrador de la plataforma que nos otorgue permisos a alguno de nuestro Kp para usar BinaryRepository y con el nivel de actuación que deseemos Consultas, Inserciones o Completo.

En función del tipo de permiso podremos realizar todas las operaciones expuestas por el Servicio o solo aquellas para las que estemos autorizados.

Mejoras en el soporte de almacenamiento de binarios

Sobre futuras capacidades de MongoDB 3.2 y capacidades Sofia2

En el evento MongoDB World 2015 de New York se ha hablado de las mejoras en el producto que traerá la versión MongoDB 3.2 (beta en verano y RA a finales de año).

Entre las más interesantes tenemos:

Conector para BI: se permitirá acceso SQL a nivel de lectura a través de la función de agregación

Validación de documentos: permitirá aplicar reglas para verificar los tipos de datos, los valores, los campos obligatorios y así sucesivamente.

Visualización de esquemas. Esta interfaz gráfica dará a los desarrolladores y DBAs una visión de la estructura de los documentos y colecciones enteras

Es una buena noticia para los usuarios de MongoDB, aunque seguro que a los que ya conocéis Sofia2 ninguna de estas os resultará extraña puesto que Sofia2 las soporta todas!!!

· Conector para BI: Sofia2 tiene un completo parser SQL que traduce a lenguaje nativo. Soporta tanto SELECT como INSERT, UPDATE y DELETE. Ver post: https://about.sofia2.com/2014/05/05/soporte-consultas-sql-sobre-bdtr-sofia2/

· Validación de documentos: Cada concepto Sofia2 (ontología) debe definirse, esto es definir su tipo, si es opcional o no, enumeraciones,…

· Visualización de esquemas: los conceptos Sofia2 además de validarse se definen, Sofia2 ofrece diversas herramientas en este sentido, desde el modelado visual: https://about.sofia2.com/2015/04/08/modelado-visual-de-ontologias/

a consolas para consultas

Sobre futuras capacidades de MongoDB 3.2 y capacidades Sofia2