GUÍA DE USO CONSOLA WEB DE CONFIGURACIÓN SOFIA2

Transcripción

1 GUÍA DE USO CONSOLA WEB DE CONFIGURACIÓN SOFIA2 FEBRERO 2015 Versión 6

2 1 INDICE 1 INDICE INTRODUCCIÓN REQUISITOS OBJETIVOS Y ALCANCE DEL PRESENTE DOCUMENTO ACCESO A CONSOLA WEB SOLICITAR DE ALTA DE USUARIO ACCESO A CONSOLA WEB ACCESO ROL USUARIO ACCESO ROL COLABORADOR ACCESO ROL ADMINISTRADOR GESTIÓN ONTOLOGÍAS ALTA ONTOLOGÍAS ALTA ONTOLOGÍAS CAMPO A CAMPO SOPORTE A BINARIOS ALTA ONTOLOGÍAS DESDE EXCEL ESTADO DE CARGA DE EXCEL ALTA ONTOLOGÍA DESDE COLECCIÓN LISTADO DE ONTOLOGÍAS MODIFICACIÓN DE ONTOLOGÍAS BAJA DE ONTOLOGÍAS SUSCRIPCIÓN A ONTOLOGÍAS AUTORIZACIONES A MIS ONTOLOGÍAS GESTIÓN ONTOLOGÍAS DE GRUPO LISTADO DE ONTOLOGÍAS DE GRUPO MODIFICACIÓN DE ONTOLOGÍAS DE GRUPO BAJA DE ONTOLOGÍAS DE GRUPO Consola Web SOFIA2 Página 2/221

3 5.4 SUSCRIPCIÓN A ONTOLOGÍAS DE GRUPO AUTORIZACIONES ONTOLOGÍA DE GRUPO GESTIÓN DE KPS/APPS ALTA DE KPS/APPS LISTADO DE KPS MODIFICACIÓN DE UN KP GESTIÓN DE TOKENS GESTIÓN DE INSTANCIAS DE KPS CONTENEDOR KPS/APPS CREAR KPS/APPS EN CONTENEDOR REGLAS CREAR REGLA CON WIZARD CREACIÓN SCRIPT Scripts tipo Timmer Scripts sobre ontologías Scripts sobre Ontologías Padre Scripts tipo Cep LISTADO DE SCRIPT DETALLE DE SCRIPT EDICIÓN DE SCRIPT REGLAS CEP EVENTO CEP GESTIÓN DE ASSETS CREAR ASSET LISTAR ASSETS DETALLE DE ASSETS MODIFICACIÓN DE ASSETS Consola Web SOFIA2 Página 3/221

4 9.5. CREAR TIPO DE ASSET LISTAR TIPOS DE ASSET DETALLE DE TIPO DE ASSET MODIFICAR TIPOS DE ASSET CREAR NODO LISTAR NODOS DETALLE DE NODO MODIFICACIÓN DE UN NODO VISUALIZACIONES MIS GADGETS Crear Gadgets MIS DASHBOARDS Crear Dashboards HERRAMIENTAS CONSOLA BDTR Y BDH GESTIÓN CONSULTAS PREDEFINIDAS KPS ACTIVOS Busca y consulta de instancias de KPs Activos Realizar consultas BDTR sobre el KP Activo ENVÍO MENSAJES SSAP VALIDAR MENSAJE JSON VISUALIZACIÓN ESTADO PROCESOS GESTIÓN SW GESTIÓN DE CONFIGURACIÓN DE SOFTWARE ASIGNACIÓN DE CONFIGURACIÓN SOFTWARE EN KPS ADMINISTRACIÓN GESTIÓN DE USUARIOS Consola Web SOFIA2 Página 4/221

5 ALTA DE USUARIOS LISTAR USUARIOS MODIFICACIÓN DE USUARIOS BAJA DE USUARIOS GESTIÓN PLANTILLAS ONTOLOGÍAS CREAR NUEVA PLANTILLA LISTAR PLANTILLA EDICIÓN DE PLANTILLAS GESTIÓN DE PETICIONES GESTIÓN OPERACIONES OPCIONES DE ADMINISTRACIÓN API MANAGER MI API KEY MIS APIS Pantalla de Creación de API Pantalla de Consulta de API Pantalla de Modificación de API AUTORIZACIONES APIS SUSCRIPCIÓN A APIS MIS SUSCRIPCIONES SOCIAL MEDIA USUARIOS TWITTER BÚSQUEDA TENTENCIAS PÁGINAS FCCEBOOK TENDENCIAS INSTAGRAM... ERROR! MARCADOR NO DEFINIDO CONFIGURACIONES 179 Consola Web SOFIA2 Página 5/221

6 16. SOFIA2 DATAFLOW * INTRODUCCIÓN CONTENEDORES... ERROR! MARCADOR NO DEFINIDO STREAMS... ERROR! MARCADOR NO DEFINIDO. 16N4.SOURCES & File... Error! Marcador no definido.octubre 30, FTP... Error! Marcador no definido HTTP JDBC JMS Kafka Mail MongoDB MQTT Reactor-lp SFTP Syslog Tail TCP TCP-Client Time Trigger Twitter Search TwiterStream PROCESSOR Aggregator Filter Consola Web SOFIA2 Página 6/221

7 HTTP Client Script Shell Splitter Transform SINKS File FTP HDFS HDFS Dataset JDBC Log Mail Mongo MQTT Redis Shell TCP Counter Field Value Counter Aggregate Counter Gauge Rich Gauge JOB UN VISTAZO A LA UI Definiciones Crear Stream Consola Web SOFIA2 Página 7/221

8 Análisis Consola Web SOFIA2 Página 8/221

9 2 INTRODUCCIÓN 2.1 Requisitos Antes de seguir esta guía se recomienda leer la guía SOFIA2-Conceptos SOFIA2.doc 2.2 Objetivos y alcance del presente documento El presente documento presenta los conceptos básicos sobre la Consola Web integrada en la Plataforma de SOFIA2. A través de la Consola Web los usuarios en función de su rol podrá realizar un conjunto de acciones, como suscribirse a ontologías, crear KPs, crear Ontologías, Consola Web SOFIA2 Página 9/221

10 3 ACCESO A CONSOLA WEB SOFIA2 puede desplegarse en infraestructura propia o bien en Cloud. Existe una versión Cloud de SOFIA2 que será la que se use en esta guía. La consola de la Web está accesible en la URL: Solicitar de alta de usuario Si es la primera vez que se accede a esta consola y no se dispone de usuario será necesario solicitar el alta, para eso se pulsará sobre el link alta de nuestro usuario. (link) para solicitar el Consola Web SOFIA2 Página 10/221

11 Una vez enviada la petición se validará esta petición y si es correcta se activará el usuario con rol de USUARIO. Consola Web SOFIA2 Página 11/221

12 3.2 Acceso a Consola Web Una vez creado el usuario se podrá acceder a la Consola Web con el nuevo usuario: Cuando se crea un usuario en la Plataforma se crea con Rol USUARIO, lo que implica que sólo tiene un acceso limitado y de lectura a la Plataforma. Consola Web SOFIA2 Página 12/221

13 Se puede solicitar acceso a la Plataforma con Rol COLABORADOR lo que permite insertar datos en la Plataforma. Para ello pulsar sobre el link que hay en la cabecera de la página donde se indica el usuario logado en la plataforma: a continuación pulsar sobre el botón Paso a Colaborador: Usuario: xxxx [ROL_USUARIO]. En el formulario que se muestra Consola Web SOFIA2 Página 13/221

14 Se enviará una petición de solicitud de cambio de Rol a Colaborador al Administrador. El Administrador cuando reciba la petición la podrá aceptar o rechazar, informando al usuario a través de un correo electrónico de la resolución de petición. En caso de que se acepte el cambio, el usuario al logearse otra vez en la consola podrá comprobar que tiene acceso a una mayor funcionalidad. 3.3 Acceso Rol Usuario Un usuario con rol Usuario tiene acceso a estas opciones de menú: ONTOLOGÍAS Mis Suscripciones ONTOLOGÍAS DE GRUPO Mis Suscripciones KP s/apps SOFIA2 Mis KPs/APPs Mis Tokens Mis Instancias KP/APP HERRAMIENTAS Consulta BDTR y BDH KP s Activos Envío Mensajes SSAP Validar Mensajes SSAP Consola Web SOFIA2 Página 14/221

15 Consola Web SOFIA2 Página 15/221

16 API MANAGER Suscripción a APIs Mis Suscripciones Mi API Key 3.4 Acceso Rol Colaborador Un usuario con rol Colaborador tiene acceso a estas opciones de menú: ONTOLOGÍAS Crear Ontología Crear Ontología campo a campo Crear Ontología desde Excel Estado de Carga de Excel Generador de Instancias Mis Ontologías Mis Suscripciones Autorizaciones a mis Ontologías ONTOLOGÍAS DE GRUPO Crear Ontología de Grupo Mis Ontologías de Grupo Mis Suscripciones Autorizaciones a mis Ontologías Consola Web SOFIA2 Página 16/221

17 KP S/APPS SOFIA2 Mis KPs/APPs Mis Tokens Mis Instancias de KP/APP o REGLAS DE ASSETS Crear Regla con Wizard Mis Scripts Mis Reglas CEP Mis Eventos CEP ASSETS Mis Assets Visualizar Assets Tipos de Assets Nodos VISUALIZACIONES Mis Gadgets Mis Dashboards HERRAMIENTAS Consola BDTR y BDH Consola Web SOFIA2 Página 17/221

18 Gestión Consultas Predefinidas KP s Activos Envío Mensajes SSAP Validar Mensaje SSAP Visualización Estado Procesos GESTIÓN SW Mis Configuraciones SW Asignación Configuración API MANAGER Mis APIS Autorizaciones APIs Suscripción a APIs Mis Suscripciones Mi API Key 3.5 Acceso Rol Administrador Un usuario con rol Administrador tiene acceso a estas opciones de menú: ONTOLOGÍAS Crear Ontología Crear Ontología campo a campo Crear Ontología desde Excel Mis Ontologías Autorizaciones a mis Ontologías Consola Web SOFIA2 Página 18/221

19 ONTOLOGÍAS DE GRUPO Crear Ontología de Grupo Mis Ontologías de Grupo Autorizaciones a mis Ontologías KP S/APPS SOFIA2 Mis KPs/APPs Mis Tokens Mis Instancias de KP/APP o REGLAS DE ASSETS Crear Regla con Wizard Mis Scripts Mis Reglas CEP Mis Eventos CEP ASSETS Mis Assets Visualizar Assets Tipos de Assets Nodos Consola Web SOFIA2 Página 19/221

20 VISUALIZACIONES Mis Gadgets Mis Dashboards HERRAMIENTAS Consola BDTR y BDH Gestión Consultas Predefinidas KP s Activos Envío Mensajes SSAP Validar Mensaje SSAP Visualización Estado Procesos GESTIÓN SW Mis Configuraciones SW Asignación Configuración Consola Web SOFIA2 Página 20/221

21 ADMINISTRACIÓN Gestión Plantillas Ontologías Gestión Operaciones Gestión Peticiones Gestión de Usuarios API MANAGER Mis APIS Autorizaciones APIs Mis Suscripciones Mi API Key Consola Web SOFIA2 Página 21/221

22 4 GESTIÓN ONTOLOGÍAS Permite hacer una Gestión Completa de Ontologías, esto es: Crear y Modificar Ontologías Buscar Ontologías por criterios Buscar Ontologías y suscribirme a ellas. El objetivo de las ontologías es ser el schema contra el que se validarán las inserciones de ontologías por parte de los KPs. 4.1 Alta Ontologías A través de la opción de menú Ontología, un usuario con rol colaborador o rol administrador podrá definir y dar de alta en el Sistema nuevas ontologías. El formulario está accesible desde el menú en la opción de Crear Ontología, el usuario deberá indicar: Nombre con el que desea identificar la nueva ontología Versión actual de la plantilla seleccionada. Campo no editable Si la ontología será activa Si la ontología será pública para el resto de usuarios. Tiempo de paso de la información almacenada en la Base de Datos de Tiempo Real (BDTR) a la Base de Datos de información Histórica (BDH). Se seleccionará una programación para dicho paso. Si el campo se deja vacío, no se activará dicho paso. Si en lugar de realizar el paso de información de BDTR a BDH se desea eliminar la información. Al seleccionar esta opción, el periodo seleccionado como Tiempo de paso pasa a considerarse como Tiempo de eliminación de información almacenada en la BDTR. Esta opción se deshabilita si no hay periodo de borrado. Consola Web SOFIA2 Página 22/221

23 Clase Preprocesamiento Paso BDTR a BDH: incluye un check que habilita un campo de texto para introducir el nombre de una clase (debe existir en el classpath, a través de un plugin) que realizará el MapReduce en el paso de los datos de la BDTR a la BDH. Tanto el check como la caja de texto sólo están disponibles para usuarios administradores. Dependencias entre Ontologías: Incluye un check que indica si la ontología va a ser o no Padre. Si se selecciona esta opción, se podrán crear ontologías que extiendan de ella. Además incluye un combo en la que (de no tratarse de una ontología Padre) podrá seleccionarse la ontología padre de la que extenderá (cuyo esquema se utilizará para la nueva ontología hija). Si no se selecciona ninguna opción en dichos controles, la ontología será una ontología que se tratará de forma normal. Se definirán 3 tipos de Ontologías: o Ontologías Padre. Serán Ontologías abstractas (no instanciables) sobre las que no se podrá realizar ningún tipo de operación. o Ontologías Hijas. Serán ontologías que extenderán de una Ontología Padre (utilizarán su esquema). Mantendrán su propia configuración en cuanto a seguridad y backup en BBDD. o Ontologías de tipo general. Las ontologías que se conocen hasta el momento (la gestión y funcionamiento de las mismas es el utilizado hasta ahora). La Ontología Padre sólo será visible para los usuarios Administradores, para el usuario creador y para los usuarios que hayan sido autorizados sobre la misma. Para cada uno de ellos, se mostrará la Ontología Padre en el listado de Ontologías y en la combo Ontología padre de la que extiende de este componente. Plantilla o fichero xsd a utilizar en la definición de la ontología: En el caso de seleccionar fichero xsd tras examinar el fichero se deberá pulsar el botón Generar Ontología para que en el editor se carge el esquema asociado al mismo. El esquema de la ontología Descripción para indicar lo que se pretende representar con la ontología. Consola Web SOFIA2 Página 23/221

24 Consola Web SOFIA2 Página 24/221

25 Tendrán privilegios para crear ontologías los usuarios con roles Administrador o Colaborador. En el caso particular del Colaborador una vez que haya creado la ontología adquirirá los permisos ALL sobre dichas ontologías. El Administrador aunque no sea el propietario tendrá plenos privilegios sobre todas las ontologías. A modo de ayuda para el alta de una ontología, existe un generador de Instancias JSON. Si se pulsa sobre el botón Generar Instancia, se mostrará en la sección Instancia JSON un ejemplo de una instancia de la ontología que se desea dar de alta teniendo en cuenta el esquema de la ontología. 4.2 Alta Ontologías campo a campo De manera análoga al alta de ontologías, un usuario podrá crear ontologías sin necesidad de escribir directamente el esquema JSON de su ontología. Para esto, la consola de administración ofrece en el menú, en la sección de Ontologías, la opción Crear Ontología campo a campo. Ofrece al usuario las mismas opciones que la pantalla Alta de ontologías de la sección anterior, con las mismas funcionalidades (Ver sección 10.1 Alta Ontologías). Junto con un formulario para la definición de las propiedades que debe tener la ontología a dar de alta: Consola Web SOFIA2 Página 25/221

26 En este formulario es posible dar de alta todas las propiedades de la ontología a crear incluyendo su tipo de datos e indicando si se trata de una propiedad requerida o no. Una vez definida la propiedad, pulsando el botón Añadir, será incluida en la tabla de propiedades de la ontología. Consola Web SOFIA2 Página 26/221

27 Los tipos de datos disponibles para crear propiedades desde el asistente son los básicos de JSON-Schema, junto con los tipos binary y timestamp y geometry para explotar las capacidades de la BDTR procesando estos tipos de datos. Una vez definidas todas las propiedades de la ontología, estas aparecerán en la tabla de propiedades, de la que podrán ser borradas en caso de que se detecte que alguna no debe formar parte de la ontología. Antes de generar el esquema de la ontología, es posible indicar si admite propiedades adicionales a las declaradas o no. Para ello se dispone de la combo Additional Properties. En caso de no indicarse valor, o indicarse como false, la ontología no admitirá instancias de ontología con otras propiedades diferentes de las indicadas. En caso de informarse a true, si admitirá otras propiedades diferentes a las indicadas. Una vez especificadas las propiedades y la restricción Additional Properties, es posible generar el esquema de la ontología pulsando el botón Generar ontología. Esto hará que en el editor de ontologías de la página aparezca el esquema JSON de la ontología con la definición de las propiedades indicadas. Consola Web SOFIA2 Página 27/221

28 Este esquema es editable, de manera que antes de crear la ontología en la plataforma, es posible editar a mano el esquema para por ejemplo añadir otros campos con otros tipos de datos. Una vez que estemos conformes con el esquema, es posible crear la ontología pulsando el botón crear. NOTA: No es posible generar una ontología sin propiedades salvo que se especifique la restricción additional properties a true. Esto es para que no puedan existir ontologías que impongan la restricción de que sus instancias de ontología sean vacías. 4.3 Soporte a Binarios A través del Alta de Ontologías Campo a Campo se permite añadir de forma automática, propiedades de tipo Binario a las ontologías. Consola Web SOFIA2 Página 28/221

29 El tipo de dato binary es un tipo de dato complejo, que consta de un campo de tipo String para almacenar el binario serializado y otro complejo para almacenar la meta-información asociada. El atributo data de tipo String, es el campo donde encontramos el binario serializado en formato Base64 o Base91. El atributo media es un tipo de dato complejo que contiene información asociada al binario necesaria para su correcto procesamiento. Distinguimos los siguientes campos. name que es el nombre del fichero. binaryencoding que nos indica el tipo de encoding utilizado para serilizar el dato binario, este puede ser unicamente Base64 o Base91. No estando este último soportado por en todas las API. El encoding es usado internamente por las API de la plataforma por lo que unicamente se soportan los tipos definidos cuando se crea el tipo de dato. Consola Web SOFIA2 Página 29/221

30 mime, esta propiedad ha de contener los tipo de datos binarios que puede usar nuestra ontología, por defecto se añaden unicamente dos. application/pdf e image/jpeg, debemos añadir todos aquellos tipo de datos que queramos soportar. Al estar limitado el alcance del mime, a la gestión que desde los KP se quiera hacer de los datos binarios y no tener una vinculación en el amacenaje de la información, el contenido de este campo es libre y no es validado más allá del esquema definido. A continuación se muestra el Schema completo del tipo de dato binary para su inclusión en la creación manual de Ontologías. "binary": { "type": "object", "required": [ "data", "media" ], "properties": { "data": { "type": "string" }, "media": { "type": "object", "required": [ "name", "binaryencoding" "mime" ], "properties": { "name": { "type": "string" }, "binaryencoding": { "type": "string", "enum": [ "Base64", "Base91" ] }, "mime": { "type": "string", "enum": [ "application/pdf", "image/jpeg" ] } } } } } Consola Web SOFIA2 Página 30/221

31 4.4 Alta Ontologías desde Excel A través de esta opción se nos permite crear automáticamente una ontología a partir de un fichero Excel o csv. Esta opción de menú está disponible para Rol Colaborador y Rol Administrador. La pantalla que se nos mostrará en esta opción será la siguiente: Esta pantalla es similar a la pantalla de Crear Ontología, pero incluye un control para permitir la selección de un fichero de tipo Excel/CSV. Dicho fichero contendrá la información referida a Consola Web SOFIA2 Página 31/221

32 una ontología nueva que se desee crear o que se desee añadir a una ontología ya existente. Esto se puede configurar en la opción Modo de carga. También existen dos opciones desde donde poder cargar el fichero: Local y Servidor. Si se selecciona Servidor aparecen los ficheros Excel/CSV que se han cargado previamente en dicho servidor. En cambio si se marca el origen del fichero Local, se permitirá seleccionar el Excel/CSV a cargar pulsando sobre Seleccionar archivo. Si el archivo es de tipo CSV, se mostrará un campo adicional que servirá para indicar que carácter delimitador se usará en ese fichero (para poder parsearlo). Consola Web SOFIA2 Página 32/221

33 Este campo (Delimitador CSV) será editable y dicho carácter se utilizará para el parseo del archivo para la carga de sus datos. También se debe seleccionar el caracter decimal utilizado en el fichero. Adicionalmente se le indicará si el archivo a cargar incluye encabezados que contengan los ids de las columnas y que servirán para identificar a los atributos de la ontología a generar. Una vez seleccionados estos datos, se pulsará sobre el botón Cargar atributos en Excel/CSV. Se cargará una tabla que incluirá los datos del Excel: - En caso de que la primera fila contenga encabezados:. En caso de que no contenga encabezados: Consola Web SOFIA2 Página 33/221

34 - En la primera columna se muestra el Identificador de Columna. Si no se ha seleccionado el check Ids de columna en la primera fila se mostrarán vacíos. En ambos casos es un campo editable. - Como segunda columna se mostrarán los datos correspondientes a la segunda fila del fichero, para que sirva de muestra. - En la tercera columna se mostrará el tipo de datos al que pertenece el dato de la columna. En la versión actual se permiten los tipos: String, Boolean, Number, Geometry-LAT y Geometry-LON. Es modificable y debe definirlo el usuario. En principio está seleccionado el tipo String. o En cuanto a los tipos, sólo se permite un tipo geográfico (una combinación de Geometry-LAT y Geometry-LON). Y siempre que haya uno de esos tipos, tiene que estar el otro. Como validación adicional, tampoco se pueden seleccionar varios tipos de esos dos (más de un Geometry-LAT o más de un Geometry-LON). - La cuarta columna mostrará un check que permitirá seleccionar qué columnas se cargarán durante el proceso. Debajo de la tabla se incluyen dos botones. Generar Esquema y Seleccionar otro fichero. Seleccionar otro fichero, eliminará el fichero seleccionado y vaciará la tabla de atributos, el esquema generado y la instancia asociada al esquema. Al pulsar sobre Generar Esquema, se generará el esquema correspondiente, utilizando para ello los atributos seleccionados en la tabla (con sus identificadores y tipos asociados) y el nombre de la ontología. Se cargará en la sección Esquema y se desplegará de forma automática. Consola Web SOFIA2 Página 34/221

