Se compone de una aplicación web que permite a un usuario mediante un formulario realizar una solicitud donde, diligencia sus datos personales, selecciona una fecha de visita y un redacta motivo de visita, para el

ingreso a la granja Román Gómez Gómez del PCJIC, las solicitudes de ingreso son respondidas por un administrador que acepta o rechaza la solicitud del usuario. Si la solicitud es aceptada se le envía un email al usuario que contiene un código QR de ingreso a la granja y la fecha única de valides del mismo. Este código posteriormente se valida en la entrada de la granja donde es escaneado y verificado en la base de datos, para conceder o denegar el acceso a la granja por medio de un módulo scanner QR.

Las tecnologías y dispositivos que usan:

El desarrollo fue construido en su mayor parte en el lenguaje de programación orientado a objetos JavaScript [10], [11].

Arquitectura: Implementan la arquitectura de software Cliente-Servidor [15], [11], como se muestra en la Figura 1. Esta arquitectura es de gran ventaja y permite que se pueda intervenir en el código fácilmente y realizar cambios que comprenden el módulo de seguridad a implementar.

Cliente: Esta construido en React Js, [15], la gran ventaja es que permite un mayor dinamismo en la página por los diferentes componentes que se reutilizan.

Servidor: Esta construido en Node Js [16], [11], para el desarrollo simple del servidor utilizan el frame work Express [17], que proporciona un fácil desarrollo de la APIRESTful.

Figura 1
Diagrama de arquitectura de software implementada

Base de datos: Una base de datos de tipo relacional, Implementada en el sistema gestor de PostgreSQL, construida en lenguaje PSQL, que es similar y basado al muy conocido SQL (Structured Query Language). Con únicamente tres tablas las cuales no tienen relación y las consultas se efectúan en alguna tabla, por lo que abunda redundancia.

Autenticación: Se basan en la tecnología QR que significa (Quick Response), o código de respuesta rápida, donde utilizan códigos QR para almacenar información de la solicitud de un visitante que tiene acceso a la granja. La información se codifica en una matriz de puntos bidireccional conformada por módulos de color blancos y negros. En la Figura 2. se presenta la estructura y características generales de los códigos QR.

Figura 2
Estructura y características de los códigos QR [18]

AWS: Utilizan el servicio de almacenamiento en la nube llamado S3 donde almacenan códigos QR.

Modulo Scanner QR: Esta desarrollado en Python, [19]. También Utiliza librería OpenCV para el manejo de datos multimedia al momento de leer el código QR, la plataforma o dispositivo físico en donde se corre este módulo es una Raspberry pi 3 modelo B (micro procesador o mini pc) y para la lectura de los códigos se utiliza una pi camera v1.3, (un dispositivo de hardware adicional propio de la raspberry).

Marco Legal: Se sujeta a la Ley 1581 de 2012 artículo 189 de la constitución política de Colombia, para el tratamiento, manejo adecuado y la protección de los datos personales de los usuarios, la cual se identifica en [20].

Como punto de partida se establece un nuevo modelo de base de datos completo el cual describe cómo será el comportamiento y almacenamiento de los datos, fue necesario reemplazar la base de datos existente por problemas como redundancia de datos, información ineficiente, falta de relaciones, falta de tablas, ya que solo contaba con tres tablas. Las tablas solicitud_ingreso y solicitud_aprobada guardaban los mismos datos, no es una buena práctica, además, de que no brinda información de utilidad, por lo que se mezclaba la información de la solicitud y el usuario, la tabla usuario_admin que contenía las credenciales del administrador no posee problemas. Por lo tanto, se realiza un nuevo diseño del modelo de base de datos, el cual se diseña estratégicamente para cumplir todas las necesidades que debe abordar el módulo de seguridad. Esto se evidencia en la Figura 3.

Figura 3
Modelo entidad relación de la base de datos

Se establecieron diez (10) tablas las cuales se relacionan para brindar información de utilidad, eficiencia en las consultas, además eliminamos la redundancia, y se añadieron tablas con el fin de poder dar una vía para el correcto cumplimiento del protocolo que constantemente requiere de información específica y de fácil acceso Tabla 1.

Una vez realizado el diseño de la base de datos, se procede con el diseño del protocolo, este se desarrolla basado en varias etapas las cuales tanto el administrador, el usuario, el cliente, el servidor y el módulo scanner cumplen roles y actividades que se deben lograr para poder garantizar el control y la seguridad en las zonas, ya que el ingreso será especifico de personas autorizadas y la cantidad permitida de ingreso por zona en todo momento será controlada.

