-
Notifications
You must be signed in to change notification settings - Fork 1
Requisitos
Este módulo se encarga de cargar los datos de los agentes que podrán enviar incidencias al sistema. A diferencia del curso pasado, hay diferentes tipos de agentes: personas físicas, entidades, sensores, etc. Cada tipo de usuario estará identificado por una palabra clave. Ejemplos de identificadores del tipo de agente son: "Person", "Entity", "Sensor", etc.
La introducción de los datos se hará a partir de ficheros Excel. Los campos del fichero Excel son diferentes a los del sistema anterior, los campos son:
- Nombre (en el caso de personas, contendrá nombre y apellidos)
- Localización (coordenadas geográficas del agente). Este valor es opcional para personas y entidades. Si no hay localización el valor estará en blanco.
- Email: Correo electrónico de contacto. En el caso de sensores u otro tipo de agentes automáticos, puede ser el correo electrónico de la persona que lo administra.
- Identificador: Identificador del agente. En caso de personas físicas o entidades puede ser el CIF. Este identificador será único en el sistema y será el nombre de usuario.
- Tipo: Número entero que representa el tipo de agente.
Además del fichero Excel que contiene los datos de cada agente, el sistema utilizará un fichero maestro en formato CSV que contiene los tipos de agentes disponibles. El fichero tiene 2 campos separados por comas donde el primer campo es el código numérico y el segundo el nombre del tipo de usuario. Por ejemplo:
- Person
- Entity
- Sensor
Los códigos y tipos de agentes que aparezcan en este fichero maestro pueden variar, y el sistema de carga tendrá en cuenta los códigos numéricos para resolver el tipo de entidad que corresponda.
Este módulo analizará los datos de los agentes, creando un informe de errores, si se producen. Por cada agente, se almacenará la información proporcionada, junto con una clave de acceso que se generará aleatoriamente. Toda esa información será almacenada en una base de datos que será utilizada por el otro módulo.
Además, se creará una lista de cartas personalizadas para informar del usuario y clave introducido en el sistema y que se enviarán a los correos electrónicos que se han indicado. A diferencia del año pasado, el usuario del sistema será el campo identificador (el año pasado era el correo electrónico).
El sistema podría extenderse para emitir cartas en formatos como Word o PDF comunicándole a la persona su nombre de usuario y su clave de acceso. Si el fichero viniera con errores, se detectarían y se enviarían los datos a un fichero de LOG para su posterior tratamiento.
El analizador de los datos de entrada debe ser configurable, ya que podrían venir los datos en diferentes formatos y no sólo en Excel. Es opcional permitir más de una entrada, pero es obligatorio que el sistema permita en el futuro una ampliación de manera sencilla.
Al igual que en el curso pasado, este módulo consiste en un servicio Web REST que permitirá consultar y obtener información de los agentes que participan en el sistema. El servicio Web está pensado para ser utilizado por agentes que puedan conectarse al sistema, por lo que la entrada serán ficheros en formato JSON y las respuestas también serán en formato JSON.
Al igual que el año pasado, este sistema podrá disponer de un subsistema de acceso a través de Web para actualizar la clave de cada usuario. Opcionalmente, podrán actualizarse otros campos de los usuarios. El formato de las invocaciones al sistema es el siguiente (obsérvese que se han modificado 2 campos respecto al año pasado):
{"login": usuario, "password": password, "kind": tipo de agente}
En caso de que la combinación login/password/kind aparezca en la base de datos, se devolverá la siguiente información:
{
"id": "id_usuario" (long),
"password": "password",
"kind": "tipo_usuario",
"kindCode": "id_kind" (long),
"dni": "dni",
"nombre": "nombre",
"apellidos": "apellidos",
"email": "email",
"username": "nombre_usuario"
}
El campo "kindCode" se obtiene a partir de un fichero maestro en formato CSV que se ha descrito en la sección anterior. Se puede crear un sencillo interfaz de acceso en HTML para que los usuarios puedan entrar en el sistema, consultar su información o incluso modificar algunos datos.
Este módulo se encarga de tramitar las incidencias que serán enviadas por los agentes. El módulo se comunicará con el módulo 2 (Agents) para chequear que los agentes están dados de alta en el sistema y tienen permisos para enviar incidencias.
Pueden existir diferentes tipos de agentes para enviar incidencias: personas, entidades, sensores, etc. El tipo de agentes no está predeterminado, sino que se obtendrá del mismo fichero maestro descrito en el primer entregable. Cada incidencia puede contener los siguientes campos: nombre de usuario y password, nombre de la incidencia, descripción, localización (se obtendrá automáticamente del dispositivo si es posible), etiquetas (lista de palabras separadas por comas que permitirán categorizar las incidencias), información adicional (fotos, vídeos, etc.).
Algunas incidencias podrán también contener una lista de campos con la forma "propiedad/valor", donde el campo propiedad indica un nombre de propiedad, y el campo valor, indica el valor de dicha propiedad.
En caso de que la combinación "nombre de usuario/password" sea incorrecta, las incidencias no serán procesadas y se informará del error.
Si la combinación es correcta, se procesarán las incidencias y se enviará la incidencia procesada a Apache Kafka para su posterior análisis por parte del módulo 4 (InciDashboard).
Los sensores pueden estar enviando incidencias, de forma continua, dependiendo de cómo estén configurados. Por ejemplo, un sensor de temperatura puede estar configurado para emitir incidencias cada hora con información sobre la temperatura en un determinado lugar.
Las incidencias adquirirán un estado (abierta, en proceso, cerrada, anulada) así como otra información generada por el sistema (persona/entidad asignada para resolver la incidencia), comentarios sobre la incidencia realizados por los operarios, etc. Las incidencias también pueden tener una caducidad, por ejemplo, en el caso de las incidencias que pueda enviar un sensor de temperatura, si se envían cada hora, tendrán una hora de caducidad). El sistema solamente almacenará un subconjunto de las incidencias enviadas (por ejemplo, las enviadas por personas o entidades, o algunos valores específicos enviados por los sensores). Las cuales podrán consultar las incidencias que han enviado utilizando el nombre de usuario y la clave asignadas en el módulo 1. Cada agente podrá tener acceso a todas las incidencias que ha enviado y realizar un seguimiento de estas.
El cuadro de mandos está pensado para que sea utilizado por el personal de gestión de incidencias, que podrá visualizar y gestionar las incidencias que ocurren en el sistema.
Este módulo recibirá las incidencias suministradas por el módulo 3 (InciManager) a través de Apache Kafka.
Ciertos agentes, como los sensores, estarán enviando continuamente incidencias, con los valores de ciertas propiedades. El cuadro de mandos se configurará indicando qué valores pueden permitirse en ciertas propiedades y cómo clasificar los valores de otras propiedades.
En caso de que los valores de ciertas propiedades sean peligrosos, el sistema notificará a los operarios del sistema para que tomen las acciones correspondientes.
El sistema ofrecerá una monitorización continua de la evolución de los valores de las propiedades más representativas de los sensores, así como de las incidencias que estén siendo generadas por las personas o entidades.
También se ofrecerá la posibilidad de visualizar las incidencias geolocalizadas en un mapa, así como los valores actuales, los estados y los históricos de algunas (por ejemplo, de la temperatura).
El sistema ofrecerá información a los operarios sobre las incidencias que tienen asignadas y les permitirá controlar dichas incidencias, cambiando el estado de las incidencias según se hayan procesado o no.
El sistema podrá ofrecer diferentes visualizaciones gráficas o estadísticas de las incidencias.
Jesus García Minas. @JesusGarciaMinas | UO250999 |
Pelayo García Torre. @Pelayo-Torre | UO251143 |
José Antonio García García. @MrKarrter | UO251317 |
César Camblor García. @cesarcamblor | UO251281 |
Pablo Díaz Rancaño. @PablooD9 | UO251017 |
Fernando De la Torre Cueva. @Ferpobe | UO245182 |
Pablo Álvarez Álvarez. @PabloAlvarezUO251561 | UO251561 |