35 Bajo el esquema se encuentra un botón Generar Instancia. Si se pulsa sobre Generar Instancia, se generará una instancia de la ontología utilizando el esquema generado. Consola Web SOFIA2 Página 35/221

36 Para terminar, se pulsará sobre Crear, que creará la ontología y cargará los datos incluidos en el Excel. Finalizado el proceso, se redirigirá a la pantalla de consulta, donde se mostrará un informe de la carga de datos: Además de crear la ontología, se volcará la información de ésta en la BDTR y estando así lista para ser consumida. Consola Web SOFIA2 Página 36/221

37 4.5 Estado de carga de Excel A través de esta opción se nos permite consultar el estado de carga de ficheros Excel en Mis ontologías. Esta funcionalidad está pensada para ficheros de gran tamaño donde el proceso de carga puede ser largo. Esta opción de menú está disponible para Rol Colaborador y Rol Administrador. La pantalla que se nos mostrará en esta opción será la siguiente: Aparece un listado con los procesos de carga de Mis ontologías desde Excel/CSV donde se informa del Nombre de la ontología, Estado en el que se encuentra, número de registros que se han cargado y la fecha/hora de la última carga realizada. Si se selecciona el botón muestra un resumen de la última carga. se Pulsando sobre Actualizar estado de carga se recargan los datos de la tabla con la información actualizada de los procesos de subida. Consola Web SOFIA2 Página 37/221

38 4.6 Alta Ontología desde Colección A través de esta opción se permite crear ontologías desde colecciones de MongoDB. Conectando con una instancia de MongoDB ya existente se convierte de forma visual una colección en una ontología. Esta opción de menú está disponible para Rol Colaborador y Rol Administrador. La pantalla que se nos mostrará en esta opción será la siguiente: Seleccionando una colección de las existentes en la BDTR aparece el Registro de la Colección con el botón Generar Esquema. Al pulsar Generar esquema se muestra el detalle del esquema de la ontología a crear Consola Web SOFIA2 Página 38/221

39 Por último en el apartado Parametrización podemos configurar la ontología: activa, pública/privada y configuración BDTR y BDH. Para guardar la ontología pulsar el botón Crear. 4.7 Listado de Ontologías Únicamente los usuarios dados de alta en la plataforma con roles Colaborador y Administrador tendrán la posibilidad de Listar ontologías en la plataforma. Los usuarios Administradores tendrán plenos derechos sobre todas las ontologías, por otro lado el Colaborador podrá gestionar todas las ontologías que sean de su propiedad. Al acceder a la funcionalidad mediante la opción de menú Mis Ontologías se mostrará la siguiente página: Consola Web SOFIA2 Página 39/221

40 Se permitirá realizar búsquedas sobre las ontologías que se tengan permisos. Para filtrar la información mostrada en el listado se pueden cumplimentar los campos: Nombre. Se permitirá realizar búsquedas parciales, es decir, si se introduce un A y se pulsa el botón Buscar se listarán las ontologías que empiecen por esa letra. Descripción: Se podrán realizar búsqueda sobre textos que puedan estar contenidos en las descripciones. Para acceder al detalle de las ontologías que se muestran en el listado se deberá pulsar sobre el botón situado a la derecha de cada una de las entradas mostradas en el listado. Las opciones que se permiten realizar desde esta pantalla dependerá de los permisos que tenga el usuario que este visualizando la ontología: Usuarios logados con rol Administrador: Todas las opciones (modificar y dar de baja). Usuarios registrados con rol Colaborador: Todas las opciones sobre las ontologías de las que es propietario, para el resto de ontologías que puede visualizar únicamente accederá en modo consulta. 4.8 Modificación de ontologías Las ontologías podrán ser modificadas desde la opción de menú Mis Ontologías, y sólo si se tienen permisos para ello. Se ha de hacer clic sobre el icono de ver que aparece en listado de ontologías: y posteriormente en el botón de Modificar. Es posible modificar toda la información de una ontología (descripción, esquema, identificación, etc.). Los campos Versión y Versión de Plantilla utilizada hacen referencia a la Versión de Consola Web SOFIA2 Página 40/221

41 Plantilla Actual y la Versión con la que se dio de alta la ontología respectivamente, son campos únicamente informativos, al igual que el campo Nombre. Aparecerá un formulario como el de la creación pero con la información de la ontología introducida en el momento de la creación: Consola Web SOFIA2 Página 41/221

42 Consola Web SOFIA2 Página 42/221

43 Podrán editar ontologías los usuarios que tengan privilegios para ello: Administradores: Podrán editar cualquier ontología. Colaboradores: Únicamente podrán editar sus propias ontologías o aquellas sobre las que tenga permisos. 4.9 Baja de ontologías Desde la Consola Web también es posible dar de baja ontologías, al modificar una ontología es posible indicar si la ontología estará activa ( ) o no ( ). Se puede considerar el borrado lógico de la ontología. Los permisos para poder dar de baja la ontología son los propios para poder editarla: Administradores: Podrán editar cualquier ontología. Colaboradores: Únicamente podrán editar sus propias ontologías o aquellas sobre las que se tengan permisos. También es posible eliminar una ontología si se tiene permisos para ello o si es el propietario. Se ha de acceder al detalle de la ontología desde el listado de ontologías y pulsar sobre el botón de Dar de baja. En el caso de tratarse de una Ontología Padre, sólo se podrá eliminar si no existe ninguna Ontología Hija que extienda de ella Suscripción a Ontologías Se puede acceder a esta opción de menú desde Rol Colaborador y Rol Usuario. Desde la opción de menú Mis Suscripciones es posible buscar ontologías por los siguientes filtros: Nombre de la ontología Consola Web SOFIA2 Página 43/221

44 Descripción Al hacer clic en el botón de Buscar se buscarán todas las ontologías que cumplan con los filtros indicados. Las ontologías que se mostrarán en los dos listados que aparecen en la página serán: Listado de Ontologías: Las ontologías públicas a las que se puede suscribir el usuario logado y que todavía no han sido suscritas. Listado de mis Suscripciones: Las ontologías propias, as que ya han sido suscritas y sobre las que el administrador ha dado permisos al usuario. Consola Web SOFIA2 Página 44/221

45 Desde cualquiera de los dos listados, los usuarios podrán suscribirse o desuscribirse a las ontologías mostradas. Para ello desde el listado se pulsará en la opción de detalle ontología a la que se desee suscribirse o desuscribirse. de la Al hacer clic sobre aparecerá otra vista en la que se mostrará información sobre la ontología y los botones desuscribirse. desde los que se podrá suscribirse o Consola Web SOFIA2 Página 45/221

46 Si se pulsa sobre Suscribirse aparecerá una ventana como la siguiente: En el momento en el que se pulsa sobre Aceptar el usuario quedará suscrito a la ontología y recibirá notificaciones sobre ella periódicamente. Es importante indicar que una vez que un usuario se ha suscrito a una ontología adquiere los permisos de QUERY en ese mismo momento. El usuario podrá desuscribirse de las ontologías desde el listado listado de mis suscripciones, haciendo clic en y pulsando sobre el botón Desuscribirse. Aparecerá una ventana como la siguiente, que permitirá anular la suscripción a la ontología. Al pulsar sobre Aceptar, el usuario dejará de recibir notificaciones de inserciones de ontología Autorizaciones a mis Ontologías Únicamente los usuarios con el rol de administrador podrán acceder a ella y cambiar los permisos que tienen los usuarios sobre las ontologías del Sistema. La Plataforma cuenta con tres roles: Administrador Colaborador Usuario Según el rol los usuarios tendrán unos permisos u otros para interoperar con la Plataforma. ROL_USUARIO: Usuarios con permisos básicos. Los usuarios con este rol, podrán suscribirse y realizar consultas sobre ontologías y datos públicos, así como crear sus propios KPs. El detalle se puede ver en el punto 4 Acceso Rol Usuario. Consola Web SOFIA2 Página 46/221

47 ROL_COLABORADOR: Son usuarios que podrán dar de alta KPs y ontologías, definir consultas y suscribirse a ontologías. El detalle se puede ver en el punto 5 Acceso Rol Colaborador. ROL_ADMINISTRADOR: Son usuarios que podrán gestionar todas las áreas de la Consola Web de la Plataforma, podrán dar de alta usuarios, ontologías, KPs, otro tipo de información, definir autorizaciones entre usuarios y ontologías. El detalle se puede ver en el punto 6 Acceso Rol Administrador. Los permisos que tiene un usuario sobre una ontología están limitados por el rol y por los permisos que el administrador aplique por medio de esta funcionalidad. Los permisos que se pueden asociar a cada usuario en relación con una ontología son los siguientes: QUERY: Permitirá realizar consultas sobre las inserciones de ontologías que realicen los KPs dados de alta por el usuario propietario. INSERT: Permitirá realizar inserciones de ontología por los KPs dados de alta por el usuario propietario. ALL: EL usuario con estos privilegios sobre una ontología englobará los permisos QUERY e INSERT. Al acceder a la funcionalidad mediante la opción de menú se observa el listado de los permisos que tiene cada usuario para cada una de las ontologías: Para crear una nueva autorización se debe seleccionar un usuario, una ontología y el tipo de permiso que se desea dar al usuario seleccionado sobre la ontología y pulsar sobre el botón de Guardar. Una vez que se apliquen los permisos aparecerán en el listado inferior. El listado de autorizaciones se sitúa en la parte inferior de la página, permitiendo la eliminación de los Consola Web SOFIA2 Página 47/221

48 registros mostrados pulsando el botón privilegios. situado a la derecha de cada asociación de Para que un usuario pueda crear Ontologías Hijas a partir de una Padre, el usuario creador (o un usuario con ROL_AMINISTRADOR) debe de autorizar al usuario a utilizar la Ontología Padre previamente. Consola Web SOFIA2 Página 48/221

49 5 GESTIÓN ONTOLOGÍAS DE GRUPO A través de la opción de menú Crear Ontología de Grupo un usuario con rol colaborador o rol administrador podrá definir y dar de alta en el Sistema nuevas ontologías de grupo. El formulario está accesible desde el menú en la opción de Ontologías de Grupo, el usuario deberá indicar: Nombre con el que desea identificar la nueva ontología de grupo Tiempo en segundos en el que el SIB debe componer las instancias de grupo. Si la ontología será pública para el resto de usuarios. Descripción para indicar lo que pretende representar la ontología de grupo. Deberá seleccionar las ontologías que componen la ontología de grupo. Las ontologías disponibles para seleccionar son ontologías públicas y sobre las que el usuario tiene permisos. El usuario podrá crear una o varias instancias de ontología de grupo. Para crear una instancia de ontología, se deberá definir un nombre de instancia o Se deberá seleccionar para cada una de las ontologías de grupo que componen la ontología de grupo, el atributo de agrupación. o Y para cada atributo de agrupación el valor por el que se desea agrupar, también para cada una de las ontologías. Al acceder a la funcionalidad el aspecto será el siguiente: Consola Web SOFIA2 Página 49/221

50 Tendrán privilegios para crear ontologías de grupo los usuarios con roles Administrador o Colaborador y podrán crear sobre las ontologías sobre las que tengan permisos. 5.1 Listado de Ontologías de Grupo Únicamente los usuarios dados de alta en la plataforma con roles Colaborador y Administrador tendrán la posibilidad de Listar ontologías de grupo de la plataforma. Los usuarios Consola Web SOFIA2 Página 50/221

51 Administradores tendrán plenos derechos sobre todas las ontologías, por otro lado el Colaborador podrá gestionar todas las ontologías que sean de su propiedad. Al acceder a la funcionalidad mediante la opción de menú Mis Ontologías Grupo se mostrará la siguiente página: Se permitirá realizar búsquedas sobre las ontologías que se tengan permisos. Para filtrar la información mostrada en el listado se podrán cumplimentar los campos: Nombre. Se permitirá realizar búsquedas parciales, es decir, si se introduce un A y se pulsa el botón Buscar se listarán las ontologías de grupo que empiecen por esa letra. Descripción Para acceder al detalle de las ontologías de grupo que se muestran en el listado se pulsará sobre el botón situado a la derecha de cada una de las entradas mostradas en el listado. Al acceder al detalle de ontología de grupo se mostrará todo el detalle de la ontología, y se podrá modificar o eliminar la ontología de grupo si se tiene permisos para ello. Las opciones que se permiten realizar desde esta pantalla dependerá de los permisos que tenga el usuario que este visualizando la ontología: Usuarios logados con rol Administrador: Todas las opciones. Usuarios registrados con rol Colaborador: Todas las opciones sobre las ontologías de las que es propietario, para el resto de ontologías que puede visualizar únicamente accederá en modo consulta. Consola Web SOFIA2 Página 51/221

52 5.2 Modificación de Ontologías de Grupo Las ontologías de grupo podrán ser modificadas desde la opción de menú Mis Ontologías de grupo, haciendo clic en la ontología de grupo que se desee cambiar, sobre el icono de edición que aparece en listado de ontologías:. Es posible modificar toda la información de una ontología de grupo (descripción, temporizador, identificación, etc.). Es posible modificar los valores de las instancias definidas, así como crear nuevas instancias o eliminarlas, haciendo clic sobre la instancia que se desee modificar. Aparecerá un formulario como el de la creación pero con la información de la ontología introducida en el momento de la creación: Podrán editar ontologías los usuarios que tengan privilegios para ello: Administradores: Podrán editar cualquier ontología. Colaboradores: Únicamente podrán editar sus propias ontologías. 5.3 Baja de Ontologías de Grupo Desde la Consola Web también es posible dar de baja ontologías de grupo, al modificar una ontología de grupo es posible indicar si la ontología estará activa ( ) o no ( ). Se puede considerar el borrado lógico de la ontología. Consola Web SOFIA2 Página 52/221

53 Los permisos para poder dar de baja la ontología son los propios para poder editarla: Administradores: Podrán editar cualquier ontología. Colaboradores: Únicamente podrán editar sus propias ontologías. 5.4 Suscripción a Ontologías de Grupo Se puede acceder a esta opción de menú desde Rol Colaborador y Rol Usuario. Desde la opción de menú Mis Suscripciones es posible buscar ontologías de grupo por los siguientes filtros: Nombre de la ontología de grupo Descripción: Al hacer clic en el botón de Buscar se buscarán todas las ontologías de grupo que cumplan con los filtros indicados. Las ontologías que se mostrarán en los dos listados que aparecen en la página serán: Listado de Ontologías de grupo: Las ontologías de grupo públicas a las que el usuario no está suscrito. Listado de Mis Suscripciones: Las ontologías de grupo a las que el usuario está suscrito o sobre las que el administrador ha dado permisos ALL, INSERT o QUERY al usuario. Consola Web SOFIA2 Página 53/221

54 Desde lo listados, los usuarios podrán suscribirse o desuscribirse de las ontologías mostradas, pulsando sobre desuscribirse. de la ontología de grupo a la que se desee suscribirse o Al hacer clic sobre desde el listado de ontologías de grupo, aparecerá otra vista en la que se mostrará información sobre la ontología de grupo y los botones. Consola Web SOFIA2 Página 54/221

55 Si se pulsa sobre Suscribirse aparecerá una ventana como la siguiente: En el momento en el que se pulse sobre Aceptar el usuario quedará suscrito a la ontología y recibirá notificaciones sobre ella de forma periódica. Es importante indicar que una vez que un usuario se ha suscrito a una ontología adquiere los permisos de QUERY en ese mismo momento. El usuario podrá desuscribirse de las ontologías desde el listado listado de mis suscripciones, haciendo clic en y pulsando sobre el botón Desuscribirse. Aparecerá una ventana como la siguiente, que permitirá anular la suscripción a la ontología. Al pulsar sobre Aceptar, el usuario dejará de recibir notificaciones de inserciones de ontología. Consola Web SOFIA2 Página 55/221

56 5.5 Autorizaciones Ontología de Grupo Únicamente los usuarios con el rol de administrador podrán acceder a ella y cambiar los permisos que tienen los usuarios sobre las ontologías del Sistema. La Plataforma cuenta con tres roles: Administrador Colaborador Usuario Según el rol los usuarios tendrán unos permisos u otros para interoperar con la Plataforma. ROL_USUARIO: Usuarios con permisos básicos. Los usuarios con este rol, podrán suscribirse y realizar consultas sobre ontologías y datos públicos, así como crear sus propios KPs. El detalle se puede ver en el punto 4 Acceso Rol Usuario. ROL_COLABORADOR: Son usuarios que podrán dar de alta KPs y ontologías, definir consultas y suscribirse a ontologías. El detalle se puede ver en el punto 5 Acceso Rol Colaborador. ROL_ADMINISTRADOR: Son usuarios que podrán gestionar todas las áreas de la Consola Web de la Plataforma, podrán dar de alta usuarios, ontologías, KPs, otro tipo de información, definir autorizaciones entre usuarios y ontologías. El detalle se puede ver en el punto 6 Acceso Rol Administrador. Los permisos que tiene un usuario sobre una ontología están limitados por el rol y por los permisos que el administrador aplique por medio de esta funcionalidad. Los permisos que se pueden asociar a cada usuario en relación con una ontología son los siguientes: QUERY: Permitirá realizar consultas sobre las inserciones de ontologías que realicen los KPs dados de alta por el usuario propietario. INSERT: Permitirá realizar inserciones de ontología para los KPs dados de alta por el usuario propietario. ALL: EL usuario con estos privilegios sobre una ontología englobará los permisos QUERY e INSERT. Al acceder a la funcionalidad mediante la opción de menú se observará el listado de los permisos que tiene cada usuario para cada una de las ontologías: Consola Web SOFIA2 Página 56/221

57 Para crear una nueva autorización se ha de seleccionar el usuario, la ontología de grupo y el permiso que se le quiere aplicar y pulsar sobre el botón de Guardar. Una vez que se apliquen los permisos, aparecerán en el listado inferior la nueva autorización junto con el resto de autorizaciones. Es posible eliminar una autorización pulsando en el listado sobre el botón situado a la derecha de cada asociación de permisos: Consola Web SOFIA2 Página 57/221

58 Consola Web SOFIA2 Página 58/221

59 6 GESTIÓN DE KPS/APPS Permite gestionar los KPs con los que va a interactuar la Plataforma : Crear y modificar KPs Buscar KPs Ver KPs Activos Gestionar los Tokens e instancias asociadas a un KP. 6.1 Alta de KPs/APPs A través de la opción de menú Mis KPs/APPs, cualquier usuario registrado en la plataforma podrá dar de alta en el Sistema nuevos KPs. Al hacer clic sobre la opción Crear KP el usuario deberá completar el formulario con la siguiente información: Identificación del KP Clave de cifrado: Ésta clave permitirá enviar mensajes cifrados mediante XXTEA. En la guía APIs SOFIA2 se detalla el uso de la interfaz de KP para usar este método de cifrado. Descripción del KP Se podrán seleccionar las Ontologías u ontologías de grupo con las que va a trabajar el KP Otra meta-información de interés para el KP. Los campos obligatorios son el Identificador de KP y una o varias ontologías asociadas al KP. El resto de campos son opcionales pero es recomendable definir el KP de la forma más clara posible para que represente bien su cometido. Se puede acceder dentro de la Consola Web a la creación de KPs desde el formulario de búsqueda de KPs. Una vez que se accede a la funcionalidad se muestra el formulario: Consola Web SOFIA2 Página 59/221

60 Se cumplimentará la información de nuestro nuevo KP. Una vez completados los campos para definir un nuevo KP se pulsará el botón Crear situado en la parte inferior derecha del formulario. En caso de no cumplimentar alguno de los campos obligatorios no se permitirá dar de alta el KP mostrando un mensaje informativo. Una vez guardada la información del nuevo KP se mostrará el detalle del KP creado: Como se ha comentado anteriormente en este punto cualquier usuario podrá crear KPs en la plataforma, pero dependiendo de los permisos de los que disponga el usuario se podrán crear KPs sobre unas ontologías u otras: Usuario con rol Administrador: Podrá crear KPs sobre cualquier ontología creada en la plataforma. Consola Web SOFIA2 Página 60/221

61 Usuario con rol Colaborador y Resto de Usuarios: Podrá crear KPS sobre las que tenga algún tipo de privilegio: o Podrá crear KPs Consumer sobre ontologías con las que tenga permisos QUERY o ALL. o Podrá crear KPs Producer sobre ontologías con las que tenga permisos INSERT o ALL. o Podrá crear KPs Proconsumer sobre ontologías sobre las que tenga permisos ALL. Es importante recalcar que no se especifica el tipo de KP en el Alta de KP a nivel de productor/consumidor de información, es un aspecto intrínseco a las ontologías con las que está relacionado y los privilegios que tiene el usuario sobre dichas ontologías. 6.2 Listado de KPs Desde esta funcionalidad se permite listado todos los KPS sobre los que el usuario logado tiene privilegios. Al acceder a la funcionalidad desde la opción de menú Mis KPs/APPs se muestra el formulario de búsqueda con el listado de KPs sobre los que el usuario tiene acceso: Se permite realizar búsquedas por los siguientes campos: Ontología: Ontologías con las que está relacionado un KP. Consola Web SOFIA2 Página 61/221

62 Ontología de grupo: Ontologías de grupo con las que puede estar relacionado el KP Nombre: Nombre o Identificador del KP. Se permitirá realizar búsquedas parciales, es decir, si se introduce un A y se pulsa el botón Buscar se listarán los KPs que empiecen por esa letra. Descripción: El funcionamiento es como el del campo Nombre. Una vez introducidos los valores para realizar el filtrado se debe pulsar el botón Buscar situado en la parte inferior derecha del formulario. Adicionalmente desde el formulario se da la opción de crear un nuevo KP y acceder a la funcionalidad descrita en el punto 9.1. Desde el listado se podrá acceder al detalle del KP, modificarlo o eliminarlo Los KPs que se mostrarán en función al rol del usuario logado en la Consola Web serán los siguientes: Usuarios con rol Administrador: Podrán realizar toda la operativa definida sobre todos los KPs dados de alta en la plataforma. Usuarios con rol Colaborador y resto de Usuarios: Podrán gestionar los KPs que hayan dado de alta ellos mismos en la plataforma. 6.3 Modificación de un KP Desde la opción de menú Mis KPs/APPs, pulsando sobre la opción, los usuarios podrán modificar toda la información del KP (identificación, descripción, ontologías, etc.) Una vez que se ha accedido a la funcionalidad se muestra el formulario de edición: Consola Web SOFIA2 Página 62/221