El proceso de generar solicitudes se realiza mediante un formulario donde el usuario diligencia sus datos personales y demás datos sobre la visita, fue modificado especialmente para brindar mayor interacción entre componentes del cliente y el servidor, con fin de eliminar los objetos estáticos del lado del cliente, esto quiere decir que todos los recursos se consumen de la APIRESTful y de forma dinámica se actualizan los datos del componente según la elección del usuario, Se garantiza una elección especifica de zonas disponibles según la fecha. En la Figura 4 se presenta de forma resumida y clara el funcionamiento de la Etapa 1 del protocolo, en un esquema, donde los recuadros de color verde encierran los componentes del cliente añadidos y modificados los cuales están en constante interacción con la API del servidor y se observa la dependencia entre el componente zona respecto a fecha.

Tabla 1
Descripción de las tablas del modelo de datos

Figura 4
Esquema de funcionamiento del protocolo etapa 1

Esta etapa internamente se dividió en dos subetapas, puesto que se van a gestionar solicitudes pendientes y solicitudes que ya fueron aprobadas.

1) Etapa 2.1 Solicitudes pendientes

En el proceso de gestión de solicitudes pendientes se realizan modificaciones a los cards donde se despliega la información de cada solicitud que contendrá datos personales del usuario, visita y específicamente zonas solicitadas por el usuario, además, un espacio de observaciones. El administrador podrá realizar acciones como aceptar solicitud, permiso especial y rechazar la solicitud. Para los casos “Aceptar” y “Especial”, se debe seleccionar cuales zonas se van a autorizar y dejar una observación si es necesario, se envía la respuesta al servidor, se actualiza la base de datos y genera un código QR de autenticación para las zonas autorizadas, que posteriormente se envía por correo al usuario, la única diferencia es que un permiso especial no tiene fecha de caducidad para el ingreso hasta nueva orden. Ahora, para el caso de “Rechazar” no se debe seleccionar ninguna zona, pero sí dejar una observación, se envían los datos al servidor y se actualiza la base de datos para luego enviar un correo de respuesta al usuario donde indique que ha sido rechazada la solicitud. A continuación, se muestra el esquema de funcionamiento resumido para la etapa 2.1 Figura 5.

Figura 5
Esquema de funcionamiento del protocolo etapa 2.1

2) Etapa 2.2 – Solicitudes aprobadas

El proceso de gestión de solicitudes aprobadas fue modificado para no eliminar ningún registro en la base de datos, pero sí alterarlo en su estado, se basa en la acción “Rechazar” de la subetapa anterior, pero la diferencia es que se anulan solicitudes o permisos que antes fueron aceptados, esto es necesario por motivos de seguridad y control sobre las personas que dejan de tener acceso en las zonas. El administrador envía los datos al servidor y se realizan las modificaciones en la base de datos, luego el usuario recibe un correo donde se le informa que sus permisos fueron anulados.

A continuación, se muestra de forma resumida el esquema de funcionamiento para la anulación de solicitudes aprobadas. Figura 6.

Figura 6
Esquema de funcionamiento del protocolo etapa 2.2

El proceso de validación de ingreso de usuarios fue modificado para que un usuario se dirija a cada zona donde presentara el código QR de autenticación, funciona mediante el módulo scanner que estará ubicado en cada zona, fue intervenido para la manipulación de los datos una vez son decodificados, para convertirlos en formato JSON [17], [19] junto con la zona donde se encuentra realizando la lectura, para luego enviar la petición HTTP de tipo POST al servidor, puesto que ahora se debe registrar la visita en la base de datos, solo si la validación es correcta, una vez el servidor comprueba los datos de autenticación del usuario en la zona, envía una respuesta para autorizar o denegar el acceso. A continuación, en la Figura 7, se muestra de forma resumida el funcionamiento de la etapa 3 mediante un esquema.

Figura 7
Esquema de funcionamiento del protocolo etapa 3

El proceso de control de vistas se añadió como necesidad de visualizar lo que ocurre en tiempo real en cada zona, su funcionamiento se basa en la tecnología WebSocket, usando la dependencia Socket.io en ambos sentidos, tanto el lado del cliente como del servidor, se basa en eventos que se emiten y se escuchan por un canal de intercambio de datos bidireccional, lo que permite la visualización en tiempo real de los registros de ingreso que se presentan en las zonas, así mismo, se añadieron componentes para la interacción con un filtro especial por zonas y por fecha, para un mejor enfoque de control en las zonas, los datos se visualizan en una tabla. Se puede observar el funcionamiento en un esquema de la Figura 8.