63 Las validaciones y restricciones que se realizan en esta página son las mismas que las definidas para el Alta del KP. Tras realizar los cambios que se estimen oportunos en el KP se pulsará el botón Guardar situado en la parte inferior derecha del formulario para registrar dichos cambios. Si todo se ha realizado de forma correcta, se registrarán los cambios y se mostrará el detalle del KP, con los cambios aplicados. Consola Web SOFIA2 Página 63/221

64 Los KPs que se permitirán editar en función al rol del usuario logado en la Consola Web será el siguiente: Usuarios con rol Administrador: Podrán realizar toda la operativa definida sobre todos los KPs dados de alta en la plataforma. Usuarios con rol Colaborador y resto de Usuarios: Podrán gestionar los KPs que hayan dado de alta ellos mismos en la plataforma. 6.4 Gestión de Tokens Desde esta funcionalidad se permite gestionar los Tokens asociados a un KP, tendrán acceso todos los usuarios dados de alta en la plataforma pudiendo gestionar los Tokens sobre los KPs sobre los que se tengan permisos: Usuarios con rol Administrador: Podrá gestionar los Tokens de todos los KPs dados de alta en la plataforma. Usuarios con rol Colaborador y resto de Usuarios: Podrá gestionar los Tokens de todos los KPs de los que sean propietarios. Al acceder a la funcionalidad por medio de la opción de menú Mis Tokens se mostrará la siguiente página: Para poder Gestionar los Tokens de un KP primero se debe seleccionar el KP. Se podrán realizar búsquedas por medio de los siguientes campos: Propietario. Consola Web SOFIA2 Página 64/221

65 Nombre KP: Nombre o Identificador del KP. Se permitirá realizar búsquedas parciales, es decir, si se introduce un A y se pulsa el botón Buscar se listarán los KPs que empiecen por esa letra. Solo visible para usuarios con rol Administrador. Se rellenan los campos con el filtrado que se desee realizar y se pulsará sobre el botón Buscar situado abajo a la derecha: Una vez mostrada la lista de KPs filtrada, se podrá seleccionar un KP para acceder a sus Tokens. Se pulsará sobre el registro de la tabla del KPs sobre el que se desee ver el detalle. Se mostrará en la parte inferior de la pantalla los Tokens relacionados con el KP. Se puede realizar la siguiente operativa sobre los Tokens que se muestran en el listado: Activar o Desactiva un Token: Se activará o desactivará mediante el campo Check incluido en la columna del listado Activo. Es importante señalar que Desactivar el Token implicará que los consumidores/productores de información no podrán comunicarse por medio del SIB hasta que se vuelva a activar. Consola Web SOFIA2 Página 65/221

66 Eliminar el Token: implica un borrado físico del Token, por lo que realizar esta acción implicará que habrá que cambiar en la configuración de todas las instancias del KP afectado en caso de querer que éstas se puedan volver a conectar al SIB. Para generar más Tokens para el KP seleccionado se deberá seleccionar un número entre 1 y 10 en el campo de selección situado a la izquierda del botón Generar Tokens ubicado en la parte inferior izquierda del listado de Tokens. Una vez seleccionado el número de Tokens que se desea generar se pulsará sobre el botón Generar Tokens. Al generar el número de Tokens seleccionados se mostrará un mensaje informativo de que la operación se realizó correctamente. Una vez creados se mostrarán en el listado de Tokens en estado Desactivado por defecto: 6.5 Gestión de Instancias de KPs En Sofia2 se permiten dos tipos de instancias de KPs, las Instancias de KP Dinámicas y las Instancias de KPs Estáticas: Instancias de KPs Estáticas: Son las Instancias de KP registradas en la plataforma mediante la Consola Web. Éste tipo de instancia está asociada a un KP en concreto. Se permite su gestión desde la Consola Web como se detallará a continuación. Instancias de KPs Dinámicas: Se generan en función a los mensajes SSAP JOIN que envían los KPs para conectarse al SIB, y se destruyen una vez que el KP envía el mensaje SSAP LEAVE para finalizar la sesión. Su tiempo de vida es el tiempo de duración de la sesión SSAP. La operativa sobre las instancias de KPs estará restringida de la siguiente forma: Consola Web SOFIA2 Página 66/221

67 Los usuarios que tengan asociado un rol Administrador podrán acceder a la Gestión de Instancias de KPs para todos las Instancias de todos los KPs dados de alta en la plataforma. El resto de usuarios podrán gestionar las Instancias de los KPs de los que sean propietarios. Al acceder a la funcionalidad mediante la opción de menú Mis Instancias KP/APP se muestra la siguiente página: Desde ésta página se realiza un primer filtrado de los KPs sobre los que se quiera operar. Una vez localizado el KP sobre el que se desea trabajar se pulsará sobre el botón en la parte derecha del KP listado. situado A continuación se mostrará la siguiente pantalla para gestionar las Instancias del KP seleccionado: Consola Web SOFIA2 Página 67/221

68 Como se puede ver en la pantalla se muestra la siguiente información: Identificación: Muestra el identificador de la Instancia. o Instancias Dinámicas: para el caso de las Instancias dinámicas hará referencia al identificador enviado en el mensaje SSAP JOIN, el cual no validará salvo para comprobar que no se trata de una Instancia Estática registrada por la plataforma. Un mensaje JOIN con un identificador de instancia que se haya utilizado para abrir una sesión previa, provoca que se caduque la sesión previa y se abra una nueva sesión con la sessionkey que se envía en la respuesta del segundo JOIN. o Instancias Estáticas: Informa del valor dado de alta por el creador de la Instancia. Última IP: Indica la última IP con la que se conecto la instancia del KP. Modo IPStrict: El valor de la columna hará referencia a las Instancias Estáticas, indicando si se usa o no éste modo de control: Si el modo IPStrict está desactivado: Un segundo JOIN con el mismo identificador de KP generará una nueva sesión SSAP caducando la antigua sin comprobar la IP de la que proviene. No obstante, actualizará el campo de última dirección IP. Si el modo IPStrict está activado: Un segundo JOIN con el mismo identificador de KP generará una nueva sesión SSAP caducando la antigua solo si proviene desde la IP que tenga almacenada dicha instancia de KP. En caso de provenir de una IP distinta, se rechaza. Instancia Estática: Se mostrarán tanto las Instancias de KP generadas dinámicamente como las instancias de KP registradas de forma estática. Cuando esta columna esté Consola Web SOFIA2 Página 68/221

69 marcada indicará que la Instancia mostrada es de tipo estático, en caso contrario indicará que se tratas de una instancia dinámica. Para las instancias generadas dinámicamente no se permite ni la edición ni la eliminación de las mismas. Se permiten realizar las siguientes operaciones sobre las Instancias de KPs Estáticas dadas de alta en la plataforma desde el listado: Eliminación: Para poder eliminar una Instancia Estática se pulsará sobre el botón situado a la derecha de las Instancias de KP listadas. Una vez que se pulse sobre el botón eliminar, en el caso de que hubiera una sesión abierta ésta quedará invalidada en ese mismo momento, no permitiendo a la Instancia de KP comunicarse con el SIB. Edición: Para poder editar una Instancia Estática se debe pulsar sobre el botón situado a la derecha de las Instancias de KP listadas. Una vez localizada la Instancia Estática sobre la que se desee trabajar se pulsará sobre el botón indicado, accediendo a la siguiente página de edición: En el formulario indicado se permitirá editar la siguiente información: Identificador del KP: Se permitirá modificar el nombre identificativo de la instancia del KP. Hay que tener en cuenta que cambiar el nombre identificativo teniendo una sesión activa para dicha instancia provocará la invalidación de la misma. Modo IPStrict: Se permitirá activar y desactivar el modo de control. Los cambios que se realicen en el modo de control implicará que afectará a la sesión activa si la tuviera. Consola Web SOFIA2 Página 69/221

70 7. CONTENEDOR KPs/APPS El contenedor de KP s consiste en un nuevo modelo que permite el despliegue de Apps Sofia2, gestionando su ejecución y encargándose del envío al SIB de la información generada por el KP Crear KPs/APPs en Contenedor Para crear un KP en Contenedor se debe acceder a la opción de menú Contendor KPs/APPs, Crear KPs/APPs en contenedor y se muestra la siguiente pantalla: Se debese En esta pantalla es necesario especificar información acerca del KP que se va a dar de alta. Consola Web SOFIA2 Página 70/221

71 KP: Identificador del KP registrado en Sofia2 a registrar en el contenedor. Instancia de KP: Identificador de KP a registrar en el contenedor Tipo de contenedor de KP: En la versión actual todos son los KPs son temporizados y se lanzan periódicamente conforme a la expresión CRON. Lenguaje: Lenguaje de programación del KP, permite al contenedor seleccionar el runtime con el que lanzar el KP. Timeout: Tiempo en segundos que el contenedor asigna al KP para completar su ejecución. Si el KP no finaliza en dicho tiempo, el contenedor aborta la ejecución. Descripción: Descripción informativa del contenedor. Prefijo de ficheros de mensajes: Prefijo que tendrán los ficheros de mensajes generados por el fichero ejecutable. Propiedades: Pares de clave-valor con las propiedades que necesita el programa. Estas propiedades se utilizan por el contenedor de KPs para crear un fichero en el directorio de ejecución con dichas propiedades. El fichero de propiedades tendrá el mismo nombre que el programa junto con la extensión.properties. Para consultar el listado de KPs en contenedor de KPs se dispone en la consola la opción: Contenedor KP s/apps > Mis KPs/APPs en Contenedor. Desde este listado se puede visualizar, modificar y eliminar los KPs en contenedores. Consola Web SOFIA2 Página 71/221

72 8. REGLAS Desde ésta funcionalidad se permitirá la gestión de Reglas CEP y Script para los siguientes tipos de usuarios: Para los usuarios registrados en la plataforma que tengan asociado rol Administrador se les permitirá gestionar todos las reglas dadas de alta en la plataforma. Para los usuarios registrados en la plataforma que tengan asociado rol Colaborador podrán crear Reglas CEP y Script sobre Ontologías sobre las ontologías que tengan permisos Insert o All. Únicamente podrán visualizar y modificar Reglas CEP y Script sobre Ontologías que hayan dado de alta Crear Regla con Wizard Desde esta funcionalidad se puede crear Reglas CEP y Script de manera sencilla. Se accede a ella seleccionando la opción de menú Crear Regla con Wizard y aparece la siguiente pantalla: Seleccionando la opción que se desea realizar y el botón Siguiente se accede a la creación de la Regla con el asistente pasando por varios pasos para agilizar y simplificar su creación. Consola Web SOFIA2 Página 72/221

73 8.2. Creación Script Para profundizar en el desarrollo de Scripts en SOFIA se recomienda la lectura de la Guía de Script. Se puede acceder a la funcionalidad por medio de la opción de menú Mis Script y el botón Crear Script. Se visualizarán las siguientes páginas en función del tipo de Script a crear. (Scripts tipo Timmer, Scripts sobre Ontologías, Scripts sobre Ontologías Padre y Scripts tipo Cep): Scripts tipo Timmer Los Script tipo Timmer tienen la característica principal de que se ejecutan únicamente cada cierto período de tiempo configurable, no están asociados a ningún otro evento. Para crear Script temporizados se deberá cumplimentar los campos: Identificación: Se deberá indicar el nombre identificativo del Script. Consola Web SOFIA2 Página 73/221

74 Temporizador: Tiempo en segundos que indica la frecuencia con la que se ejecutará el Script siempre que esté Activo. Nos permite introducir expresiones CRON. Operaciones disponibles: Se puede seleccionar entre las operaciones creadas anteriormente las que se quieren añadir en los diferentes bloques (If, Then, Else, Error) para facilitar la creación del Script. Timeout: Tiempo en segundos que permitirá cancelar un Script que tarde en ejecutarse más tiempo del indicado. Bloque THEN: Para este tipo de Script se deberá informar este campo. El resto de campos opcionales en la creación de un Script Temporizado: Activa: Se deberá marcar este campo para que se ejecute el Script. Bloque IF: En el caso de que se informe este campo cada vez que se ejecute el script se evaluará la condición que se indique, devolviendo el control al contenedor de Script. Para poder devolver en este bloque los valores true o false al contenedor de Script se deberá emplear la instrucción return true o return false dentro del bloque de Script para que el contendor de Script pueda manejar el flujo deseado en su ejecución. Bloque ELSE: Este campo para este tipo de Script es opcional. Es necesario que el Bloque IF esté informado para indicar el Bloque ELSE, no tendría sentido el Bloque ELSE si no se informa el Bloque IF. Para que se ejecute este bloque de Script el resultado de la condición del Bloque IF debe dar como resultado false Bloque ERROR: Este campo aunque opcional será importante informarlo, en caso de que hubiera algún error no controlado en la ejecución del Script el contenedor de Scripts ejecutaría dicho bloque. Un ejemplo de creación de Script temporizado sería el siguiente: Consola Web SOFIA2 Página 74/221

75 Como se ha comentado anteriormente únicamente podrán crear Scripts Temporizados los usuarios registrados en la plataforma con rol asociado Administrador. En caso de estar logado con un usuario con rol asociado Colaborador se mostrará el siguiente mensaje en la parte inferior del formulario de creación de Scripts: En caso de incluir alguna instrucción que viole las restricciones de Seguridad Activa como se muestra en la imagen, se mostrará un mensaje informando del error: Consola Web SOFIA2 Página 75/221

76 Scripts sobre ontologías Los Scripts sobre Ontologías tienen la principal característica de que se ejecutan cada vez que se realice una inserción de ontología determinada indicada por el creador del Script. Para crear Script sobre ontologías se deberá cumplimentar los campos: Identificación: Se deberá indicar el nombre identificativo del Script. Ontología: Se mostrará un cuadro con las ontologías disponibles sobre las que el usuario logado tiene los permisos de INSERT o ALL. Según se seleccionen, se mostrarán en el cuadro de Ontologías Seleccionadas de la derecha. Timeout: Tiempo en segundos que permitirá cancelar un Script que tarde en ejecutarse más tiempo del indicado. Bloque IF: Cada vez que se ejecute el script se evaluará la condición que se indique en este campo, devolviendo el control al contenedor de Script. Para poder devolver en este bloque los valores true o false al contenedor de Script se deberá emplear la instrucción return true o return false dentro del bloque de Script para que el contendor de Script pueda manejar el flujo deseado en su ejecución. Bloque THEN: En este bloque se indicarán las acciones a ejecutarse por el contenedor de Script una vez evaluada la condición del Bloque IF con resultado true. Para este tipo de Script se deberá informar este campo. El resto de campos opcionales en la creación de un Script sobre ontologías: Activa: Se deberá marcar este campo para que se ejecute el Script. Bloque ELSE: Este campo para este tipo de Script es opcional. Es necesario que el Bloque IF esté informado para indicar el Bloque ELSE, no tendría sentido el Bloque ELSE si no se informa el Bloque IF. Para que se ejecute este bloque de Script el resultado de la condición del Bloque IF debe dar como resultado false. Bloque ERROR: Este campo aunque opcional será importante informarlo, en caso de que hubiera algún error no controlado en la ejecución del Script el contenedor de Scripts ejecutaría dicho bloque. Consola Web SOFIA2 Página 76/221

77 Una vez cumplimentados los datos para dar de alta un nuevo Script, para proceder a guardar los datos se deberá pulsar sobre el botón Crear situado en la parte inferior derecha del formulario. Las validaciones que se realizarán para este tipo de Script son las mismas que para los Script Temporizados salvo los campos obligatorios requeridos. Una vez guardado el Script se mostrará la página de detalle del Script creado, la operativa de la página de detalle se explica en el apartado 10.4 Detalle de Script Scripts sobre Ontologías Padre Los Scripts sobre Ontologías Padre tienen la principal característica de que se ejecutan cada vez que se realice una inserción de ontología padre determinada indicada por el creador del Script. Para crear Script sobre ontologías padre se deberá cumplimentar los campos: Consola Web SOFIA2 Página 77/221

78 Identificación: Se deberá indicar el nombre identificativo del Script. Ontología: Se mostrará un cuadro con las ontologías padre disponibles sobre las que el usuario logado tiene los permisos de INSERT o ALL. Según se seleccionen, se mostrarán en el cuadro de Ontologías Seleccionadas de la derecha. Timeout: Tiempo en segundos que permitirá cancelar un Script que tarde en ejecutarse más tiempo del indicado. Bloque IF: Cada vez que se ejecute el script se evaluará la condición que se indique en este campo, devolviendo el control al contenedor de Script. Para poder devolver en este bloque los valores true o false al contenedor de Script se deberá emplear la instrucción return true o return false dentro del bloque de Script para que el contendor de Script pueda manejar el flujo deseado en su ejecución. Bloque THEN: En este bloque se indicarán las acciones a ejecutarse por el contenedor de Script una vez evaluada la condición del Bloque IF con resultado true. Para este tipo de Script se deberá informar este campo. El resto de campos opcionales en la creación de un Script sobre ontologías: Activa: Se deberá marcar este campo para que se ejecute el Script. Bloque ELSE: Este campo para este tipo de Script es opcional. Es necesario que el Bloque IF esté informado para indicar el Bloque ELSE, no tendría sentido el Bloque ELSE si no se informa el Bloque IF. Para que se ejecute este bloque de Script el resultado de la condición del Bloque IF debe dar como resultado false. Bloque ERROR: Este campo aunque opcional será importante informarlo, en caso de que hubiera algún error no controlado en la ejecución del Script el contenedor de Scripts ejecutaría dicho bloque. Consola Web SOFIA2 Página 78/221

79 Una vez cumplimentados los datos para dar de alta un nuevo Script, para proceder a guardar los datos se deberá pulsar sobre el botón Crear situado en la parte inferior derecha del formulario. Las validaciones que se realizarán para este tipo de Script son las mismas que para los Script Temporizados salvo los campos obligatorios requeridos. Una vez guardado el Script se mostrará la página de detalle del Script creado, la operativa de la página de detalle se explica en el apartado 10.4 Detalle de Script Scripts tipo Cep Los Scripts tipo Cep tienen la principal característica de que se ejecutan cada vez que se produce un evento indicado por el creador del Script. Para crear Script tipo Cep se deberán cumplimentar los campos: Identificación: Se deberá indicar el nombre identificativo del Script. CEP: Se mostrará un cuadro con las reglas Cep disponibles. Según se seleccionen, se mostrarán en el cuadro de Cep Seleccionadas de la derecha. Timeout: Tiempo en segundos que permitirá cancelar un Script que tarde en ejecutarse más tiempo del indicado. Consola Web SOFIA2 Página 79/221

80 Bloque IF: Cada vez que se ejecute el script se evaluará la condición que se indique en este campo, devolviendo el control al contenedor de Script. Para poder devolver en este bloque los valores true o false al contenedor de Script se deberá emplear la instrucción return true o return false dentro del bloque de Script para que el contendor de Script pueda manejar el flujo deseado en su ejecución. Bloque THEN: En este bloque se indicarán las acciones a ejecutarse por el contenedor de Script una vez evaluada la condición del Bloque IF con resultado true. Para este tipo de Script se deberá informar este campo. El resto de campos opcionales en la creación de un Script tipo Cep: Activa: Se deberá marcar este campo para que se ejecute el Script. Bloque ELSE: Este campo para este tipo de Script es opcional. Es necesario que el Bloque IF esté informado para indicar el Bloque ELSE, no tendría sentido el Bloque ELSE si no se informa el Bloque IF. Para que se ejecute este bloque de Script el resultado de la condición del Bloque IF debe dar como resultado false. Bloque ERROR: Este campo aunque opcional será importante informarlo, en caso de que hubiera algún error no controlado en la ejecución del Script el contenedor de Scripts ejecutaría dicho bloque. Consola Web SOFIA2 Página 80/221

81 8.3. Listado de Script Se podrá acceder a la funcionalidad por medio de la opción de menú Mis Scripts. Los usuarios que tengan permisos para acceder a esta funcionalidad visualizarán la siguiente página: Consola Web SOFIA2 Página 81/221

82 Al acceder a la página se muestran todos los Scripts dados de alta sobre los que se tienen permisos. Dependiendo del usuario que ha accedido se visualizarán diferentes Scripts: Usuarios registrados en la plataforma con rol asociado Administrador: Podrán visualizar todos los Scripts, tanto los Temporizados como los creados sobre una ontología. Usuarios registrados en la plataforma con rol asociado Colaborador: Visualizarán los Scripts sobre los que tengan permisos de INSERT o ALL, independientemente de que hayan sido los creadores o no. Desde el formulario se permite realizar búsquedas por nombre/identificador del Script, se podrán realizar búsquedas parciales por el comienzo del nombre del Script. Desde el listado se puede ver el detalle de una Script pulsando el botón situado a la derecha de cada Script. Una vez pulsado el botón se redireccionará a la página de detalle del Script creado. La operativa de la página de detalle se explica en el apartado 10.4 Detalle de Script Detalle de Script Se puede acceder a esta funcionalidad desde el Listado de Scripts y cuando se ha realizado con éxito la creación de un nuevo Script: Consola Web SOFIA2 Página 82/221

83 Desde el detalle de Script ser permite realizar la siguiente operativa: 8.5. Edición de Script La edición de Scripts contendrá la operativa semejante a la creación de Scripts detallada en el punto 10.2 New Script. Al acceder a la funcionalidad desde el Detalle de Script comentado en el punto anterior se muestra la siguiente página: Consola Web SOFIA2 Página 83/221

84 8.6. Reglas CEP Desde esta funcionalidad se puede crear Reglas CEP. Se accede a ella seleccionando la opción de menú Reglas, Mis Reglas CEP y aparece la siguiente pantalla: Pulsando el botón Crear regla se muestra los datos de configuración de la Regla CEP, a continuación vemos un ejemplo: Consola Web SOFIA2 Página 84/221

85 Se debe seleccionar en el combo Eventos CEP el evento al que va a hacer referencia la nueva Regla CEP y pulsar Añadir para incluirla en el cuadro From. En dicho cuadro especificamos la query/filtro que se debe cumplir. En el cuadro Select se especifica el atributo de la ontología que se selecciona en caso de éxito y en el cuadro Insert Into introducimos el nombre de salida que también será el nombre que se le asigna a la Regla CEP Evento CEP Para crear un Evento CEP se accede a la opción de menú Reglas, Mis Eventos CEP, aparece la siguiente pantalla y se pulsa el botón Crear Evento: Consola Web SOFIA2 Página 85/221

86 Los datos del Evento CEP se configuran de la siguiente manera: Se debe seleccionar la ontología a la que va asociada el Evento y pulsar Cargar Campos. Una vez cargados los campos de la ontología, se seleccionan aquellos que se vayan a incluir en el evento y se pulsa Crear para guardar el evento. Consola Web SOFIA2 Página 86/221

87 El evento se ha creado de manera satisfactoria si se muestra al final el detalle de dicho evento. Desde el detalle del evento se puede Modificar pudiendo cambiar los atributos de la ontología definidos anteriormente por otros. Desde el botón Eliminar se procede al borrado del evento, apareciendo un mensaje de confirmación de la eliminación. Consola Web SOFIA2 Página 87/221

88 9. GESTIÓN DE ASSETS 9.1. Crear Asset La funcionalidad descrita en este punto permite crear Assets, los cuales deben estar asociados a un Tipo de Asset, un KP y una Instancia del KP seleccionado. Los usuarios que pueden acceder a esta funcionalidad son los usuarios dados de alta en la plataforma con roles administrador o colaborador asociado: Los usuarios con rol administrador asociado: podrán crear Assets sobre cualquier instancia de KP o Tipo de Asset dado de alta en la plataforma. Los usuarios con rol colaborador podrán dar de alta Asset sobre cualquier Tipo de Asset dado de alta en la plataforma pero únicamente asociarlo a Instancias de KP sobre los que sea propietario. Una vez que se accede a la opción Mis Assets y se pulsa el botón Crear se muestra la página de creación de Asset: Consola Web SOFIA2 Página 88/221

89 La información que se necesita para dar de alta un Asset en la plataforma es la siguiente: Identificación: Nombre identificativo del Asset. El campo será obligatorio. Tipo de Asset: Tipo de Asset al que pertenece. Tras seleccionar el Tipo de Asset al que se desea asociar el Asset, se mostrarán las propiedades configurables asociadas al Tipo de Asset, con las que se dará de alta el Asset. KP: El KP sobre el que se dará de alta el Asset. Una vez seleccionado el KP se mostrarán las instancias asociadas al KP en el campo del presente formulario Instancia. Los KPs que se mostrarán dependerán del rol asociado al usuario registrado como se indica más arriba. Instancia: En función al KP seleccionado se mostrarán sus Instancias Estáticas dadas de alta en la plataforma. Consola Web SOFIA2 Página 89/221

90 Responsable: El responsable que se desee asociar a la gestión del Asset. El campo será opcional. Descripción: Descripción del Asset. Latitud: Campo para indicar la localización geográfica del Asset. Longitud: Campo para indicar la localización geográfica del Asset. Nodo: Nodo o sede a la que estará asociado el Asset, este campo es opcional. TAGs: Tags de búsqueda del Asset dentro de un nodo, los tags estarán formados por caracteres alfanuméricos separados por comas y sin espacios, este campo también es opcional. Una vez cumplimentada la información con la que se desee crear el Asset para hacer efectivos los cambios de deberá pulsar sobre el botón Crear situado en la parte inferior derecha de la página Listar Assets El listado de Asset muestra todos los Asset dados de alta en la plataforma tanto para los usuarios con rol administrador asociado como para el rol colaborador. En el caso de los usuarios que tengan asociado un rol colaborador únicamente verán los Asset de los cuales ellos sean propietarios. Tras seleccionar la opción Mis Assets se mostrará el listado de todos los Assets dados de alta en la plataforma: Consola Web SOFIA2 Página 90/221

91 Las operaciones que se pueden realizar sobre los diferentes Asset dados de alta en la plataforma son las siguientes: Visualización del detalle pulsando sobre el botón. Edición del Asset pulsando sobre el botón. Eliminación de Asset pulsando sobre el botón Detalle de Assets Al acceder a esta funcionalidad la página que se muestra deberá ser la siguiente: Consola Web SOFIA2 Página 91/221

92 9.4. Modificación de Assets Esta funcionalidad permitirá modificar la información asociada a un Asset una vez que haya sido creado. Al acceder a la funcionalidad se mostrará una página similar a la de creación: La operativa es la misma que para la creación de Assets, una vez que cumplimentada la información con la que se desee modificar el Asset para hacer efectivos los cambios se deberá pulsar sobre el botón Guardar situado en la parte inferior derecha de la página Crear tipo de Asset Los usuarios que podrán acceder a esta funcionalidad son los usuarios con roles asociados colaborador y administrador permitiéndoles crear Tipos de Assets. Se accede mediante la opción de menú Tipos de Assets y seleccionando el botón Crear la página que se muestra es la siguiente: Consola Web SOFIA2 Página 92/221

93 Los campos que se muestran en el formulario son los siguientes: Nombre del Tipo: Nombre identificador del tipo de asset que se va a crear. El campo será obligatorio. Descripción: Descripción del tipo de Asset. El campo será opcional. URL Imagen: Dirección del servidor externo donde se ubicará la imagen que define el tipo de Asset. El campo será opcional. Imagen: Imagen que se almacenará en la plataforma que define el tipo de Asset. El campo será opcional. Propiedades del Tipo: Este tipo de propiedades serán comunes a todos los Assets que se creen de este tipo. No son configurables para cada Asset que se cree, como se mostrará a continuación a diferencia de las Propiedades configurables para cada Asset. Será opcional el crear propiedades para el tipo de Asset. Consola Web SOFIA2 Página 93/221

94 o Nombre Propiedad o Valor: Valor fijo para todos los Asset que sean del tipo que se va a crear. o Descripción: Descripción de la propiedad del Asset que se va a crear. Propiedades de Configuración: Son propiedades que se definen para cada creación de un Asset. No se introduce ningún valor en la propiedad dado que en el proceso de creación de un Asset en concreto es cuando se solicita dicho valor. Será opcional la creación de propiedades configurables para el Asset. o Nombre: Nombre de la propiedad que se mostrará en el proceso de creación de un Asset. o Descripción: Descripción de la propiedad. Para añadir Propiedades del Tipo de Asset y Propiedades de Configuración de Asset se deben cumplimentar los campos obligatorios de cada formulario: Una vez cumplimentados se debe pulsar el botón situado en la parte inferior derecha de cada formulario. Una vez pulsado el botón indicado se añadirán al listado que se sitúa en la parte inferior. Los cambios no serán efectivos hasta que se haya cumplimentado el formulario de la información relativa a todo el Tipo de Asset. En el caso se quieran eliminar las propiedades que se van dando de alta se deberá pulsar el botón mostrada en el listado. situado en la parte derecha de la propiedad Consola Web SOFIA2 Página 94/221

95 Una vez cumplimentada la información con la que se desee dar de alta el Tipo de Asset, para hacer efectivos los cambios se deberá pulsar el botón Crear situado en la parte inferior derecha de la página. Una vez guardados los cambios se mostrará el listado de Tipos de Asset dados de alta en la plataforma con el nuevo Tipo de Asset cuyo funcionamiento se detalla en el siguiente punto: Consola Web SOFIA2 Página 95/221

96 Como nota importante a tener en cuenta, una vez que se ha creado un Asset asociado a alguno de los Tipos de Asset que se hayan dado de alta en la plataforma éstos no podrán ser eliminados del sistema Listar tipos de Asset El listado de Tipos de Asset muestra todos los tipos de Asset dados de alta en la plataforma tanto para los usuarios con rol administrador asociado como para el rol colaborador. Tras pulsar sobre la opción correspondiente Tipos de Assets, se mostrará el listado de todos los Tipos de Assets dados de alta en la plataforma: Consola Web SOFIA2 Página 96/221

97 Las operaciones que se pueden realizar sobre los diferentes Tipos de Assets dados de alta en la plataforma son las siguientes: Visualización del detalle: Al pulsar el botón mostrará el detalle del tipo de Asset como se indica en el punto 11.7 Detalle Tipo de Asset. Edición del Tipo de Asset: Al pulsar el botón se redireccionará a la pantalla de edición de Tipo de Asset definida en el punto 11.8 Modificación de Tipo de Asset. Eliminación del Tipo de Asset : Únicamente se podrán eliminar Tipos de Asset que no tengan asociados ningún Asset en el momento de la eliminación. En el caso de tener asociados Asset al Tipo de Asset en el momento de la creación se mostrará un mensaje de error Detalle de Tipo de Asset Al acceder a esta funcionalidad la página que se muestra deberá ser la siguiente: Consola Web SOFIA2 Página 97/221

98 9.8. Modificar tipos de Asset Esta funcionalidad permitirá modificar la información asociada a un Tipo de Asset una vez que haya sido creado. Al acceder a la funcionalidad se mostrará una página similar a la de creación de Tipos de Assets, la única diferencia es que no se permitirá editar el nombre del Tipo de Asset: Consola Web SOFIA2 Página 98/221

99 La operativa es la misma que para la creación de Tipos de Assets. Una vez cumplimentada la información con la que se desee modificar del Tipo de Assets para hacer efectivos los cambios se deberá pulsar sobre el botón Guardar situado en la parte inferior derecha de la página Crear Nodo Mediante esta funcionalidad se permite crear Nodos o sedes donde poder localizar a un Asset. Los usuarios que pueden crear nodos son aquellos que estén dados de alta en la plataforma con roles administrador o colaborador. Para acceder hay que seleccionar la opción de manú Nodos y el botón Crear. Consola Web SOFIA2 Página 99/221

100 La información necesaria para dar de alta un nodo es la siguiente: Identificador: Nombre identificativo del Nodo, campo obligatorio. TAGs: Tags de búsqueda del nodo, formado por caracteres alfanuméricos separados por comas, campo obligatorio. Padre: Nodo padre, un nodo o sede puede pertenecer a otro nodo o sede, no pueden existir relaciones recursivas. Campo opcional Latitud: Campo para indicar la localización geográfica del Nodo. Campo opcional. Longitud: Campo para indicar la localización geográfica del Nodo. Campo opcional Descripción: Descripción del nodo. Campo opcional. Consola Web SOFIA2 Página 100/221

101 9.10. Listar Nodos Al seleccionar la opción Nodos, se muestra el listado con todos los nodos dados de alta en la plataforma, tanto para usuarios administradores como colaboradores, estos últimos sólo podrán ver los Nodos de los cuales sean propietarios. Las operaciones que se pueden realizar sobre los diferentes Nodos dados de alta en la plataforma son las siguientes: Visualización del detalle pulsando sobre el botón. Edición del Nodo pulsando sobre el botón. Eliminación de Nodo pulsando sobre el botón Detalle de Nodo Al acceder a esta pantalla desde el listado de nodos, se selecciona la opción ver muestra lo siguiente:, se Consola Web SOFIA2 Página 101/221

102 9.12. Modificación de un Nodo Esta funcionalidad permitirá modificar la información asociada a un Nodo. Para acceder a ella se debe seleccionar la opción Editar. Consola Web SOFIA2 Página 102/221

103 La operativa es la misma que para la creación de Nodos, una vez que cumplimentada la información con la que se desee modificar el Nodo para hacer efectivos los cambios se deberá pulsar sobre el botón Guardar situado en la parte inferior derecha de la página. Consola Web SOFIA2 Página 103/221

104 10. VISUALIZACIONES Mis Gadgets En la opción de menú Visualizaciones, seleccionar Mis Gadgets y aparecerá la siguiente pantalla: Crear Gadgets Se debe pulsar sobre el botón Crear Gadget en la parte superior derecha. Consola Web SOFIA2 Página 104/221

105 Seleccionando el tipo de gadget que se desea crear, aparece una pantalla para elegir un KP y asignar un nombre al gadget. En el caso de seleccionar HTML Externo, debemos introducir la URL externa. Para guardar, pulsar botón Crear. Estos Gadgets se pueden seleccionar para crear un Dashboard Mis Dashboards Un Dashboard es una interfaz gráfica donde el usuario puede administrar distintos widgets. Al acceder a la opción de menú Visualizaciones y seleccionar Mis dashboards aparece la siguiente pantalla: Crear Dashboards Pulsando sobre el botón Crear Dashboard se accede a la pantalla de creación. Consola Web SOFIA2 Página 105/221

106 Pulsando sobre el icono añadir ( seleccionar. ) aparecen las opciones de nuevos widgets que se pueden Se seleccionan los que se desean y van añadiéndose al Dashboard. Una vez terminado, para guardar el Dashboard se debe pulsar sobre el botón Crear. Consola Web SOFIA2 Página 106/221

107 11. HERRAMIENTAS Estas Herramientas permiten interactuar con la Plataforma Consola BDTR y BDH Permite realizar consultas sobre ontologías almacenadas en la plataforma para recuperar las instancias de tales ontologías enviadas por los KPs. Existen dos bases de datos para almacenamiento de ontologías: BDTR (Base de datos de tiempo real): Almacena las últimas instancias de cada ontología durante la ventana de tiempo considerada como tiempo real para cada ontología. BDH (Base de datos histórica): Almacena para cada ontología las instancias que han dejado de pertenecer a la ventana de tiempo real. Esta base de datos tiene propósito de almacenamiento histórico para futuro procesamiento de esta información. Desde la consola de administración se pueden consulta ambas bases de datos mediante la herramienta Consola BDTR y BDH en la sección Herramientas del menú: Consola Web SOFIA2 Página 107/221

108 La herramienta consiste en un formulario desde el que se puede enviar una sentencia a la correspondiente base de datos, BDTR o BDH, que tiene que seleccionarse en una combo, junto con el tipo de lenguaje utilizado en la sentencia (Nativo o SQL-Like). Asimismo, se dispone un combo que irá registrando el historial de las consultas que se vayan lanzando. Consultas a la BDTR: Para realizar consultas sobre ontologías en la base de datos de tiempo real, hay que seleccionar: o En el combo Base de datos: La opción BDTR. o En el combo Tipo: El tipo de lenguaje utilizado en la sentencia: SQL-Like: Si se utiliza el lenguaje tipo SQL. Nativo: Si se utiliza el lenguaje nativo de la BDTR (MongoDB). o En el campo de texto Query: La sentencia a ejecutar sobre la BDTR, escrita en el tipo de lenguaje seleccionado en el combo Tipo. o En el cuadro Ontologías (de Grupo) disponibles: seleccionar una ontología sobre la que hacer la consulta, haciendo doble clic sobre ella, para que el campo de texto Query se actualice. Consola Web SOFIA2 Página 108/221

109 Como vemos, hemos ejecutado una sentencia utilizando lenguaje SQL-Like. El equivalente en modo Nativa para la consulta anterior sería db.sensorhumedad.find({"sensorhumedad.medida":12}) Los resultados de la sentencia se muestran en la propia página como un documento JSON, que incluye la instancia de la ontología, junto con información de contexto añadida por el SIB cuando se almacenó la instancia: Consola Web SOFIA2 Página 109/221

110 Una vez se haya realizado una consulta sobre la BDTR, aparecerán en pantalla tres iconos debajo del botón Realizar Consulta, expuesto anteriormente. El objetivo de estos iconos es ofrecer al usuario la posibilidad de descargarse la información resultante de la consulta realizada en formato Excel, XML o CSV. Además, el nombre del fichero disponible para la descarga será el correspondiente al nombre de la ontología sobre la que se ha lanzado la consulta. Consola Web SOFIA2 Página 110/221

111 Para conocer en detalle el formato con el que se guarda la información obtenida en los ficheros, se va a incorporar un ejemplo en el que se va a crear una ontología llamada SensorBasico basada en la plantilla BasicSensor. En primer lugar, se muestran los datos devueltos por la consulta realizada sobre la ontología SensorBasico. Una vez realizada la consulta, se pulsa sobre este icono DatosSensorBasico.xml con la siguiente información:, obteniendo el fichero <SensorBasicos> <SensorBasico> <contextdata> <timestamp> <![CDATA[ <$date> t17:40:03.699z</$date> ]]> </timestamp> <kp>kpsensorbasico</kp> <kp_instancia>prueba</kp_instancia> <user>jirejas</user> <session_key>f03d5323-be0e ce7-eac05d52841d</session_key> </contextdata> <BasicSensor> Consola Web SOFIA2 Página 111/221

112 <timestamp> <![CDATA[ <$date> t17:14:00.000z</$date> ]]> </timestamp> <unit>string</unit> <groupid>string</groupid> <assetid>string</assetid> <measure>28.6</measure> </BasicSensor> <_id> <![CDATA[ <$oid>552d34d328634b674d70ce90</$oid> ]]> </_id> </SensorBasico> <SensorBasico> <contextdata> <timestamp> <![CDATA[ <$date> t17:40:47.232z</$date> ]]> </timestamp> <kp>kpsensorbasico</kp> <kp_instancia>prueba</kp_instancia> <user>jirejas</user> <session_key>f03d5323-be0e ce7-eac05d52841d</session_key> </contextdata> <BasicSensor> <timestamp> <![CDATA[ <$date> t17:15:00.000z</$date> ]]> </timestamp> <unit>m</unit> <groupid> k</groupid> <assetid> j</assetid> <measure>30</measure> </BasicSensor> <_id> <![CDATA[ <$oid>552d34ff28634b674d70ce91</$oid> ]]> </_id> </SensorBasico> </SensorBasicos> Como se puede ver, tanto el timestamp como el _id poseen un subcampo con un símbolo $ que debe ser tratado para que el fichero sea creado libre de errores. Para ello, se han localizado estos campos y se han encapsulado dentro de una sección CDATA para que el analizador notifique el contenido sin intentar interpretarlo. Cada mensaje es incorporado dentro de las etiquetas llamadas como el nombre de la propia ontología sobre la que se ha realizado la consulta, y todo esto se encuentra en el interior de una etiqueta generada para almacenar toda esta información. Una vez analizado el fichero XML generado, se procede a pulsar sobre el icono para descargar el fichero en formato Excel, cuyo contenido se muestra a continuación. Consola Web SOFIA2 Página 112/221

113 Si hay un objeto B contenido dentro de otro objeto A, se representará su nombre con la estructura A:B en la primera fila del documento. El valor de este campo se irá almacenando por filas, de manera que ofrece una lectura rápida de la información contenida en el campo y de su nombre completo. Si el objeto B estuviese formado por un array numérico, se representaría como A:B[] con tantas columnas como valores distintos tenga dicho array. En caso de que sea un array de un tipo distinto (String, array), se seguiría la nomenclatura anteriormente expuesta. Por último, pulsando sobre el icono se descargará el fichero DatosSensorBasico.txt que contendrá la siguiente información: Una vez se haga click sobre uno de los iconos, quedarán bloqueados a la espera de que el fichero se genere. Una vez generado y descargado, se desbloquearán de manera que se pueda descargar otro fichero. Consultas a la BDH: Para realizar consultas sobre datos históricos de ontologías en la base de datos histórica, hay que seleccionar: o En el combo Base de datos: La opción BDH. o En el combo Tipo: Se bloquea la opción SQL-Like, ya que este es a su vez el lenguaje nativo del Driver de la BDH (Impala). Por lo que no es posible utilizar otro. o En el campo de texto Query: La sentencia a ejecutar sobre la BDH, escrita en lenguaje SQL-Like. Por las características de la BDH solo se permiten sentencias de tipo SELECT e INSERT. Consola Web SOFIA2 Página 113/221

114 o En el cuadro Ontologías (de Grupo) disponibles: seleccionar una ontología sobre la que hacer la consulta, haciendo doble clic sobre ella, para que el campo de texto Query se actualice. Los resultados de la sentencia se muestran en la propia página como un documento JSON, que devuelve información sobre las columnas de la tabla y una matriz con los resultados en la tabla. Para ello se devuelve dos atributos: o columns: Array con meta-información de cada columna de la tabla de resultados Nombre Tipo de datos Índice en los resultados o values: Matriz con cada uno de los registros de la tabla de resultados El resultado de una sentencia tiene el siguiente aspecto: { "columns": [ {"name":"id","type":"varchar","index":1}, Consola Web SOFIA2 Página 114/221

115 } {"name":"timestamp_","type":"integer","index":2}, {"name":"mensajealarma","type":"varchar","index":3}, {"name":"mensajeexcepcion","type":"varchar","index":5}, {"name":"causa","type":"varchar","index":6}, {"name":"contextdata session_key","type":"varchar","index":7}, {"name":"contextdata user_id","type":"varchar","index":8}, {"name":"contextdata kp_id","type":"varchar","index":9}, {"name":"contextdata kp_identificador","type":"varchar","index":10}, {"name":"contextdata timestamp_","type":"varchar","index":11} ], "values": [ ["ObjectID(52fa4787fee7acf12f75a893)",null,"","3.0","69.0","\"KPproductor HT01\""," "], ["ObjectID(52fa e9d0a8d4a66)",null,"","","",""," ","3.0","69.0","\"KPproductorHT01\""," "], ["ObjectID(52fa53e475926e9d0a8d4a67)",null,"","","",""," ","3.0","69.0","\"KPproductorHT01\""," "], ] Consola Web SOFIA2 Página 115/221

116 11.2. Gestión Consultas Predefinidas Permite realizar consultas predefinidas sobre ontologías almacenadas en la plataforma para recuperar las instancias de tales ontologías enviadas por los KPs. Se pueden hacer consultas en dos tipos de lenguajes: o SQL-Like: Si se utiliza el lenguaje tipo SQL. o Nativo: Si se utiliza el lenguaje nativo de la BDTR (MongoDB). Consola Web SOFIA2 Página 116/221

117 La herramienta presenta un listado de Consultas predefinidas con las opciones de Ver, Editar, Lanzar o Borrar. Al seleccionar Lanzar, se muestra un formulario con los datos de la consulta realizada y el resultado de la misma. Consola Web SOFIA2 Página 117/221

118 Se puede seleccionar una consulta predefinida anteriormente o crear una consulta nueva de la siguiente manera. Consola Web SOFIA2 Página 118/221

119 o Identificación: Asignar un nombre a la consulta. o En el combo Tipo: El tipo de lenguaje utilizado en la sentencia: SQL-Like: Si se utiliza el lenguaje tipo SQL. Nativo: Si se utiliza el lenguaje nativo de la BDTR (MongoDB). o En el cuadro Ontologías disponibles: seleccionar una ontología sobre la que hacer la consulta, haciendo doble clic sobre ella. o En el cuadro Consulta: insertar la query que se quiere guardar KPs Activos Los usuarios logados en la Consola Web podrán consultar KPs a través de la opción de menú KPs Activos. Se consideran KPs activos para los que algunas de las instancias de KP han realizado un inicio de sesión satisfactorio que se mantiene vigente en el SIB. Al acceder a la funcionalidad se muestra el siguiente formulario de búsqueda: Consola Web SOFIA2 Página 119/221