En la Figura 10, se muestra un ejemplo de la herramienta utilizada para la administración de la base de datos y así mismo, para realizar las pruebas de consultas SQL.

Figura 8
Esquema de funcionamiento del protocolo etapa 4

Figura 9
Base de datos y lista de tablas creadas en PostgreSQL

Figura 10
Herramienta PgAdmin

Anteriormente se había mencionado, la base de datos estaba implementada bajo el motor de base de datos relacional PostgreSQL, por lo que se opta continuar con este gestor, puesto que nos provee buenas herramientas tanto gráfica y de consola para crear la nueva base de datos, realizar pruebas de las consultas y las respectivas modificaciones, además, es gratuita y de código abierto. Según el modelo de datos creado en el procedimiento 2, se procede a realizar la creación de la base de datos y posteriormente las tablas por la terminal de comandos, se utiliza lenguaje PSQL y como resultado obtenemos las siguientes tablas que se muestran en la Figura 9.

Figura 11
Estructura y modificaciones en el Backend

A continuación, se explican los cambios y mejoras en cada uno de los directorios de la estructura del proyecto:

• Controllers: Esta carpeta contiene todos los archivos o clases donde se definen los controladores, para resolver cada una de las rutas de la API. Cada controlador ejecuta métodos necesarios para tratar y manipular la información recibida y a entregar al cliente. Se modificaron y añadieron características a los controladores, siguiendo el protocolo que se encuentra en la clase “protocoloSolicitud”, que es donde se constata cada método que será utilizado por los controladores y además, se añadió el controlador “visitasController” para manejar los métodos referentes a el registro y visualización de visitas, también, se comunica el “clienteController” con la clase “socket”, que se encuentra en el directorio “plugins”, para manejar los métodos de validación del QR leído en una zona y avisar que hubieron cambios, para que el socket pueda emitir al cliente más adelante.

• Plugins: Los directorios contienen los métodos utilizados para enviar emails a el usuario, para generar códigos QR [21] y además de establecer sockets de conexión.

• Mail_sender: Fue modificado para añadir ciertas características, con el fin de mejorar el entendimiento por parte del usuario, puesto que solo se enviaban emails con el id, código QR y fecha en el caso de que la solicitud fuera aceptada. Las modificaciones fueron para emails de: Permiso especial, Solicitud rechazada y Permiso anulado. Todos con cambios en la estructura y contenido del email según el caso. Cabe resaltar que se continúa empleando la librería Nodemailer, [22] y no fue necesario cambiar la librería porque, es fácil de usar y cumple con las necesidades de enviar los emails correctamente, bajo los parámetros modificados que se necesitan.

• Qr_Code: Se modificó la forma en generar tanto el id del código QR como la codificación del mismo con la información adicional. La información que se codifica fue modificada añadiendo campos nuevos para detallar y saber que permisos tiene un usuario, en que zonas y cuando, en la Figura 12 y Figura 13 muestran los dos casos de códigos que se generan.

Figura 12
Estructura de código QR para solicitud aceptada

Figura 13
Estructura de código QR para permiso especial

Se cambia la librería para generar los códigos QR “qr-image” por “qrcode”, la razón es que para “qrcode” hay un mayor seguimiento y desarrollo de actualizaciones, lo que permite un respaldo y fuente de información para posibles cambios futuros, este cambio no afecta en el proceso de generar códigos. Esta librería proporciona un método para corregir el nivel de error [23], teniendo en cuenta de que la información es poca para codificar y se desea realizar una lectura rápida, se eligió un nivel Medio “M”, con la finalidad de garantizar lectura rápida en el módulo scanner, puesto que con un nivel alto “H” tarda un poco más de tiempo en reconocer el código y se vuelve un poco tedioso a la hora de agilizar el proceso de lectura, además, garantizar de que si el usuario presenta el código digital o impreso sea posible su lectura, donde se corre el riesgo medio de pérdida de legibilidad en una superficie vs una pantalla donde no hay pérdida. En la Tabla 2, se observa los niveles y porcentaje de resistencia a error de lectura.

Tabla 2
Niveles y resistencia al error de qrcode [21]