120 Se permite realizar búsquedas por Usuario: Solo estará activo para Usuarios con rol Administrador. Ontología u ontologías de grupo relacionada con KPs activos. Nombre: Nombre o Identificador del KP. Se permitirá realizar búsquedas parciales, es decir, si se introduce un A y se pulsa el botón Buscar se listarán los KPs que empiecen por esa letra. Descripción del KP. Una vez cumplimentado el formulario de búsqueda para poder ver los resultados se debe pulsar el botón Buscar situado en la parte inferior derecha del formulario: Consola Web SOFIA2 Página 120/221

121 El listado incluye tres opciones, para ver las instancias activas del KP seleccionado, para realizar consultas en BDTR y para consultar los últimos valores insertados por el KP Busca y consulta de instancias de KPs Activos Desde el listado de KPs Activos, se puede acceder a las instancias activas para un KP. Se mostrarán las instancias de KPs para el KP seleccionado en el listado pulsando la opción : Consola Web SOFIA2 Página 121/221

122 Realizar consultas BDTR sobre el KP Activo Desde el listado de KPs Activos, podrán realizarse consultas a la BDTR pulsando sobre el botón situado en el listado a la derecha de cada KP Activo. Al pulsar el botón indicado se muestra la siguiente página: En la página indicada se muestra un boceto de query para orientar al usuario en la posible consulta BDTR a lanzar y las ontología con las que está relacionado el KP Activo. La consulta prepara la query con los atributos de las ontologías y localizaciones en donde se deben ubicar los valores para poder realizar dicha consulta: [VALUE], de esta forma se facilita la posibilidad de realizar una consulta sobre la BDTR. Se ha de sustituir [VALUE] por el valor deseado y eliminar los caracteres especiales [ ] Envío Mensajes SSAP Para poder probar el protocolo de mensajería estándar SSAP (Smart Space Access Protocol), se accede a esta opción de menú. Consola Web SOFIA2 Página 122/221

123 Tal y como se indica en la Guía SOFIA2-APIs SOFIA2 pueden enviarse mensajes SSAP al SIB y simular una comunicación entre KP y SIB desde esta opción de menú. Al acceder, se muestra la página con dos áreas de texto, la situada a la izquierda deberá contener el Mensaje SSAP que se pretende enviar al SIB y a la derecha el mensaje síncrono de respuesta del SIB: Una vez que introducido el mensaje SSAP, se pulsará sobre el botón Enviar Petición situado abajo a la izquierda. En este caso se ha enviado un mensaje JOIN al SIB, con lo que la respuesta en caso de realizar el inicio de sesión correctamente es el mensaje de respuesta con el id de sesión: La respuesta del SIB es un JSON sin formato, por lo que para formatearlo se pulsará sobre el botón Formatear mensaje situado abajo a la derecha. Una vez pulsado dicho botón, aparecerá el mensaje de respuesta del SIB formateado en un cuadro de texto en la parte inferior de la página. Consola Web SOFIA2 Página 123/221

124 Se validará por parte del SIB que los mensajes SSAP que se envían no violan los permisos establecidos. Para más información acerca de los mensajes SSAP se puede revisar la Guía SOFIA2-Conceptos SOFIA Validar Mensaje JSON Para poder comprobar si una instancia definida sobre una Ontología es correcta, se accede a esta opción de menú. Al acceder, se muestra la página con tres partes diferenciadas: - La primera, un selector en el cuál podremos elegir la Ontología sobre la que queremos definir nuestra instancia. Una vez seleccionada, se nos mostrará su esquema JSON. - La segunda, un editor JSON en el que se mostrará el esquema de la ontología. Podremos cambiar el modo de vista del esquema. - La tercera, un cuadro de texto en el que introducir nuestra instancia en formato JSON. Consola Web SOFIA2 Página 124/221

125 Una vez que introducida la instancia, se pulsará sobre el botón Validar situado abajo a la derecha. En este caso se ha enviado una instancia perteneciente a la Ontología SensorHumedad. La consola nos informará de la validez de la Instancia que hemos introducido. En este caso: Consola Web SOFIA2 Página 125/221

126 Consola Web SOFIA2 Página 126/221

127 En caso de que la instancia tuviera algún error: En este caso nos avisa de que la instancia no es válida para la Ontología SensorHumedad, el esquema de la instancia no es correcto Visualización Estado Procesos Esta herramienta nos permite visualizar el estado de un proceso como Scripts o Reglas CEP. Consola Web SOFIA2 Página 127/221

128 Se mostrarán los Procesos llevados a cabo por la plataforma. Pulsando en el listado la opción aparecera una pantalla como la siguiente, con los datos del proceso y los tiempos de ejecución. Consola Web SOFIA2 Página 128/221

129 12. GESTIÓN SW Desde esta sección podremos definir versiones de software y configuraciones de las aplicaciones desplegadas en un Gateway, así como podremos listar las configuraciones asignadas y creadas. Sólo los usuarios con rol de Administrador y Colaborador tendrán acceso a este menú. Se deben tener en cuenta las siguientes consideraciones: Un KP podrá tener varias aplicaciones de software y cada aplicación podrá tener varias configuraciones de software. Sólo una configuración de software podrá estar activa a la vez. Una vez activada una configuración y asignada a un KP e Instancia no podrá ser modificada. Cuando se modifica una aplicación o configuracion de sotware, se incrementará la versión en uno y por defecto se guardará como desactivada. o Por defecto, cuando se modifica o se clona una configuración o aplicación de software se guardarán como desactivadas. Se podrán clonar tanto configuraciones de software como aplicaciones de software con sus asignaciones, por defecto al clonar se guardará como desactivada. Las aplicaciones de software podrán desactivarse pero no podrán eliminarse del Sistema. Y sólo se podrán modificar si no han sido asignadas a ningún KP o Instancia de KP. Con esta gestión se pueden realizar actualizaciones masivas que afecten a un gran número de KPs y/o instancias de KPs Gestión de Configuración de Software Accediendo a la opción del menú Mis configuraciones SW se mostrará un listado con las aplicaciones y configuraciones de software que haya creado el usuario logado en la Plataforma. Un administrador podrá ver todas las aplicaciones y configuraciones de software creadas en el Sistema. Consola Web SOFIA2 Página 129/221

130 En la parte de arriba de la pantalla se incluye un campo que permite filtrar por el nombre de la aplicación de software. Se incluye un filtro por usuario sólo disponible para usuarios con rol de Administrador. En el listado se muestra el nombre de la aplicación, versión, propietario, descripción y si está o no activa. El listado incluye también la opción para consultar el detalle de la configuración de software o para modificar en el caso de que no haya sido asignada la aplicación de software. En la primera parte de la pantalla hay un botón Crear Configuración que nos redireccionar a otra pantalla para dar de alta una nueva aplicación de software y su configuración. La UI Crear Configuración se compone de dos partes principales, Datos Gestión de SW y Datos de la Configuración En la primera parte indicaremos los datos de gestión de software como: Nombre de la aplicación: El sistema nos avisará si intentamos crear una aplicación de sofware con un nombre que ya existe. Activa: Nos indica si se desea activar la aplicación de software o no. Aplicación: Permite seleccionar el war con el software a utilizar por los clientes. Descripción: Descripción a incluir sobre la aplicación de software. Consola Web SOFIA2 Página 130/221

131 En la parte de datos de configuración, indicaremos las propiedades de configuración de software ( por ejemplo: kp, instancia de kp, token de conexión, ip, puerto, etc.) Una vez creada la aplicación de software, nos mostrará el detalle con todos los datos. Desde la pantalla del detalle, podremos clonar (, ) tanto las configuraciones de la aplicación, como la aplicación de sofware, por defecto al clonar se guarda con los datos desactivados. Consola Web SOFIA2 Página 131/221

132 12.2. Asignación de Configuración Software en KPs A través de esta opción podremos listar las asignaciones de aplicaciones y configuración de software para KPs e Instancias de Kps. Desde esta funcionalidad será posible establecer asignaciones concretas a un KP e Instancia de KP, así como realizar asignaciones masiva como, asignar la misma configuración de software a todas las instancias de un KP, seleccionando *. O establecer una configuración de software para todos los KPs e Instancias de KP a través de *. Consola Web SOFIA2 Página 132/221

133 Una asignación podrá eliminarse pulsadon sobre el icono de la asignación a eliminar. Consola Web SOFIA2 Página 133/221

134 13. ADMINISTRACIÓN Permite: Buscar Usuarios Crear,modificar y eliminar usuarios Gestión de Usuarios Alta de usuarios Únicamente los usuarios registrados en la plataforma con rol Administrador podrán acceder a esta funcionalidad. Para dar de alta a nuevos usuarios, basta con hacer clic sobre el menú en la opción de Gestión de Usuarios, Crear Usuario y completar el formulario. Habrá que indicar: Alias y password para acceder al sistema: Estos campos deberán venir informados. Nombre completo del usuario: Campo Opcional. Campo obligatorio. Rol que tendrá el usuario: Lo roles que se le pueden asociar al usuario serán los siguientes: o Rol Administrador o Rol Colaborador o Rol Usuario Si el usuario está activo Fecha de alta y de baja del usuario en la Plataforma: La fecha de Alta es obligatoria, la fecha de baja es opcional. Consola Web SOFIA2 Página 134/221

135 Una vez que cumplimentado el formulario con los campos necesarios para dar de alta un usuario se pulsará sobre el botón Crear situado en la parte inferior derecha del formulario: Al darse de alta el usuario en la plataforma se muestra la pantalla de detalle del usuario: Consola Web SOFIA2 Página 135/221

136 Desde los datos del usuario se dará la posibilidad de Cancelar, Crear un nuevo Usuario, Modificar el usuario o Dar de baja el usuario creado, a través de los diferentes botones Listar usuarios Únicamente los usuarios registrados en la plataforma con rol Administrador podrán acceder a esta funcionalidad. Es posible consultar en todo momento los usuarios de la Plataforma, a través de la opción de menú Gestión de Usuarios: Se permitirá filtrar la información que se muestra en el listado: Usuario: Se permitirá realizar búsquedas parciales, es decir, si se introduce un A y se pulsa el botón Buscar se listarán los usuarios que empiecen por esa letra. Consola Web SOFIA2 Página 136/221

137 . Una vez introducidos los valores por los que se desea filtrar se deberá pulsar sobre el botón Buscar situado en la parte inferior derecha del formulario. Adicionalmente puede crearse un nuevo usuario mediante el botón Crear Usuario situado a la derecha del botón Buscar. Las opciones que se pueden realizar sobre cada uno de los usuarios mostrados en el listado son las siguientes: Detalle del usuario Edición de Usuarios Eliminar Usuario : Al pulsar el botón de eliminación se mostrará un mensaje de confirmación. Una vez aceptado se eliminará el usuario Modificación de usuarios Únicamente los usuarios registrados en la plataforma con rol Administrador podrán acceder a esta funcionalidad. Seleccionando la opción del menú Gestión de Usuarios y en el lista de usuarios la opción Editar se podrá modificar toda la información de un usuario de la Plataforma que haya sido dado de Alta: Consola Web SOFIA2 Página 137/221

138 Las validaciones que se realizarán serán las mismas que cuando se da de alta a un usuario Baja de usuarios Los usuarios registrados en la plataforma con cualquier rol eliminar o cancelar su cuenta de usuario. Esto es posible con el Rol Administrador a través del Listado de Usuario pulsando sobre el icono Eliminar Usuario de la columna Opciones. Para el resto de Roles es posible siempre y cuando el usuario esté logeado en la Consola de Administración. Para ello deberá pulsar el link que hay en la cabecera de la página donde se indica el usuario logado en la plataforma: Usuario: xxxx [ROL_XXXX], como se muestra en la siguiente imagen: En la ficha de Usuario que aparece se deberá pulsar sobre el botón Dar de Baja como se observa a continuación: Para finalizar se pedirá confirmación de la acción: Consola Web SOFIA2 Página 138/221

139 Pulsando sobre el botón Eliminar se producirá la cancelación de la cuenta o la baja automática del usuario Gestión Plantillas Ontologías Permite Gestionar las Plantillas que sirven de base a las Ontologías Crear nueva Plantilla Únicamente los usuarios logados en la Consola Web con rol Administrador podrán gestionar las plantillas dadas de alta. Mediante esta funcionalidad se permite dar de alta las plantillas que ayudarán en la creación de nuevas ontologías, facilitando su definición. Al acceder mediante la opción de menú Gestión Plantillas Ontologías, el botón crear Plantilla y se mostrará el siguiente formulario de creación de plantillas: Consola Web SOFIA2 Página 139/221

140 Para poder dar de alta una nueva plantilla se deberá cumplimentar el formulario con los campos obligatorios: Nombre: Nombre identificativo de la plantilla. Siempre deberá venir informado. Versión: Campo informativo de la versión inicial de la plantilla (no modificable). Editor de la plantilla: Área de edición de la plantilla. Siempre deberá ir informado y será validado como esquema JSON al dar de alta en la plataforma. Descripción: Opcionalmente se podrá incluir un texto descriptivo de la plantilla. Una vez informados los campos obligatorios para dar de alta la plantilla se deberá pulsar sobre el botón Crear situado en la parte inferior derecha del formulario de búsqueda. Una vez dada de alta la plantilla en la plataforma se mostrará el detalle de la misma: Consola Web SOFIA2 Página 140/221

141 Desde el detalle de la plantilla adicionalmente se dará la posibilidad de Crear una nueva plantilla, Modificar la plantilla, Eliminar la plantilla o Cancelar la acción: En el caso de que la plantilla no pase la validación de esquema JSON se mostrará el siguiente mensaje de error: En la creación de plantillas, se deben tener en cuenta los atributos reservados para la definición de Schemas JSON. Los atributos más habituales son los siguientes: required: Éste atributo del schema indica que la instancia de ontología deberá tener un valor. Consola Web SOFIA2 Página 141/221

142 properties: Este atributo define un objeto que contendrá definiciones de propiedad que concretará valores que deberán tener las instancias de ontología. Ítems: Este atributo define los valores permitidos para una instancia de array. default: Este atributo define un valor por defecto para la propiedad a la que hace referencia. title: atributo que debe contener el título del elemento al que hace referencia. type: indica la tipología de la propiedad a la que hace referencia en el JSON. Para más información acerca de los atributos de definición de schemas JSON se puede consultar en la dirección: Actualmente SOFIA2 esta testado según el draft-04 de JSON Listar Plantilla Podrán acceder únicamente los usuarios registrados con rol Administrador. Al acceder a la funcionalidad se mostrará el siguiente listado: Se permitirá filtrar la información que se muestra en el listado: Consola Web SOFIA2 Página 142/221

143 Nombre: Nombre o Identificador de Plantilla. Se permitirá realizar búsquedas parciales, es decir, si se introduce un A y se pulsa el botón Buscar se listarán las Plantillas que empiecen por esa letra. Descripción: Es posible buscar por texto que pueda estar en la descripción de la plantilla Una vez introducidos los valores por los que se desea filtrar se pulsará sobre el botón Buscar situado en la parte inferior derecha del formulario. Adicionalmente se puede crear una plantilla mediante el botón Crear situado a la derecha del botón Buscar. Las opciones que se pueden realizar sobre cada uno de las plantillas mostradas en el listado es el siguiente: Detalle de la plantilla Edición de la plantilla Eliminar plantilla : Al pulsar el botón de eliminación se mostrará un mensaje de confirmación, una vez aceptado se eliminará la plantilla Edición de plantillas Se podrá acceder a la edición de una plantilla desde el listado o tras la creación de una plantilla. Al acceder a la página se mostrará un formulario como el de creación de plantillas, donde se realizan las mismas validaciones. La versión de plantilla se habrá incrementado en una unidad: Consola Web SOFIA2 Página 143/221

144 Para aplicar los cambios sobre la plantilla modificada se deberá pulsar sobre el botón Guardar situado en la parte inferior derecha del formulario Gestión de Peticiones Sólo para usuarios con rol Administrador se puede gestionar las peticiones de los usuarios para pasar de rol Usuario a rol Colaborador. Accediendo a la opción del menú Administración y Gestión peticiones aparece la siguiente pantalla: Consola Web SOFIA2 Página 144/221

145 Desde esta consola se puede aceptar o rechazar las peticiones de los usuarios. Si se pulsa Aceptar, el usuario en cuestión pasa a tener automáticamente el rol Colaborador Gestión Operaciones Seleccionando la opción de menú Gestión Operaciones se accede a la siguiente pantalla: Desde el listado de operaciones se puede ver, editar y eliminar las operaciones. Se puede crear una nueva operación pulsando sobre el botón Crear Operación. Consola Web SOFIA2 Página 145/221

146 Se deben completar los campos Identificación, Descripción e insertar la Operación en groovy. Para finalizar pulsar el botón Crear Opciones de Administración Recientemente se ha incluido la opción de Vaciar Caché de la Consola Web de Sofia2. Mediante el borrado de caché se eliminan datos innecesarios agilizando los procesos de la web. Para ello debemos acceder a la opción de menú Administración, Opciones de Administración y aparece la siguiente pantalla con el botón Vaciar Caché: Consola Web SOFIA2 Página 146/221

147 14. API MANAGER Esta sección se utilizará para permitir disponibilizar Ontologías como APIs así como para registrar APIs externas en el sistema. Existirá también un mecanismo para permitir el acceso a las APIs por medio de autorizaciones a usuarios concretos. Se realizará la suscripción a APIs publicadas y se podrá consultar el API Key generado para la invocación a las mismas. Este módulo permite que los usuarios de la Plataforma puedan interactuar con SOFIA2 a través de recursos REST sin la necesidad de manejar los conceptos avanzados de SOFIA2 (ontologías, KPs, ), permitiendo además que SOFIA2 disponga de un catálogo de APIs REST que permitirá al usuario acceder a la información almacenada para desarrollar sus propias aplicaciones o extender las propias de forma simple. Además mediante la inclusión y registro de APIs externas se proporciona un repositorio integrado de APIs. Sólo los usuarios con rol Administrador y Colaborador tendrán acceso a las opciones Mis APIs y Autorizaciones APIs. El resto de opciones están disponibles para todos los usuarios excepto Suscripción a APIs que está disponible para usuarios con rol Colaborador y Usuario. Consola Web SOFIA2 Página 147/221

148 Flujo de Trabajo: Durante la creación de los usuarios, se generará un token de usuario que se utilizará para la invocación a las APIs. Consola Web SOFIA2 Página 148/221

149 14.1. Mi API Key En la pantalla Mi API Key se podrá consultar el Token y regenerarlo para obtener otro nuevo. Si el usuario Administrador consulta los datos de un usuario, se mostrará su API KEY en el caso de que haya sido generado. Consola Web SOFIA2 Página 149/221

150 14.2. Mis APIs Esta opción permitirá gestionar las APIs disponibilizadas o registradas por los usuarios. A esta opción sólo tendrán acceso los usuarios con roles COLABORADOR o ADMINISTRADOR. El listado mostrará todas las APIs que se encuentran registradas en el sistema: La primera parte de la pantalla mostrará una serie de filtros. Para usuarios con rol COLABORADOR, se incluirán los filtros Buscar y Estado. Para usuarios con rol ADMINISTRADOR se incluye un campo adicional de búsqueda Usuario, que permitirá discriminar entre los usuarios que disponibilizaron la API. A continuación se muestran los controles que se utilizarán para realizar la búsqueda o bien para Crear una nueva API (redirigirá a la pantalla de creación de APIs). Consola Web SOFIA2 Página 150/221

151 En el listado, se mostrará un registro por cada API. En cada registro se incluye: Imagen que representa a la API (en caso de no tener se muestra una imagen por defecto). Nombre de la API y su número de versión (precedida por V ). Usuario propietario de la API. Estado de la API. Descripción de la API. Control que permite cambiar de estado a la API de forma directa. Si se pulsa sobre el control para cambio de estado (Publicar, Deprecar o Eliminar dependiendo del caso), se realizará la modificación y se volverá a mostrar la pantalla. Si se pulsa sobre el Nombre Versión de la API o sobre la imagen de la API, se navegará a la pantalla de consulta de datos de la API. Consola Web SOFIA2 Página 151/221

152 Pantalla de Creación de API Permitirá incorporar una API al catálogo de APIs disponibles. Bien registrando una API Externa en el sistema o bien disponibilizando una Ontología como API. Para ello, se deberán introducir los siguientes campos: Nombre: Identificador único de la API. Publica: Definirá si la API es accesible por todos los usuarios o si es necesario autorizarles para que puedan suscribirse a la misma. Versión: Versión de la API. Se recalcula automáticamente a partir del nombre de la misma. Categoría: Categoria genérica a la que pertenecerá el API y que facilitará su localización. API Externa: Se seleccionará si se desea registrar un API en el sistema. Si se marca esta opción, se deshabilitará el campo Ontología se mostrará el campo EndPoint base Externo y se mostrará la sección de Autorización y Operaciones correspondiente al registro de una API Externa. Ontología: Si no se selecciona el check anterior, es decir, estamos en el caso de una API disponibilizada a partir de una Ontología, este control se activará y será mediante este control con el que se seleccionará dicha Ontología. Para los usuarios con rol Colaborador, sólo se mostrarán las ontologías de las que sean propietarios, mientras que para los usuarios con rol Adminsitrador se mostrarán todas las ontologías públicas y activas. Si se selecciona una Ontología, se generarán automáticamente tanto el nombre (y el cálculo de la versión correspondiente), como el Path de cada una de las operaciónes (a partir del nombre de la API y su versión). Imagen: Representará a la API en el sistema. Si no se introduce ninguna, se mostrará una imagen por defecto. EndPoint: Dirección EndPoint del servicio que se generará automáticamente a partir del identificador y la versión de la API. Enpoint base externo: Dirección EndPoint del servicio final que se va a registrar en el sistema. Se mostrará si se está registrando una API externa en el sistema. Descripción: Descripción general de la API. Consola Web SOFIA2 Página 152/221

153 Meta-Inf: Metainformación util para ubicar la API. Autenticación: En caso de tratarse de una API Externa, se mostrará una sección que permitirá introducir atributos de autenticación. Operaciones. Toda la información asociada a cada una de las operaciones disponibles en la API. Dependiendo de si se trata de dar de alta una API externa o de si se está disponibilizando una Ontología, mostrará un interfaz u otro. Tanto Nombre, Versión, EndPoint, EndPointExterno Descripción como Meta-Inf son campos obligatorios, no permitiendo el sistema realizar el alta si alguno de ellos se encuentra vacio. A continuación examinaremos la pantalla correspondiente a la disponibilización de una Ontología como API. La primera parte de la pantalla tiene el aspecto siguiente: Consola Web SOFIA2 Página 153/221