Por último, el método “qrUpload” fue eliminado, puesto que los códigos se estaban almacenando y muchos nunca se estaban usando, por lo que al momento de que el usuario enviaba la solicitud, el código se generaba sin que el administrador aceptara la solicitud de ingreso, así que se almacenaba en el servicio AWS S3, lo que resulta totalmente innecesario, porque es información que ya existe en la base de datos lo que causa redundancia, más consumo de recursos y por ende más tiempo de ejecución. Además, cabe resaltar que, al momento de enviar un email con el código, este queda almacenado en el correo electrónico del usuario y de la administración de la granja.

Socketio: Se agregó este directorio o capa para establecer websockets [24], esta herramienta es necesaria para establecer un canal de transferencia de datos bidireccional entre el cliente y el servidor, puesto que para realizar la sección de visitas es importante mantener un intercambio de datos en tiempo real, sobre lo que ocurre en cada una de las zonas al momento que ingresa un usuario, para que dicho evento se refleje en el mismo instante. La forma de implementar los WebSockets de manera eficiente se hará utilizando la librería Socket.io [24], además, “Socket.IO permite la comunicación en tiempo real, bidireccional y basada en eventos. Funciona en todas las plataformas, navegadores o dispositivos, centrándose igualmente en la confiabilidad y la velocidad” [25], es por ello que se decide utilizar esta librería. En primera instancia fue necesario hacer unos cambios en la configuración del servidor, por lo que Express directamente no funciona con “socket.io”. Se importó la librería integrada de Node js “http” que permite levantar el servidor y usar los sockets, luego, se crea una variable “server” donde se define el servidor usando “http”, se parametriza con la constante “app” de Express, puesto que Express está basado en “http”, posteriormente, se reemplaza app por “server”, donde se llama a la función “listen” y finalmente, requerimos el archivo donde se va a inicializar el socket. Se puede observar la configuración en la Figura 14.

Figura 14
Configuración del servidor Express para el uso de Socket.io

Se crea la clase “socket.js” y se inicializa el socket de conexión donde llamara funciones con eventos que se estarán escuchando y emitiendo según el caso, posteriormente, se debe exportar para su uso en las diferentes rutas de la API. Finalmente, Se crea un evento particular que no hace parte de “socket.io”, pero si hace parte de una dependencia propia de Node llamada events, esta será utilizada para eventos que se necesitan al interior de la clase, como: “newVisitRecord” que se emite cuando la función “sendNewVisit” es ejecutada, (recibe como parámetro las visitas nuevas) por el controlador “clientController”, quien a su vez fue ejecutado mediante la ruta de la API que usa el módulo QR, para enviar nuevas visitas al momento de ser validado un ingreso. Cuando esto ocurre se puede emitir el evento “getNewVisit”, que se dispara por el socket y que envía las nuevas visitas al cliente, que por supuesto, estará escuchando dicho evento. De esta manera, es que se logra generar un registro de visitas en tiempo real, donde se visualiza en todo momento en el Frontend.

Routes: Contiene todas las rutas del servidor de Express, las rutas o direccionamiento [26], por lo que a cada ruta se le asignó un método que deriva del protocolo HTTP y que define el tipo de petición a resolver, se generaron nuevas rutas y se hicieron cambios en el tipo de método, según la petición y la acción que el servidor debe cumplir para resolver las peticiones que recibe. Las rutas se manejan de la siguiente manera: http://URL_BASE/END_POINT, donde la URL_BASE será la URL del servidor en donde se encuentre desplegado o en su defecto, la ruta local y el END_POINT es el punto final, la URL o ruta específica de la API, que responde a una petición que el servidor atiende.

En la Figura 15 y Figura 16 se observa el siguiente proceso, Inicialmente el cliente carga el formulario con los datos de tipo usuario, obtenidos desde servidor, (Rojo), el usuario completa sus datos personales. A medida que interactúa con los componentes fecha y zonas, el servidor realiza las validaciones para encontrar las zonas disponibles según la fecha seleccionada, (Amarillo, para objeto de prueba el tope de confirmados por zona es igual a 5). Luego, el usuario presiona Enviar y espera la validación (Azul), donde el servidor pronuncia los nuevos confirmados en las zonas y vemos que la solicitud ha sido exitosa.

Figura 15
Envió de solicitud de ingreso a las zonas

Figura 16
Respuestas del servidor para comprobar disponibilidad y generar solicitud

Si un usuario intenta solicitar una visita para la misma fecha, se lanza un mensaje de validación (Rosado), como se observa en las Figura 16 y Figura 17.

Figura 17
Validación de error en generar solicitud

1) Etapa 2.1 Solicitudes Pendientes

El Administrador ingresa a la sección de solicitudes pendientes, donde inicialmente se renderiza la vista con los datos obtenidos desde el servidor, como se observa en la Figura 18 y Figura 19 (Azul).

Figura 18
Solicitudes pendiente

Figura 19
Respuesta del servidor con las solicitudes pendientes

Aceptar solicitud: El administrador selecciona las zonas que va a autorizar, redacta una observación y luego presiona “Aceptar”. Podemos observar el comportamiento y resultado en las Figura 20 y Figura 21, donde las que no fueron seleccionadas, automáticamente quedan denegadas (Verde). Nuevamente se obtienen las solicitudes pendientes restantes (Azul).

El usuario recibe un correo electrónico con el código QR de autenticación y la información clara del uso del mismo, donde especifican las zonas permitidas y la fecha única de validez y demás detalles de la visita (Verde), como se puede observar en las Figura 21 y Figura 22.

Figura 20
Aceptar solicitud con permisos de ingreso a zonas específicas

Figura 21
Respuesta del servidor en aceptar solicitud

Figura 21
Respuesta del servidor en aceptar solicitud

Permiso especial: El administrador selecciona las zonas que va a autorizar, redacta una observación y luego presiona “Especial”. Podemos observar el comportamiento y resultado en las Figura 23 y Figura 24, donde todas las zonas seleccionadas fueron autorizadas con un permiso especial (Gris). Nuevamente se obtienen las solicitudes pendientes restantes (Azul).

Figura 23
Permiso especial de acceso en zonas específicas

Figura 24
Respuesta del servidor para permiso especial

El usuario recibe un correo electrónico con el código QR de autenticación y la información clara del uso del mismo, donde especifican las zonas permitidas y que el tipo de permiso no tiene fecha de caducidad, hasta una nueva orden (Gris), como se puede observar en las Figura 24 y Figura 25.

Figura 25
Email con código de autenticación de usuario con permiso especial

Rechazar solicitud: El administrador deja una observación y presiona “Rechazar”, automáticamente se deniegan los permisos en todas las zonas, se liberan los cupos donde se había confirmado (Rojo) y luego se obtienen las solicitudes pendientes restantes (Azul). El proceso se observa en las Figura 26 y Figura 27.

Figura 26
Rechazo de solicitud de ingreso

Figura 27
Respuesta del servidor rechazo de solicitud

El usuario recibe un correo electrónico con detalles del rechazo de la solicitud (Rojo), se puede observar la respuesta en las Figura 27 y Figura 28.

Figura 28
Email de rechazo de solicitud

2) Etapa 2.2 Solicitudes aprobadas

En esta sección el administrador puede observar todas las solicitudes aceptadas y con permiso especial, tiene la posibilidad de anular los permisos, según sea necesario (Por motivos de seguridad en la granja). Procede a dejar una observación y presiona “Cancelar” (Rojo). Nuevamente se obtienen las solicitudes aprobadas restantes (Azul). Este proceso se refleja en las Figura 29 y Figura 30.

El usuario recibe un correo electrónico con la información detallada, sobre la anulación de los permisos que anteriormente teína (Rojo). En este caso un empleado. Se observa en las Figura 30 y Figura 31.

Figura 29
Solicitudes aprobadas

Figura 30
Respuesta del servidor para anular permisos en solicitudes aprobadas

Figura 31
Email de Anular permisos

El usuario se dirige a una zona de la granja y presenta el código QR de autenticación para ser validado, el módulo scanner decodifica el código, luego manda los datos al servidor especificando la zona de lectura y recibe una respuesta para autorizar o denegar el ingreso, esta prueba se realiza en 2 zonas, donde a cada una le corresponde una cámara, ambas conectadas a la misma Raspberry [27], pero ejecutando procesos independientes para la lectura. De igual forma, se establece un montaje básico de Leds, en donde se puede indicar una respuesta para el usuario, como se observa en las Figura 32 y Figura 33.

En la Figura 33. Se observa la respuesta del servidor cuando un usuario es autorizado en este caso con permiso especial, se registra la visita en la base de datos, con hora y fecha, se emite el evento para que el cliente web pueda escucharlo, además, retorna una respuesta de la petición que se hizo desde el cliente modulo scan ner, para autorizar el ingreso en la zona, se observa un mensaje por consola y se enciende un led de color verde (Figura 32), que indica que el usuario es autorizado en la zona Porcicultura.