154 La parte correspondiente a las operaciones: Mediante cada uno de los botones que representan a cada Operación, puede seleccionarse qué operaciones estarán disponibles en la API. Tras pulsar sobre los controles deseados, habrá que introducir la información necesaria. En este caso la información que describa cada una de las operaciones seleccionadas. La parte de la pantalla tras este paso quedaría: Consola Web SOFIA2 Página 154/221

155 Tras introducir la información necesaria y pulsar el botón Crear, se realizará el Alta del nuevo registro y se navegará a la pantalla de Consulta de Datos de la API, Consola Web SOFIA2 Página 155/221

156 Para un API Externa, la primera parte de la pantalla sería como sigue: Consola Web SOFIA2 Página 156/221

157 Se deberá introducir la URL del EndPoint base externo para la invocación de la API Externa. Este tipo de APIs podrán tener una autenticación asociada (para la invocación del servicio subyacente) que puede configurarse mediante la sección Autenticación: Se añadirá un tipo y una descripción. Si se selecciona el tipo Básico, se añadirá una entrada en la sección de Autenticación: Consola Web SOFIA2 Página 157/221

158 Se podrá editar y eliminar dicha autenticación, así como asignarle un valor al atributo Authorization Este valor tendrá que informarse en uno de los atributos de la petición para servir como valor de autenticación. En caso de introducir un valor por defecto, será el utilizado para la invocación al API Externa, sin que sea necesario informarlo por parte del usuario que la invoca. En caso de que la autenticación sea de por Headers, al seleccionarlo el interfaz mostrará: Al pulsar sobre Añadir Header, se añadiran los distintos Headers que serán necesario introducir en la petición al API. De la misma forma que en la anterior se le pueden dar valores por defeto para que no sea necesario que los introdizca el usuario en la invocación. Consola Web SOFIA2 Página 158/221

159 Tras introducir los datos y guardar, se mostrará en el interfaz. Una vez dad de alta la Autenticación, habría que definir al menos una operación. Para ello, se utilizaría la sección Operaciones: Se pulsa sobre el botón Añadir Operación y se muestra el siguiente interfaz: Consola Web SOFIA2 Página 159/221

160 Se deben introducir los campos correspondientes: - Método de la operación HTTP (GET, POST, PUT o DELETE). - Nombre de la operación (identificador). - EndPoint Base Operación:Si se introduce, para la operación en cuestión sustituirá el EndPoint del API. - Ruta relativa: se construye para completar la ruta del EndPoint general. - Descripción : Información que describe a la operación. Tras pulsar sobre guardar, se mostrará la operación creada en la lista: Se podrán editar sus datos generales o bien eliminar la operación. Si se pulsa sobre el nombre de la operación se desplegará sus opciones: Consola Web SOFIA2 Página 160/221

161 Se podrá añadir el resto de parámetros asociados a la Operación, tanto heders como queryparams. Tras pulsar sobre el botón correspondiente, se mostrará el interfaz de alta: Se deberán introducir una serie de datos: - Nombre: Identificación del Parametro - Condición: Si es requerido (el parámetro es obligatorio), si es opcional (no es necesario que se informe pero se tendrá en cuenta) o constante (el parámetro se introducirá en la invocación independientemente de si el usuario lo informe o no). - Tipo: Tipo de datos del atributo, en principio string, boolean o number. - Valor: Valor del atributo, si quiere informarse. En el caso de que la Condición sea constante, será obligatorio. - Descripción: Información sobre el parámetro introducido. Tras pulsar sobre guardar, se mostrarán los datos por pantalla: Consola Web SOFIA2 Página 161/221

162 Se podrá modificar y eliminar todos los parámetros introducidos anteriormente. Para el caso de los Headers el comportamiento sería similar. Una vez introducidos todos los datos necesarios, si se pulsa sobre crear, se finalizará el registro de la API Externa. Consola Web SOFIA2 Página 162/221

163 Consola Web SOFIA2 Página 163/221

164 Pantalla de Consulta de API La pantalla muestra la información introducida en la pantalla de Creación, si bien se muestra la imagen introducida, así como el estado del API (Creada). Como controles se incluyen Cancelar, que volverá a la pantalla Mis APIs, Crear, que redirigirá a la pantalla de Creación de APIs y Modificar, que cargará la pantalla de modificación de la API mostrada por pantalla. En el caso de tratarse de API Externa registrada en el sistema, se podrá acceder a los valores de todos los atributos de autenticación así como a los de cada Operación definida Pantalla de Modificación de API La primera parte de la pantalla, para una API generada como disponibilización de una Ontología, presenta el siguiente aspecto: Consola Web SOFIA2 Página 164/221

165 Y la parte de las operaciones: Mostrará la información relativa a la API, permitiendo la modificación de la misma. Como campos editables se incluyen: Categoría, Imagen, EndPoint, Descripción, Meta-inf y todos aquellos asociados a las Operaciones. Se podrá modificar o eliminar cualquiera de las operaciones existentes así como añadir operaciones nuevas (de la misma forma que se permitía en la pantalla de creación). Tras introducir los cambios, si se pulsa sobre guardar, se aplicarán los cambios y se volverá a mostrar la pantalla de consulta de la API. Consola Web SOFIA2 Página 165/221

166 Si se pulsa sobre cancelar, se cancelarán los cambios introducidos y se volverá a la pantalla de consulta de datos de la API. Para una API Externa registrada en Sofia2, la pantalla sería similar a: Y posteriormente la Autenticación y Operaciones: Consola Web SOFIA2 Página 166/221

167 Como campos editables se incluyen: Categoría, Imagen, EndPoint base Externo, Descripción, Meta-inf y todos aquellos asociados a las Operaciones. En la sección de Autenticación y Operaciones, todos los campos y atributos son editables. Se incluye para ambos casos (Externos y disponibilizados) además un control para cambiar el estado de la API, mediante el que se realiza directamente el cambio de estado de la API (no almacena el resto de cambios realizados). Consola Web SOFIA2 Página 167/221

168 El ciclo de vida de las APIS será el siguente: Tras el proceso de Creación de API, pasará a estado Creada. Es el estado inicial de todas las APIs. Si se desea que la API esté disponible para el resto de usuarios, se deberá publicar (estado Publicado). En ese momento, el resto de usuarios podrán suscribirse sobre la API para poder utilizarla. En algún momento determinado, por la aparición de una nueva versión de la API, puede que se desee retirar las versiones anteriores. En ese caso, dichas versiones pasarán a estado Deprecado. Seguirán estando desplegadas, pero ya no serán visibles ni invocables por los usuarios. Finalmente, podrá eliminarse cualquier API que estuviera deprecada. Consola Web SOFIA2 Página 168/221

169 14.3. Autorizaciones APIs Cuando se crea una API, bien disponibilizando una Ontología, bien registrando una API Externa existente en el sistema, se ofrece la opción de que sea pública. Si se selecciona esa opción, todos los usuarios podrán suscribirse a la API, pudiendo utilizarla desde ese momento. En caso de que la API se defina como no pública, se deberá proporcionar un sistema de permisos a los usuarios. Para implementar esta funcionalidad, se utiliza la pantalla de autorizaciones. Sólo tendrán acceso a esta pantalla los usuarios con perfiles Administrador y Colaborador. La pantalla tendría un un aspecto similar al siguiente: En la primera parte se muestran todos los usuarios del sistema con roles Usuario y Colaborador (exceptuando al propio usuario logado) junto con todas las APIs de las que es propietario el usuario (en caso de usuarios Administradores se mostrarán todas las APIs). En la parte inferior de la pantalla se mostrarán los permisos existentes en el sistema de los usuarios sobre las APIs. Es decir qué usuarios pueden acceder a qué APIS. Este mismo interfaz sirve para asignar permisos a los usuarios. Tras seleccionar un usuario en la primera combo y una API en la segunda, si se pulsa sobre el botón Guardar, se almacenará el permiso en el sistema, pudiendo acceder el usuario a la API (u pudiendo suscribirla). De la misma forma, en esta misma pantalla se permite eliminar los permisos dados de alta, pulsando sobre el botón eliminar que se encuentra en cada uno de los registros de la tabla. Consola Web SOFIA2 Página 169/221

170 14.4. Suscripción a APIs Mediante esta opción un usuario podrá registrarse para poder usar las APIs registradas. Para los usuarios con rol ADMINISTRADOR, esta pantalla no mostrará ninguna API, ya que podrán invocar a todas. Para los usuarios con rol COLABORADOR aparecerán las APIs disponibles de las que no sean propietarios, ya que las propias serán invocables. Para el resto de usuarios, aparecerán todas las APIs registradas. En la primera parte de la pantalla se incluyen unos filtros. Como primer control, se observan las distintas categorías disponibles. Pulsando sobre dichas categorías, se realizará el filtrado de las Apis por las mismas (la opción Todas no filtra por ninguna, muestra todas las APIs disponibles). El siguiente filtro realiza una búsqueda sobre los campos Identificación, descripción y meta-inf de la API. Tras pulsar sobre buscar, se mostrarán los resultados de la búsqueda. Los registros de la tabla mostrarán los mismos campos que en la gestión de APIs, si bien los registros no son accesibles para consultar. Consola Web SOFIA2 Página 170/221

171 Junto a cada registro se incluye un control que permite realizar la suscripción a dicha API. Tras pulsar sobre el control Suscribir, se recargará la página, desapareciendo el registro de la lista (al estar ya suscrito al mismo). Consola Web SOFIA2 Página 171/221

172 14.5. Mis Suscripciones En esta pantalla se mostrarán las suscripciones activas de cada usuario. Para usuarios con rol ADMINISTRADOR, aparecerán todas las APIS, ya que tienen acceso a todas. Para los usuarios con rol COLABORADOR se mostrarán todas las APIs de las que son propietarios, así como todas aquellas a las que se hayan suscrito. Para el resto de usuarios, aparecerán las APIs a las que se encuentren suscritos. La pantalla será similar a la siguiente: En cada registro se incluyen los datos asociados a cada API. Se podrá navegar al detalle de las APIs pulsando sobre el link con el nombre del API y se mostrará una pantalla como la siguiente: Consola Web SOFIA2 Página 172/221

173 Además desde Mis Suscripciones para cada API sobre la que estamos suscritos, se incluyen dos controles: Desuscribir: Permitire desuscribir al usuario de la API seleccionada. Test: Mediante este control se abre una pantalla que permite invocar a la API registrada. Consola Web SOFIA2 Página 173/221

174 Desde este interfaz se podrá invocar a las distintas operaciones de la API. Se seleccionará la operación correspondiente, se introducirá el token de usuario en el campo (X-SOFIA2-APIKey) y los parámetros necesarios para invocar a la operación. Se incluyen las siguientes operaciones: En todas ellas se deberá introducir el token de usuario en el campo X-SOFIA2-APIKey. INSERT: Operación con método HTTP POST sobre /sofia2.com/sib-api/api/{version}/{api]/ enviando en el body de la petición una instancia de la ontología disponibilizada. "Feed": { "assetid": "1", "assettype": "CuadroElectrico", "assetsource": "CuadroEntrada", "type": "VIRTUAL", "timestamp": {"$date": " T13:57:39.342Z"}} UPDATE: Operación con método HTTP PUT sobre /sofia2.com/sib-api/api/{version}/{api]/ enviando en el body de la petición un objeto con: - ObjectId de la instancia a actualizar de la BTDR Consola Web SOFIA2 Página 174/221

175 - Nuevos datos de la instancia en el mismo formato descrito en el esquema de su ontología. {"_id" : {"$oid" : " fdef e05d"}, "Feed": {"assetid" : "2", "assettype" : "CuadroElectrico", "assetsource" : "CuadroEntrada", "type" : "VIRTUAL", "timestamp" : { "$date" : " T13:57:39.342Z"}}} DELETE: Operación con método HTTP DELETE sobre /sofia2.com/sib-api/api/{version}/{api]/ enviando en el body de la petición un objeto con: - ObjectId de la instancia a eliminar de la BTDR. {"_id" :{ "$oid" : " fdef e05d"}} QUERY: Se implementan dos métodos: - Operación con método HTTP GET sobre /sofia2.com/sib-api/api/{version}/{api]/ enviando en el body de la petición un objeto con: o Id de la instancia a actualizar de la BTDR - Operación con método HTTP GET sobre /sofia2.com/sib-api/api/{version}/{api]/ enviando en el body de la petición un objeto con: o $targetdb: Base de datos sobre la que se realizará la consulta: BDTR BDH o o $filter: Consulta a realizar sobre la BBDD. $querytype: Tipo de consulta realizada: SQL-LIKE Native o $formatresult: Permite configurar el formato en el que se va a mostrar la información resultante a la petición enviada. En caso de que este campo no se rellene, la información se mostrará en formato JSON. Los formatos disponibles son: CSV JSON Consola Web SOFIA2 Página 175/221

176 XML QUERY OPS: Operación con método HTTP GET sobre /sofia2.com/sib-api/api/{version}/{api]/ enviando en el body de la petición un objeto con: o $querytype:tipo de consulta. SQLLIKE o $query: Consulta SQL a realizar sobre la BBDD. Se incluyen INSERT, UPDATE y DELETE. Para el caso de las APIs Externas se comportaría de forma similar, si bien el interfaz de invocación se construirá de forma dinámica en función de las operaciones y los atributos de la API. Consola Web SOFIA2 Página 176/221

177 15. SOCIAL MEDIA Usuarios Twitter Desde la Consola Web de Sofia2 se puede acceder a contenido de Social Media, en este caso a la red social Twitter. Desde la opción de Menú Social Media, Usuarios Twitter se pueden buscar usuarios de Twitter por su nombre_usuario. También debemos elegir la configuración de acceso con la que queremos acceder a la red social Búsqueda Desde la opción de Menú Social Media, Búsqueda se puede buscar twits introduciendo la palabra clave a buscar y seleccionando la configuración de acceso con la que queremos acceder a la red social Tendencias Desde la opción de Menú Social Media, Tendencias se puede buscar las últimas tendencias de Twitter seleccionando en los combos la zona geográfica de interés (Global, España, EEUU, Francia, Reino Unido, Italia, Portugal, Alemania o México) y la configuración de acceso con la que queremos acceder a la red social. Consola Web SOFIA2 Página 177/221

178 Al pulsar el botón Buscar aparece una pantalla con las últimas tendencias de la red social: Páginas Facebook Desde la opción de Menú Social Media, Páginas Facebook se puede buscar el nombre de la página facebook, pudiendo ofrecer múltiples resultados en un listado en el caso de que haya más de una página con ese nombre. Este listado resultante se puede guardar sobre una ontología, de manera que todos los datos se almacenan en la ontología destino que se elija. Adicionalmente, sobre cada resultado se podrá obtener el Timeline de la página en concreto y de nuevo se podrá guardar esta información sobre una ontología Tendencias Instagram Desde la opción de Menú Social Media, Tendencias Instagram se puede realizar una búsqueda de las últimas tendencias en Instagram. Consola Web SOFIA2 Página 178/221

179 15.6. Configuraciones de Acceso Accediendo a la opción de menú Social Media, Configuraciones de Acceso aparece la siguiente pantalla con el listado de configuraciones registradas: Se puede crear una configuración de acceso a la red social Twitter pulsando el botón Crear Configuraciones de Acceso. Los parámetros a introducir son: Identificación: nombre de la configuración a guardar. Usuario Sofia2: vendrá ya definido el usuario con el que se esté logado en la consola. Usuario Twitter: usuario de la cuenta de la red social Twitter con el que se quiere hacer las búsquedas de usuarios, tendencias, Credenciales de usuario: OAuthConsumerKey, OAuthConsumerSecret, OAuthAccessToken, OAuthAccessSecret. Consola Web SOFIA2 Página 179/221

180 16. SOFIA2 DATAFLOW Introducción Este módulo se utiliza para la ingesta, exportación de los datos. el análisis en tiempo real y el procesamiento y Desde esta sección del menú se podrán crear flujos de datos desde múltiples orígenes distintos, transformarlos e insertarlos de una manera distinta. En esta guía se explicará cómo crear este flujo de datos, así como un análisis de qué es posible hacer con estos y qué posibilidades ofrece. Accediendo a esta sección, se pueden ver las siguientes secciones: Consola Web SOFIA2 Página 180/221

181 Cada apartado se va a explicar posteriormente con detalle y se hará un ejemplo de uso de Stream y Job Contenedores En esta ventana se muestran todos los contenedores disponibles. Nos aparecerá una pantalla como la mostrada a continuación. Si se selecciona el Id del contenedor desplegado, se puede obtener información adicional, como el Host, la Ip, el puerto y el Pid. Junto al contenedor aparece información de los módulos desplegados en él (Streams y Jobs). En este caso, se tiene un módulo llamado pruebajob de tipo Job. En el caso en el que se disponga de más de un contenedor disponible y habilitado, esta ventana ofrece la posibilidad de cerrarlos hasta que sólo quede un contenedor habilitado, en cuyo caso no se permitirá borrar este último Streams Un Streams ofrece la posibilidad de definir la ingesta masiva de datos desde un origen (sources), un procesamiento de esta información (processor) y un destino de los datos (sink). Cada uno de estos módulos se explicarán detalladamente en esta sección, de manera que se pueda entender correctamente el flujo de datos que está teniendo lugar. Este procesamiento se lleva a cabo en el interior del contenedor, por lo que, como se ha dicho anteriormente, debe haber mínimo un contenedor desplegado para lograr que cada uno de estos módulos se pueden ejecutar correctamente. Consola Web SOFIA2 Página 181/221

182 Como ya se ha comentado, existen 3 secciones a definir en un Stream: source, processor y sink. No obstante, solo source y sink son obligatorias para la ejecución de un Stream. A continuación se van a explicar cada uno de los componentes distintos de cada sección, así como la configuración asociada Sources Fuente de los datos que se desea tratar. Por ello, es el primer módulo que se debe de poner en el esquema de creación File Description Provides the contents of a File as a byte array by default. Dir: The absolute path to the directory to monitor for files (String, default: /tmp/xd/input/<stream name>) fixeddelay: The fixed delay polling interval specified in seconds (int, default: 5) initialdelay: An initial delay when using a fixed delay trigger, expressed in TimeUnits (seconds by default) (int, default: 0) maxmessages: The maximum messages per poll; -1 for unlimited (long, default: -1) Parameters mode: Specifies how the file is being read. By default the content of a file is provided as byte array (FileReadingMode, default:contents, possible values: ref,lines,contents) pattern: A filter expression (Ant style) to accept only files that match the pattern (String, default: *) preventduplicates: Whether to prevent the same file from being processed twice (boolean, default: true) timeunit the time unit for the fixed and initial delays (String, default: SECONDS). withmarkers: If true emits start of file/end of file marker messages before/after the data. Only valid with FileReadingMode 'lines' (Boolean, no default) FTP Consola Web SOFIA2 Página 182/221

183 Description This source module supports transfer of files using the FTP protocol. Files are transferred from the remote directory to the local directory where the module is deployed. autocreatelocaldir: Local directory must be auto created if it does not exist (boolean, default: true) clientmode: Client mode to use : 2 for passive mode and 0 for active mode (int, default: 0) deleteremotefiles: Delete remote files after transfer (boolean, default: false) filenamepattern: Simple filename pattern to apply to the filter (String, default: *) fixeddelay: The rate at which to poll the remote directory (int, default: 1) host: The host name for the FTP server (String, default: localhost) initialdelay: An initial delay when using a fixed delay trigger, expressed in TimeUnits (seconds by default) (int, default: 0) Parameters localdir: Set the local directory the remote files are transferred to (String, default: /tmp/xd/ftp) maxmessages: The maximum messages per poll; -1 for unlimited (long, default: -1) mode: Specifies how the file is being read. By default the content of a file is provided as byte array (FileReadingMode, default:contents, possible values: ref,lines,contents) password: The password for the FTP connection (Password, no default) port: The port for the FTP server (int, default: 21) preservetimestamp: Whether to preserve the timestamp of files retrieved (boolean, default: true) remotedir: The remote directory to transfer the files from (String, default: /) remotefileseparator: File separator to use on the remote side (String, default: /) timeunit: The time unit for the fixed and initial delays (String, default: SECONDS). tmpfilesuffix: Extension to use when downloading files (String, default:.tmp) username: The username for the FTP connection (String, no default). Consola Web SOFIA2 Página 183/221

184 withmarkers: if true emits start of file/end of file marker messages before/after the data. Only valid with FileReadingMode 'lines' (Boolean, no default) HTTP Description Post some data to the http server on the default port of for (boolean, default: false) maxcontentlength: The maximum allowed content length (int, default: ) Parameters messageconverterclass: The name of a custom MessageConverter class, to convert HttpRequest to Message; must have a constructor with a 'MessageBuilderFactory' parameter (String, default:org.springframework. integration.x.http. NettyInboundMessageConverter) port: The port to listen to (int, default: 9000) sslpropertieslocation: Location (resource) of properties containing the location of the pkcs12 keystore and pass phrase (String, default:classpath:httpssl.properties) JDBC Description This source module supports the ability to ingest data directly from various databases. It does this by querying the database and sending the results as messages to the stream. abandonwhenpercentagefull: Connections that have timed out wont get closed and reported up unless the number of connections in use are above the percentage (int, default: 0) alternateusernameallowed: Uses an alternate user name if connection fails (boolean, default: false) Parameters connectionproperties: Connection properties that will be sent to our JDBC driver when establishing new connections (String, no default) driverclassname: The JDBC driver to use (String, no default) fairqueue: Set to true if you wish that calls to getconnection should be treated fairly in a true FIFO fashion (boolean, default: true) fixeddelay: How often to poll for new messages (s) (int, default: 5) Consola Web SOFIA2 Página 184/221

185 initsql: Custom query to be run when a connection is first created (String, no default) initialsize: Initial number of connections that are created when the pool is started (int, default: 0) jdbcinterceptors: Semicolon separated list of classnames extending org.apache.tomcat.jdbc.pool.jdbcinterceptor (String, no default) jmxenabled: Eegister the pool with JMX or not (boolean, default: true) logabandoned: Flag to log stack traces for application code which abandoned a Connection (boolean, default: false) maxactive: Maximum number of active connections that can be allocated from this pool at the same time (int, default: 100) maxage: Time in milliseconds to keep this connection (int, default: 0) maxidle: Maximum number of connections that should be kept in the pool at all times (int, default: 100) maxmessages: The maximum messages per poll; -1 for unlimited (long, default: 1) maxrowsperpoll: Max numbers of rows to process for each poll (int, default: 0) maxwait: Maximum number of milliseconds that the pool will wait for a connection (int, default: 30000) minevictableidletimemillis: Minimum amount of time an object may sit idle in the pool before it is eligible for eviction (int, default: 60000) minidle: Minimum number of established connections that should be kept in the pool at all times (int, default: 10) password: The JDBC password (Password, no default) JMS Description The "jms" source enables receiving messages from JMS. Acknowledge: The session acknowledge mode (String, default: auto) Parameters clientid: An identifier for the client, to be associated with a durable topic subscription (String, no default) destination: The destination name from which messages will be received (String, default: <stream name>) Consola Web SOFIA2 Página 185/221

186 durablesubscription: When true, indicates the subscription to a topic is durable (boolean, default: false) provider: The JMS provider (String, default: activemq) pubsub: When true, indicates that the destination is a topic (boolean, default: false) subscriptionname: A name that will be assigned to the topic subscription (String, no default) Kafka Description This source module ingests data from a single or comma separated list of Kafka topics. When using single topic configuration, one can also specify explicit partitions list and initial offset to fetch data from. Also note that for the stream with the given name or kafka source with the given groupid, the offsets for the configured topics aren t deleted when the stream is undeployed/destroyed. This allows the re-deployed stream read from where it left when it was undeployed/destroyed. autooffsetreset: Strategy to reset the offset when there is no initial offset in ZK or if an offset is out of range (AutoOffsetResetStrategy, default: smallest, possible values: smallest,largest) encoding: String encoder to translate bytes into string (String, default: UTF8) fetchmaxbytes: Max messages to attempt to fetch for each topic-partition in each fetch request (int, default: ) fetchmaxwait: Max wait time before answering the fetch request (int, default: 100) Parameters fetchminbytes: The minimum amount of data the server should return for a fetch request (int, default: 1) groupid: Kafka consumer configuration group id (String, default: <stream name>) initialoffsets: Comma separated list of <partition>@<offset> pairs indicating where the source should start consuming from (String, default: ``) kafkaoffsettopicbatchbytes: Maximum batched bytes for writes to offset topic, if Kafka offset strategy is chosen (int, default: 200) kafkaoffsettopicbatchtime: Maximum time for batching writes to offset topic, if Kafka offset strategy is chosen (int, default: 1000) kafkaoffsettopicmaxsize: Maximum size of reads from offset topic, if Kafka Consola Web SOFIA2 Página 186/221

187 offset strategy is chosen (int, default: ) kafkaoffsettopicname: Name of the offset topic, if Kafka offset strategy is chosen (String, default: <stream name>- ${xd.module.name}-offsets) kafkaoffsettopicrequiredacks: Required acks for writing to the Kafka offset topic, if Kafka offset strategy is chosen (int, default: 1) kafkaoffsettopicretentiontime: Retention time for dead records (tombstones), if Kafka offset strategy is chosen (int, default: 60000) kafkaoffsettopicsegmentsize: Segment size of the offset topic, if Kafka offset strategy is chosen (int, default: ) offsetstorage: Strategy for persisting offset values (OffsetStorageStrategy, default: kafka, possible values: inmemory,redis,kafka) offsetupdatecount: Frequency, in number of messages, with which offsets are persisted, per concurrent processor, mutually exclusive with the time-based offset update option (use 0 to disable either) (int, default: 0) offsetupdateshutdowntimeout: Timeout for ensuring that all offsets have been written, on shutdown (int, default: 2000) offsetupdatetimewindow: Frequency (in milliseconds) with which offsets are persisted mutually exclusive with the count-based offset update option (use 0 to disable either) (int, default: 10000) partitions: Comma separated list of partition IDs to listen on (String, default: ``) queuesize: The maximum number of messages held internally and waiting for processing, per concurrent handler. Value must be a power of 2 (int, default: 8192) socketbufferbytes: Socket receive buffer for network requests (int, default: ) sockettimeout: Sock timeout for network requests in milliseconds (int, default: 30000) streams: Number of streams in the topic (int, default: 1) topic: Single topic name (String, default: ``) topics: Comma separated kafka topic names (String, default: ``) zkconnect: Zookeeper connect string (String, default: localhost:2181) zkconnectiontimeout: The max time the client waits to connect to ZK in milliseconds (int, default: 6000) Consola Web SOFIA2 Página 187/221

188 zksessiontimeout: Zookeeper session timeout in milliseconds (int, default: 6000) zksynctime: How far a ZK follower can be behind a ZK leader in milliseconds (int, default: 2000) Mail Description Depending on the protocol used, in can work by polling or receive mails as they become available. charset: The charset used to transform the body of the incoming s to Strings (String, default: UTF-8) delete: Whether to delete the s once they ve been fetched (boolean, default: true) expression: A SpEL expression which filters which mail messages will be processed (non polling imap only) (String, default: true) fixeddelay: The polling interval used for looking up messages (s) (int, default: 60) folder: The folder to take s from (String, default: INBOX) host: The hostname of the mail server (String, default: localhost) Parameters markasread: Whether to mark s as read once they ve been fetched (boolean, default: false) maxmessages: The maximum messages per poll; -1 for unlimited (long, default: 1) password: The password to use to connect to the mail server (String, no default) port: The port of the mail server (int, default: 25) properties: Comma separated JavaMail property values (String, no default) propertiesfile: File to load the JavaMail properties (String, no default) protocol: The protocol to use to retrieve messages (MailProtocol, default: imap, possible values: imap,imaps,pop3,pop3s) usepolling: Whether to use polling or not (no polling works with imap(s) only) (boolean, default: false) username: The username to use to connect to the mail server (String, no default) Consola Web SOFIA2 Página 188/221

189 MongoDB Description Allows one to query a MongoDB collection and emit messages for each and every matching result. This source works by regularly polling MongoDB and emitting the result list, as independent objects. If split is set to false, the whole list is emitted as payload. authenticationdatabasename: The MongoDB authentication database used for connecting (String, default: ``) collectionname: The MongoDB collection to read from (String, default: <stream name>) databasename: The MongoDB database name (String, default: xd) fixeddelay: The time delay between polls for data, expressed in TimeUnits (seconds by default) (int, default:1000) host:the MongoDB host to connect to (String, default: localhost) Parameters initialdelay: An initial delay when using a fixed delay trigger, expressed in TimeUnits (seconds by default) (int, default: 0) maxmessages: The maximum messages per poll; -1 for unlimited (long, default: 1) password: The MongoDB password used for connecting (String, default: ``) port: The MongoDB port to connect to (int, default: 27017) query: The query to make to the mongo db (String, default: {}) split: Whether to split the query result as individual messages (boolean, default: true) timeunit: The time unit for the fixed and initial delays (String, default: SECONDS) username: The MongoDB username used for connecting (String, default: ``) MQTT Description Connects to an mqtt server and receives telemetry messages. Consola Web SOFIA2 Página 189/221

190 Binary: True to leave the payload as bytes (boolean, default: false) Charset: The charset used to convert bytes to String (when binary is false) (String, default: UTF-8) cleansession: Whether the client and server should remember state across restarts and reconnects (boolean, default: true) clientid: Identifies the client (String, default: xd.mqtt.client.id.src) connectiontimeout: The connection timeout in seconds (int, default: 30) keepaliveinterval: The ping interval in seconds (int, default: 60) Parameters password: The password to use when connecting to the broker (String, default: guest) persistence: Memory' or 'file' (String, default: memory) persistencedirectory: File location when using 'file' persistence (String, default: /tmp/paho) qos: The qos; a single value for all topics or a comma-delimited list to match the topics (String, default: 0) topics: The topic(s) (comma-delimited) to which the source will subscribe (String, default: xd.mqtt.test) url: Location of the mqtt broker(s) (comma-delimited list) (String, default: tcp://localhost:1883) username: The username to use when connecting to the broker (String, default: guest) Reactor-lp Description Acts as a server and allows a remote party to connect to Sofia2 and submit data over a raw TCP or UDP socket. códec: Codec used to transcode data (String, default: string) dispatcher: Type of Reactor Dispatcher to use (String, default: shared) Parameters framing: Method of framing the data (String, default: linefeed) host: Host to bind the server to (String, default: ) lengthfieldlength: Byte precision of the number used in the length field (int, default: 4) port: Port to bind the server to (int, default: 3000) Consola Web SOFIA2 Página 190/221

191 transport: Whether to use TCP or UDP as a transport protocol (String, no default) SFTP Description Supports transfer of files using the SFTP protocol. Files are transferred from the remote directory to the local directory where the module is deployed. autocreatelocaldir: if local directory must be auto created if it does not exist (boolean, default: true) deleteremotefiles: delete remote files after transfer (boolean, default: false) fixeddelay: Fixed delay in SECONDS to poll the remote directory (int, default: 1) host: The remote host to connect to (String, default: localhost) initialdelay: An initial delay when using a fixed delay trigger, expressed in TimeUnits (seconds by default) (int, default: 0) localdir: set the local directory the remote files are transferred to (String, default: /tmp/xd/output) maxmessages: the maximum messages per poll; -1 for unlimited (long, default: - 1) Parameters mode: specifies how the file is being read. By default the content of a file is provided as byte array (FileReadingMode, default: contents, possible values: ref,lines,contents) passphrase: the passphrase to use (String, default: ``) password: the password for the provided user (String, default: ``) pattern: simple filename pattern to apply to the filter (String, no default) port: the remote port to connect to (int, default: 22) privatekey: the private key location (a valid Spring Resource URL) (String, default: ``) regexpattern: filename regex pattern to apply to the filter (String, no default) remotedir: the remote directory to transfer the files from (String, no default) timeunit: the time unit for the fixed and initial delays (String, default: SECONDS) tmpfilesuffix: extension to use when downloading files (String, default:.tmp) user: the username to use (String, no default) Consola Web SOFIA2 Página 191/221

192 withmarkers: if true emits start of file/end of file marker messages before/after the data. Only valid with FileReadingMode 'lines' (Boolean, no default) Syslog Description Three syslog sources are provided: reactor-syslog, syslog-udp, and syslog-tcp. The reactorsyslog adapter uses tcp and builds upon the functionality available in the Reactor project and provides improved throughput over the syslog-tcp adapter. port: the port on which to listen (int, default: 5140) rfc: the format of the syslog (String, default: 3164) Parameters nio: use nio (recommend false for a small number of senders, true for many) (boolean, default: false) port: the port on which to listen (int, default: 5140) rfc: the format of the syslog (String, default: 3164) Tail Name Tail Delay: how often (ms) to poll for new lines (forces use of the Apache Tailer, requires nativeoptions='') (long, no default) filedelay: On platforms that don't wait for a missing file to appear, how often (ms) to look for the file (long, default: 5000) Parameters fromend: Whether to tail from the end (true) or from the start (false) of the file (forces use of the Apache Tailer, requires nativeoptions='') (boolean, no default) lines: the number of lines prior to the end of an existing file to tail; does not apply if 'nativeoptions' is provided (int, default: 0) name: the absolute path of the file to tail (String, default: /tmp/xd/input/<stream name>) nativeoptions: options for a native tail command; do not set and use 'end', 'delay', and/or 'reopen' to use the Apache Tailer (String, no default) reopen: whether to reopen the file each time it is polled (forces use of the Apache Tailer, requires Consola Web SOFIA2 Página 192/221

193 nativeoptions='') (boolean, no default) TCP Description The tcp source acts as a server and allows a remote party to connect to XD and submit data over a raw tcp socket. buffersize: the size of the buffer (bytes) to use when encoding/decoding (int, default: 2048) charset: the charset used when converting from bytes to String (String, default: UTF-8) decoder: the decoder to use when receiving messages (Encoding, default: CRLF, possible values:crlf,lf,null,stxetx,raw,l1,l2, L4) Parameters nio: whether or not to use NIO (boolean, default: false) port: the port on which to listen (int, default: 1234) reverselookup: perform a reverse DNS lookup on the remote IP Address (boolean, default: false) sockettimeout: the timeout (ms) before closing the socket when no data is received (int, default: ) usedirectbuffers: whether or not to use direct buffers (boolean, default: false) TCP-Client Description The tcp-client source module uses raw tcp sockets, as does the tcp module but contrary to the tcp module, acts as a client. Whereas the tcp module will open a listening socket and wait for connections from a remote party, the tcp-client will initiate the connection to a remote server and emit as messages what that remote server sends over the wire. As an optional feature, the tcp-client can itself emit messages to the remote server, so that a simple conversation can take place. Parameters buffersize: the size of the buffer (bytes) to use when encoding/decoding (int, default: 2048) charset: the charset used when converting from bytes to String (String, default: UTF-8) close: whether to close the socket after each message (boolean, default: false) Consola Web SOFIA2 Página 193/221

194 decoder: the decoder to use when receiving messages (Encoding, default: CRLF, possible values: CRLF,LF,NULL,STXETX,RAW,L1,L2,L4) Encoder: the encoder to use when sending messages (Encoding, default: CRLF, possible values: CRLF,LF,NULL,STXETX,RAW,L1,L2,L4) Expression: a SpEL expression used to transform messages (String, default: payload.tostring()) fixeddelay: the rate at which stimulus messages will be emitted (seconds) (int, default: 5) host: the remote host to connect to (String, default: localhost) maxmessages: the maximum messages per poll; -1 for unlimited (long, default: 1) nio: whether or not to use NIO (boolean, default: false) port: the port on the remote host to connect to (int, default: 1234) propertieslocation: the path of a properties file containing custom script variable bindings (String, no default) reverselookup: perform a reverse DNS lookup on the remote IP Address (boolean, default: false) script: reference to a script used to process messages (String, no default) sockettimeout: the timeout (ms) before closing the socket when no data is received (int, default: ) usedirectbuffers: whether or not to use direct buffers (boolean, default: false) variables: variable bindings as a comma delimited string of name-value pairs, e.g., 'foo=bar,baz=car' (String, no default) Time Description The time source will simply emit a String with the current time every so often. fixeddelay: time delay between messages, expressed in TimeUnits (seconds by default) (int, default: 1) Parameters format: how to render the current time, using SimpleDateFormat (String, default: yyyy-mm-dd HH:mm:ss) initialdelay: an initial delay when using a fixed delay trigger, expressed in TimeUnits (seconds by default) (int, default: 0) maxmessages: the maximum messages per poll; -1 for unlimited (long, default: Consola Web SOFIA2 Página 194/221

195 1) timeunit: the time unit for the fixed and initial delays (String, default: SECONDS) Trigger Description The trigger source emits a message or messages according to the provided trigger configuration. The message payload is a simple literal value, provided in the payload property. Cron: cron expression specifying when the trigger should fire (String, no default) Date: a one-time date when the trigger should fire; only applies if 'fixeddelay' and 'cron' are not provided (String, default: The current time) dateformat: the format specifying how the 'date' should be parsed (String, default: MM/dd/yy HH:mm:ss) Parameters fixeddelay: time delay between executions, expressed in TimeUnits (seconds by default) (Integer, no default) initialdelay: an initial delay when using a fixed delay trigger, expressed in TimeUnits (seconds by default) (int, default: 0) maxmessages: the maximum messages per poll; -1 for unlimited (long, default: 1) payload: the message that will be sent when the trigger fires (String, default: ``) timeunit: the time unit for the fixed and initial delays (String, default: SECONDS) Twitter Search Description The twittersearch source runs a continuous query against Twitter. connecttimeout: the connection timeout for making a connection to Twitter (ms) (int, default: 5000) Parameters consumerkey: a consumer key issued by twitter (String, no default) consumersecret: consumer secret corresponding to the consumer key (String, no default) geocode: geo-location given as latitude,longitude,radius. e.g., ' , ,1mi' (String, default:``) includeentities: whether to include entities such as urls, media and hashtags Consola Web SOFIA2 Página 195/221

196 (boolean, default: true) language: language code e.g. 'en' (String, default: ``) query: the query string (String, default: ``) readtimeout: the read timeout for the underlying URLConnection to the twitter stream (ms) (int, default: 9000) resulttype: result type: recent, popular, or mixed (ResultType, default: mixed, possible values: mixed,recent,popular) TwiterStream Description This source ingests data from Twitter s accesstoken: a valid OAuth access token (String, no default) accesstokensecret: an OAuth secret corresponding to the access token (String, no default) connecttimeout: the connection timeout for making a connection to Twitter (ms) (int, default: 5000) consumerkey: a consumer key issued by twitter (String, no default) consumersecret: consumer secret corresponding to the consumer key (String, no default) delimited: set to true to get length delimiters in the stream data (boolean, default: false) Parameters discarddeletes: set to discard 'delete' events (boolean, default: true) filterlevel: controls which tweets make it through to the stream: none,low,or medium (FilterLevel, default: none, possible values: none,low,medium) follow: comma delimited set of user ids whose tweets should be included in the stream (String, default: ``) language: language code e.g. 'en' (String, default: ``) locations: comma delimited set of latitude/longitude pairs to include in the stream (String, default: ``) readtimeout: the read timeout for the underlying URLConnection to the twitter stream (ms) (int, default: 9000) stallwarnings: set to true to enable stall warnings (boolean, default: false) track: comma delimited set of terms to include in the stream (String, default: ``) Consola Web SOFIA2 Página 196/221