Figura 32
Lectura y respuesta exitosa del módulo scanner QR en la zona Porcicultura

Figura 33
Respuesta del servidor validación de acceso exitoso y registro de visita en la zona Porcicultura

Figura 34
Lectura y respuesta de rechazo del módulo scanner QR en la zona Avicultura

En la Figura 35, se observa la respuesta del servidor cuando un usuario no es admitido y se le niega el acceso, retornando la respuesta al módulo scanner donde se le niega el ingreso, este proceso se visualiza por la consola y se enciende un led de color azul Figura 34, que indica que el usuario no está autorizado para la fecha en la zona de Avicultura.

Figura 35
Respuesta del servidor validación de acceso de rechazo en zona Avicultura por fecha no valida

Ahora un usuario con código de autenticación únicamente valido en la zona Avicultura, intenta ingresar a la respectiva zona y fecha, donde la respuesta es exitosa como se muestra en las Figura 36 y Figura 37. Se puede ver el mensaje por consola y se enciende el led verde donde se le indica que el acceso es autorizado.

Luego el mismo usuario intenta ingresar a la zona Porcicultura presentando el código QR, en este caso como el usuario solo tiene autorización en Avicultura, se muestra un mensaje por consola e igualmente se enciende el led azul indicando una respuesta negativa donde el usuario no está autorizado para la zona, evitando que se violen los permisos y que los usuarios no ingresen a zonas en las que no tienen autorización. Los resultados se muestran en las Figura 38 y Figura 39.

Figura 36
Lectura y respuesta exitosa de usuario que ingresa a la zona y fecha autorizada, Avicultura

Figura 37
Respuesta del servidor cuando un usuario con autorización es válido en la zona y fecha

Figura 38
Lectura y respuesta negativa de ingreso a usuario en cuya zona no tiene autorización, Porcicultura

Figura 39
Respuesta del servidor cuando un usuario intenta ingresar a una zona no autorizada

En las Figuras 40, 41, 42 y 43, se observa como posterior a la anulación de permisos (como se aprecia en la Figura 38), el usuario no pude ingresar de nuevo a las zonas, en este caso igualmente se valida en Porcicultura y Avicultura, donde ahora el mensaje por consola es negativo y así mismo se visualiza la respuesta en el montaje donde se enciende el led azul.

Figura 40
Lectura y respuesta negativa en zona Porcicultura de usuario con permisos anulados

Una vez que el administrador entra a la sección de visitas, puede seleccionar como filtrarlas (Rojo), se establece un socket con el servidor (Amarillo), como se observa en las Figura 44 y Figura 45, si por algún motivo sale de la sección de visitas, se desconecta del socket.

Figura 41
Respuesta del servidor cuando un usuario intenta ingresar a la zona Porcicultura y los permisos fueron anulados

Figura 42
Lectura y respuesta negativa en zona Avicultura de usuario con permisos anulados

Figura 43
Respuesta del servidor cuando un usuario intenta ingresar a la zona Avicultura y los permisos fueron anulados

Figura 44
Visualización de visitas en tiempo real

Figura 45
Respuesta del servidor para conexión del cliente y visualización de visitas

Cuando se escucha el evento que recibe las nuevas visitas, se renderiza el componente de la tabla, según la ruta o la información filtrada en ese momento, para una correcta actualización. En la Figura 46 se observa cómo se filtra por zona Porcicultura y se actualiza una nueva visita para esa misma zona.

La respuesta y emisión del evento se puede observar en la Figura 36 donde se realizó la acción desde la zona Porcicultura (id 2 en este caso). Al igual se puede filtrar por fechas anteriores, pero no se visualiza ningún cambio en el componente si ocurre una visita, para no alterar la vista donde el administrador realiza su consulta. En la Figura 47 y Figura 48 se observa el resultado en el cliente y el servidor respectivamente.

Figura 46
Visualización de visitas filtradas por zona en tiempo real

Figura 47
Visualización de visitas filtradas por fecha y zona

Figura 48
Respuesta del servidor con zona y fecha específica

Finalmente, se realiza la prueba en las dos zonas Avicultura y Porcicultura, con un usuario que tiene el acceso en ambas, en la Figura 49 se visualiza el registro en tiempo real.

Figura 49
Visualización de visitas en tiempo real para un usuario que ingresa en las zonas Avicultura y Porcicultura