197 16.5. Processor Hace la función de filtrado o tratamiento de la información que le llega a partir del source y el resultado se puede obtener a la salida de cada componente. Se puede encadenar más de un processor después del source. Se pueden encontrar de los siguientes tipos: Aggregator Description It does the opposite of the splitter, and builds upon the concept of the same name found in Spring Integration aggregation: how to construct the aggregated message (SpEL expression against a collection of messages) (String, default: #this.![payload]) correlation: how to correlate messages (SpEL expression against each message) (String, default: '<stream name>') count: the number of messages to group together before emitting a group (int, default: 50) dbkind: which flavor of init scripts to use for the jdbc store (blank to attempt autodetection) (String, no default) driverclassname: the jdbc driver to use when using the jdbc store (String, no default) Parameters hostname: hostname of the redis instance to use as a store (String, default: localhost) initializedatabase: whether to auto-create the database tables for the jdbc store (boolean, default: false) password: the password to use when using the jdbc or redis store (String, default: ``) port: port of the redis instance to use as a store (int, default: 6379) release: when to release messages (SpEL expression against a collection of messages accumulated so far) (String, no default) store: the kind of store to use to retain messages (StoreKind, default: memory, possible values: memory,jdbc,redis) timeout: the delay (ms) after which messages should be released, even if the completion criteria is not met (int, default: 50000) url: the jdbc url to connect to when using the jdbc store (String, no default) Consola Web SOFIA2 Página 197/221

198 username: the username to use when using the jdbc store (String, no default) Filter Description Use the filter module in a stream to determine whether a Message should be passed to the output channel. expression: a SpEL expression used to transform messages (String, default: payload.tostring()) Parameters propertieslocation: the path of a properties file containing custom script variable bindings (String, no default) script: reference to a script used to process messages (String, no default) variables: variable bindings as a comma delimited string of name-value pairs, e.g., 'foo=bar,baz=car' (String, no default) HTTP Client Description The http-client processor acts as a client that issues HTTP requests to a remote server, submitting the message payload it receices to that server and in turn emitting the response it receives to the next module down the line. charset: the charset to use when in the Content-Type header when emitting Strings (String, default: UTF-8) httpmethod: the http method to use when performing the request (HttpMethod, default: POST, possible values: OPTIONS,GET,HEAD,POST,PUT,PATCH,DELETE,TRACE,CONNECT) Parameters mappedrequestheaders: request message header names to be propagated to/from the adpater/gateway (String, default: HTTP_REQUEST_HEADERS) mappedresponseheaders: response message header names to be propagated from the adpater/gateway (String, default: HTTP_RESPONSE_HEADERS) replytimeout: the amount of time to wait (ms) for a response from the remote server (int, default: 0) url: the url to perform an http request on (String, no default) Consola Web SOFIA2 Página 198/221

199 Script Description The script processor contains a Service Activator that invokes a specified Groovy script. This is a slightly more generic way to accomplish processing logic, as the provided script may simply terminate the stream as well as transform or filter Messages. Parameters propertieslocation: the path of a properties file containing custom script variable bindings (String, no default) script: reference to a script used to process messages (String, no default) variables: variable bindings as a comma delimited string of name-value pairs, e.g., 'foo=bar,baz=car' (String, no default) Shell Description The shell processor forks an external process by running a shell command to launch a process written in any language. The process should implement a continual loop that waits for input from stdin and writes a result to stdout in a request-response manner. The process will be destroyed when the stream is undeployed. For example, it is possible to invoke a Python script within a stream in this manner. buffersize: the size of the buffer (bytes) to use when encoding/decoding (int, default: 2048) charset: the charset used when converting from String to bytes (String, default: UTF-8) Parameters command: the shell command (String, no default) encoder: the encoder to use when sending messages (Encoding, default: CRLF, possible values: CRLF,LF,NULL,STXETX,RAW,L1,L2,L4) environment: additional process environment variables as comma delimited name-value pairs (String, no default) redirecterrorstream: redirects stderr to stdout (boolean, default: false) workingdir: the process working directory (String, no default) Splitter Description The splitter module builds upon the concept of the same name in Spring Integration and allows the splitting of a single message into several distinct Consola Web SOFIA2 Página 199/221

200 messages. Parameters Expression: a SpEL expression which would typically evaluate to an array or collection (String, default: payload) Transform Description Use the transform module in a stream to convert a Message s content or structure. expression: a SpEL expression used to transform messages (String, default: payload.tostring()) Parameters propertieslocation: the path of a properties file containing custom script variable bindings (String, no default) script: reference to a script used to process messages (String, no default) variables: variable bindings as a comma delimited string of name-value pairs, e.g., 'foo=bar,baz=car' (String, no default) Sinks Siempre es el último módulo del esquema. Define dónde se van a volcar los datos que se han insertado a través del source y que posiblemente hayan sido procesados, aunque esto último es opcional y es posible conectar un source a un sink, sin procesamiento intermedio. A continuación se van a exponer aquellos módulos que no hayan sido expuestos anteriormente, ya que muchos de ellos se repiten. En caso de que algún módulo se repita pero sin embargo tenga parámetros diferentes, se incluirán en esta sección de nuevo: File Description It saves data into a file. Parameters Binary: if false, will append a newline character at the end of each line (boolean, default: false) Charset: the charset to use when writing a String payload (String, default: UTF- Consola Web SOFIA2 Página 200/221

201 8) Dir: the directory in which files will be created (String, default: /tmp/xd/output/) direxpression: spring expression used to define directory name (String, no default) mode: what to do if the file already exists (Mode, default: APPEND, possible values: APPEND,REPLACE,FAIL,IGNORE) Name: filename pattern to use (String, default: <stream name>) nameexpression: spring expression used to define filename (String, no default) suffix: filename extension to use (String, no default) FTP Description FTP sink is a simple option to push files to an FTP server from incoming messages. It uses an ftp-outbound-adapter, therefore incoming messages could be either a java.io.file object, a String (content of the file) or an array of bytes (file content as well). autocreatedir: remote directory must be auto created if it does not exist (boolean, default: true) clientmode: client mode to use: 2 for passive mode and 0 for active mode (int, default: 0) host: the host name for the FTP server (String, default: localhost) Parameters mode: what to do if the file already exists (Mode, default: REPLACE, possible values: APPEND,REPLACE,FAIL,IGNORE) Password: the password for the FTP connection (Password, no default) Port: the port for the FTP server (int, default: 21) remotedir: the remote directory to transfer the files to (String, default: /) remotefileseparator: file separator to use on the remote side (String, default: /) temporaryremotedir: temporary remote directory that should be used (String, default: /) tmpfilesuffix: extension to use on server side when uploading files (String, default:.tmp) Consola Web SOFIA2 Página 201/221

202 usetemporaryfilename: use a temporary filename while transferring the file and rename it to its final name once it's fully transferred (boolean, default: true) username: the username for the FTP connection (String, no default) HDFS Description Parameters FTP sink is a simple option to push files to an FTP server from incoming messages. It uses an ftp-outbound-adapter, therefore incoming messages could be either a java.io.file object, a String (content of the file) or an array of bytes (file content as well). closetimeout: timeout in ms, regardless of activity, after which file will be automatically closed (long, default: 0) codec: compression codec alias name (gzip, snappy, bzip2, lzo, or slzo) (String, default: ``) directory: where to output the files in the Hadoop FileSystem (String, default: /xd/<stream name>) fileextension: the base filename extension to use for the created files (String, default: txt) filename: the base filename to use for the created files (String, default: <stream name>) fileopenattempts: maximum number of file open attempts to find a path (int, default: 10) fileuuid: whether file name should contain uuid (boolean, default: false) fsuri: the URI to use to access the Hadoop FileSystem (String, default: ${spring.hadoop.fsuri}) idletimeout: inactivity timeout in ms after which file will be automatically closed (long, default: 0) inuseprefix: prefix for files currently being written (String, default: ``) inusesuffix: suffix for files currently being written (String, default:.tmp) overwrite: whether writer is allowed to overwrite files in Hadoop FileSystem (boolean, default: false) partitionpath: a SpEL expression defining the partition path (String, default: ``) rollover: threshold in bytes when file will be automatically rolled over (String, default: 1G) HDFS Dataset Name HDFS Dataset Consola Web SOFIA2 Página 202/221

203 allownullvalues: whether null property values are allowed, if set to true then schema will use UNION for each field (boolean, default: false) basepath: the base directory path where the files will be written in the Hadoop FileSystem (String, default: /xd) batchsize: threshold in number of messages when file will be automatically flushed and rolled over (long, default: 10000) compressiontype: compression type name (snappy, deflate, bzip2 (avro only) or uncompressed) (String, default: snappy) Parameters format: the format to use, valid options are avro and parquet (String, default: avro) fsuri: the URI to use to access the Hadoop FileSystem (String, default: ${spring.hadoop.fsuri}) idletimeout: idle timeout in milliseconds when Hadoop file resource is automatically closed (long, default: -1) namespace: the sub-directory under the basepath where files will be written (String, default: <stream name>) partitionpath: the partition path strategy to use, a list of KiteSDK partition expressions separated by a '/' symbol (String, default: ``) writercachesize: the size of the cache to be used for partition writers (10 if omitted) (int, default: -1) JDBC Description The JDBC sink can be used to insert message payload data into a relational database table. By default it inserts the entire payload into a table named after the stream name in the HSQLDB database that XD uses to store metadata for batch jobs. To alter this behavior, the jdbc sink accepts several options that you can pass using the --foo=bar notation in the stream, or change globally. Parameters abandonwhenpercentagefull: connections that have timed out wont get closed and reported up unless the number of connections in use are above the percentage (int, default: 0) alternateusernameallowed: uses an alternate user name if connection fails (boolean, default: false) columns: the database columns to map the data to (String, default: payload) connectionproperties: connection properties that will be sent to our JDBC Consola Web SOFIA2 Página 203/221

204 driver when establishing new connections (String, no default) driverclassname: the JDBC driver to use (String, no default) fairqueue: set to true if you wish that calls to getconnection should be treated fairly in a true FIFO fashion (boolean, default: true) initsql: custom query to be run when a connection is first created (String, no default) initialsize: initial number of connections that are created when the pool is started (int, default: 0) initializedatabase: whether the database initialization script should be run (boolean, default: false) initializerscript: the name of the SQL script (in /config) to run if 'initializedatabase' is set (String, default: init_db.sql) jdbcinterceptors: semicolon separated list of classnames extending org.apache.tomcat.jdbc.pool.jdbcinterceptor (String, no default) jmxenabled: register the pool with JMX or not (boolean, default: true) logabandoned: flag to log stack traces for application code which abandoned a Connection (boolean, default: false) maxactive: maximum number of active connections that can be allocated from this pool at the same time (int, default: 100) maxage: time in milliseconds to keep this connection (int, default: 0) maxidle: maximum number of connections that should be kept in the pool at all times (int, default: 100) maxwait: maximum number of milliseconds that the pool will wait for a connection (int, default: 30000) minevictableidletimemillis: minimum amount of time an object may sit idle in the pool before it is eligible for eviction (int, default: 60000) minidle: minimum number of established connections that should be kept in the pool at all times (int, default: 10) Password: the JDBC password (Password, no default) removeabandoned: flag to remove abandoned connections if they exceed the removeabandonedtimout (boolean, default: false) Consola Web SOFIA2 Página 204/221

205 removeabandonedtimeout: timeout in seconds before an abandoned connection can be removed (int, default: 60) suspecttimeout: this simply logs the warning after timeout, connection remains (int, default: 0) tablename: the database table to which the data will be written (String, default: <stream name>) testonborrow: indication of whether objects will be validated before being borrowed from the pool (boolean, default: false) testonreturn: indication of whether objects will be validated before being returned to the pool (boolean, default: false) testwhileidle: indication of whether objects will be validated by the idle object evictor (boolean, default: false) timebetweenevictionrunsmillis: number of milliseconds to sleep between runs of the idle connection validation/cleaner thread (int, default: 5000) url: the JDBC URL for the database (String, no default) useequals: true if you wish the ProxyConnection class to use String.equals (boolean, default: true) username: the JDBC username (String, no default) validationinterval: avoid excess validation, only run validation at most at this frequency - time in milliseconds (long, default: 30000) validationquery: sql query that will be used to validate connections from this pool (String, no default) validatorclassname: name of a class which implements the org.apache.tomcat.jdbc.pool.validator (String, no default) Log Description Probably the simplest option for a sink is just to log the data. The log sink uses the application logger to output the data for inspection. Parameters Expression: the expression to be evaluated for the log content; use '#root' to log the full message (String, default: payload) Consola Web SOFIA2 Página 205/221

206 Level: the log level (String, default: INFO) Name: the name of the log category to log to (will be prefixed by 'xd.sink.') (String, default: <stream name>) Mail Description The "mail" sink allows sending of messages as s, leveraging Spring Integration mail-sending channel adapter. Please refer to Spring Integration documentation for the details, but in a nutshell, the sink is able to handle String, byte[] and MimeMessage messages out of the box. Bcc: the recipient(s) that should receive a blind carbon copy (SpEL) (String, default: null) Cc: the recipient(s) that should receive a carbon copy (SpEL) (String, default: null) contenttype: the content type to use when sending the (SpEL) (String, default: null) from: the primary recipient(s) of the (SpEL) (String, default: null) Parameters host: the hostname of the mail server (String, default: localhost) password: the password to use to connect to the mail server (String, no default) port: the port of the mail server (int, default: 25) replyto: the address that will become the recipient if the original recipient decides to "reply to" the (SpEL) (String, default: null) subject: the subject (SpEL) (String, default: null) to: the primary recipient(s) of the (SpEL) (String, default: null) username: the username to use to connect to the mail server (String, no default) Mongo Description The Mongo sink writes into a Mongo collection. Parameters authenticationdatabasename: the MongoDB authentication database used for connecting (String, default: ``) Consola Web SOFIA2 Página 206/221

207 collectionname: the MongoDB collection to store (String, default: <stream name>) databasename: the MongoDB database name (String, default: xd) host: the MongoDB host to connect to (String, default: localhost) password: the MongoDB password used for connecting (String, default: ``) port: the MongoDB port to connect to (int, default: 27017) username: the MongoDB username used for connecting (String, default: ``) writeconcern: the default MongoDB write concern to use (WriteConcern, default: SAFE, possible values: NONE,NORMAL,SAFE, FSYNC_SAFE, REPLICAS_SAFE, JOURNAL_SAFE,MJJORITY) MQTT Description The mqtt sink connects to an mqtt server and publishes telemetry messages. Async: whether or not to use async sends (boolean, default: false) Charset: the charset used to convert a String payload to byte[] (String, default: UTF-8) cleansession: whether the client and server should remember state across restarts and reconnects (boolean, default: true) clientid: identifies the client (String, default: xd.mqtt.client.id.snk) connectiontimeout: the connection timeout in seconds (int, default: 30) keepaliveinterval: the ping interval in seconds (int, default: 60) Parameters password: the password to use when connecting to the broker (String, default: guest) persistence: 'memory' or 'file' (String, default: memory) persistencedirectory: file location when using 'file' persistence (String, default: /tmp/paho) qos: the quality of service to use (int, default: 1) retained: whether to set the 'retained' flag (boolean, default: false) topic: the topic to which the sink will publish (String, default: xd.mqtt.test) url: location of the mqtt broker(s) (comma-delimited list) (String, default: tcp://localhost:1883) username: the username to use when connecting to the broker (String, default: guest) Consola Web SOFIA2 Página 207/221

208 Redis Description Redis sink can be used to ingest data into redis store. You can choose queue, topic or key with selcted collection type to point to a specific data store. collectiontype: the collection type to use for the given key (CollectionType, default: LIST, possible values: LIST,SET,ZSET,MAP,PROPERTIES) Database: database index used by the connection factory (int, default: 0) Hostname: redis host name (String, default: localhost) Key: name for the key (String, no default) keyexpression: a SpEL expression to use for keyexpression (String, no default) maxactive: max number of connections that can be allocated by the pool at a given time; negative value for no limit (int, default: 8) maxidle: max number of idle connections in the pool; a negative value indicates an unlimited number of idle connections (int, default: 8) Parameters maxwait: max amount of time (in milliseconds) a connection allocation should block before throwing an exception when the pool is exhausted; negative value to block indefinitely (int, default: -1) minidle: target for the minimum number of idle connections to maintain in the pool; only has an effect if it is positive (int, default: 0) password: redis password (String, default: ``) port: redis port (int, default: 6379) queue: name for the queue (String, no default) queueexpression: a SpEL expression to use for queue (String, no default) sentinelmaster: name of Redis master server (String, default: ``) sentinelnodes: comma-separated list of host:port pairs (String, default: ``) topic: name for the topic (String, no default) topicexpression a SpEL expression to use for topic (String, no default) Shell Description The shell sink forks an external process by running a shell command to launch a process written in any language. The process should implement a continual loop that waits for and consumes input from stdin. The process will be destroyed when the stream is undeployed. Consola Web SOFIA2 Página 208/221

209 buffersize: the size of the buffer (bytes) to use when encoding/decoding (int, default: 2048) charset: the charset used when converting from String to bytes (String, default: UTF-8) Parameters command: the shell command (String, no default) encoder: the encoder to use when sending messages (Encoding, default: CRLF, possible values: CRLF,LF,NULL,STXETX,RAW,L1,L2,L4) Environment: additional process environment variables as comma delimited name-value pairs (String, no default) redirecterrorstream: redirects stderr to stdout (boolean, default: false) workingdir: the process working directory (String, no default) TCP Description The TCP Sink provides for outbound messaging over TCP. buffersize: the size of the buffer (bytes) to use when encoding/decoding (int, default: 2048) charset: the charset used when converting from String to bytes (String, default: UTF-8) close: whether to close the socket after each message (boolean, default: false) encoder: the encoder to use when sending messages (Encoding, default: CRLF, possible values: CRLF,LF,NULL,STXETX,RAW,L1,L2,L4) Parameters Host: the remote host to connect to (String, default: localhost) Nio: whether or not to use NIO (boolean, default: false) Port: the port on the remote host to connect to (int, default: 1234) reverselookup: perform a reverse DNS lookup on the remote IP Address (boolean, default: false) sockettimeout: the timeout (ms) before closing the socket when no data is received (int, default: ) usedirectbuffers: whether or not to use direct buffers (boolean, default: false) Consola Web SOFIA2 Página 209/221

210 Counter Description A counter is a Metric that associates a unique name with a long value. It is primarily used for counting events triggered by incoming messages on a target stream. Parameters Name: the name of the metric to contribute to (will be created if necessary) (String, default: <stream name>) nameexpression: a SpEL expression to compute the name of the metric to contribute to (String, no default) Field Value Counter Description A field value counter is a Metric used for counting occurrences of unique values for a named field in a message payload. fieldname: the name of the field for which values are counted (String, no default) Parameters name: the name of the metric to contribute to (will be created if necessary) (String, default: <stream name>) nameexpression: a SpEL expression to compute the name of the metric to contribute to (String, no default) Aggregate Counter Description The aggregate counter differs from a simple counter in that it not only keeps a total value for the count, but also retains the total count values for each minute, hour day and month of the period for which it is run. The data can then be queried by supplying a start and end date and the resolution at which the data should be returned. dateformat: a pattern (as in SimpleDateFormat) for parsing/formatting dates and timestamps (String, default: yyyy-mm-dd't'hh:mm:ss.sss'z') Parameters incrementexpression: how much to increment each bucket, as a SpEL against the message (String, default: 1) name: the name of the metric to contribute to (will be created if necessary) (String, default: <stream name>) nameexpression: a SpEL expression to compute the name of the metric to contribute to (String, no default) Consola Web SOFIA2 Página 210/221

211 timefield: name of a field in the message that contains the timestamp to contribute to (String, default: null) Gauge Description A gauge is a Metric, similar to a counter in that it holds a single long value associated with a unique name. In this case the value can represent any numeric value defined by the application. Parameters Name: the name of the metric to contribute to (will be created if necessary) (String, default: <stream name>) nameexpression: a SpEL expression to compute the name of the metric to contribute to (String, no default) Rich Gauge Description A rich gauge is a Metric that holds a double value associated with a unique name. In addition to the value, the rich gauge keeps a running average, along with the minimum and maximum values and the sample count. Alpha: smoothing constant, or -1 to use arithmetic mean (double, default: -1.0) Parameters Name: the name of the metric to contribute to (will be created if necessary) (String, default: <stream name>) nameexpression: a SpEL expression to compute the name of the metric to contribute to (String, no default) Job Es equivalente a un Stream pero con la diferencia de que se puede planificar y por tanto lanzar cuando se desee. El modo de crearlos dista bastante del de los Streams ya que únicamente rellenando un formulario se podrá dar de alta al job predefinido elegido. En su interior posee cuatro ventanas, cada una de las cuales se va a explicar a continuación: Módulos: En esta ventana se pueden ver cada uno de los componentes con los que se puede crear un Job. Junto al nombre se pueden ver los detalles (en los que se informa de los parámetros de configuración) y la opción de crear una definición. Al elegir esta última opción, se abrirá el formulario que es necesario rellenar. No todos los parámetros Consola Web SOFIA2 Página 211/221

212 son obligatorios. El nombre de cada módulo es orientativo a lo que se hace con él, por ejemplo filejdbc implica que a partir del source file, se guardarán los datos en un sink de tipo jdbc. A continuación se va a mostrar una porción del formulario del Job timestampfile a modo de ejemplo: Consola Web SOFIA2 Página 212/221

213 Haciendo un listado de todos los Jobs diferentes que se pueden crear se puede ver: 1. Filejdbc: Import CSV to JDBC 2. Filepollhdfs: Import CSV files to HDFS 3. Ftphdfs: Import FTP to HDFS 4. Gpload: Running gpload as a batch job 5. Hdfsjdbc: Export HDFS to JDBC 6. Hdfsmongodb: Export HDFS to MongoDB 7. Jdbchdfs: Import JDBC to HDFS 8. Sparkapp: Running Spark application as a batch job 9. Sqoop: Running Sqoop as a batch job 10. Timestamfile: Prints the Timestamp to a selected file Definiciones: Aquí se pueden ver todos los Jobs existentes en el sistema, así como su estado y sus parámetros de configuración. Despliegues: De nuevo, ofrece la posibilidad de ver los detalles de cada Job y adicionalmente permite lanzarlos o planificarlos para que se lancen cada un cierto tiempo. Ésta última característica es posible gracias a la creación de un Stream que se comunica con el Job en cuestión, informando al sistema de cuando se debe lanzar y ejecutándolo. Consola Web SOFIA2 Página 213/221

214 En caso de que se desee planificarlo, se accederá a la siguiente pantalla: Ejecuciones: Por último, se dispone de la información acerca de la ejecución de los Job. En caso de que un Job este ejecutándose, se ofrece la posibilidad de pararlo y relanzarlo. A continuación se puede ver un ejemplo de la información mostrada en esta sección: Como se puede ver, aunque el Job en cuestión haya sido eliminado, la información acerca de su ejecución queda registrada Un Vistazo a la UI Definiciones En esta ventana, se puede ver una breve descripción de lo que se puede hacer desde la pestaña Definiciones (activar, desactivar y destruir), dando la posibilidad de ver en detalle las características de cada Stream dado de alta. Consola Web SOFIA2 Página 214/221

215 Si se descomprime uno de ellos, se puede ver cómo está formado y sus parámetros en caso en el que se hayan configurado: El círculo verde debajo de cada elemento indica que este módulo se está ejecutando sin errores aparentes. Obviamente, si el Stream en cuestión estuviese desactivado, no aparecería este indicador. En este caso, se verían los módulos de color gris, indicando con ello que no están operativos. Se incorpora la siguiente imagen que demuestra este comportamiento: Por tanto, cuando se active un Stream, se irá convirtiendo de color gris a azul y posteriormente se podrá ver el indicador de estado mencionado anteriormente. La manera en que están relacionados los módulos se va a explicar a la hora de la creación y configuración de Streams Crear Stream Aquí se dispone de varias herramientas para la creación de Streams, todas ellas equivalentes. En primer lugar se va a mostrar y a explicar cada una de las ventanas que aparecen en esta pantalla. Consola Web SOFIA2 Página 215/221

216 Se va a ir haciendo un ejemplo a medida que se va explicando brevemente cada sección. Para ello, se va a añadir un source de tipo file: Una vez encontrado lo único que se tiene que hacer es arrastrarlo a la izquierda, quedando así: Consola Web SOFIA2 Página 216/221

217 Notar que en la ventana superior se ha actualizado y muestra el módulo desplegado. Desde esta ventana o seleccionando el componente file se pueden ver las propiedades por defecto y configurarlas como se desee: Además aparece una X junto al componente arrastrado, por si se desea borrar este componente de la ventana. Una vez configurado el componente como se desee, se va a proceder a crear un destino (sink) para volcar los datos obtenidos desde un fichero. Para este ejemplo, se van a volcar los datos por pantalla de la consola, por lo que se busca el modulo log contenido en el interior de sink y se añade al esquema. Para unir ambos elementos, se debe de arrastrar el componente log hasta el otro componente, hasta que ambos se subrayen de color azul, que indica que si se suelta el componente se creará un enlace entre ellos. Una vez realizado esto, quedará el siguiente resultado: Consola Web SOFIA2 Página 217/221

218 De nuevo se puede ver que la ventana inmediatamente superior al esquema se actualiza con la configuración y con la unión de los componentes. Si se deseara cambiar alguna de las propiedades de manera más rápida a la vista anteriormente, se puede cambiar directamente en esta ventana lo que se desee, siendo sustitutiva además con la ventana del esquema, es decir, si en ese código se eliminara todo menos file, el esquema visual también se actualiza a lo que se está describiendo en esta ventana. Justo encima de la sección source se dispone de una ventana que hace las funciones de buscador de componentes, si se desea buscar, por ejemplo, el componente file sería como sigue: Como se puede ver, se dispone de este componente tanto como source como sink, puedo elegir por tanto el origen y destino de los datos. Llegados a este punto, se procede a crear el Stream definido. Dándole al botón Crear Stream se puede indicar el nombre de éste, además de si se desea activarlo o no: Nada más crearlo, se dispondrá de este Stream en el apartado de definiciones, anteriormente explicado. La creación de Streams se puede complicar enormemente si se adjuntan al diseño componentes adicionales, como los processor, que permiten transformar la información suministrada por un módulo source antes de llegar al sink. Consola Web SOFIA2 Página 218/221

219 Además, se debe mencionar que no tiene por qué crearse varios Streams paso a paso (es decir, diseñando cada uno de ellos y dándole a crear), sino que se pueden crear varios Streams a la vez, como se muestra en la siguiente imagen: Al darle a crear Stream, se crearán (en este caso) dos Streams independientes entre sí y se ofrece la posibilidad de llamarlos como se desee y de activarlos nada más crearlos, como se puede ver a continuación: Análisis Desde esta ventana, se pueden ver de manera gráfica los datos que se están transmitiendo en caso de que exista el mecanismo necesario para visualizarlos y éstos sean numéricos. Así pues se obtiene la siguiente ventana: Consola Web SOFIA2 Página 219/221

220 Como se puede ver, ofrece un abanico de posibilidades de representación de los datos. Ahora se va a explicar cómo hacer que los datos numéricos que se están analizando desde un Stream sean visibles gráficamente. Para ello, en realidad se debe crear otro Stream diferente, que sea capaz de enlazar con otro ya creado cuyos datos numéricos de intercambio se deseen visualizar. Siguiendo con el ejemplo anterior, ahora se desea visualizar los datos contenidos en el fichero y que se están transportando hasta el log de la consola. Para ello se diseña el siguiente Stream: Como se puede ver, en este caso se ha creado un visualizador de tipo counter. Una vez creado de la manera anterior, se pueden visualizar los datos desde la ventana Análisis: Otra manera de representarlo sería la siguiente: Consola Web SOFIA2 Página 220/221

221 Consola Web SOFIA2 Página 221/221