VIVAit Tracker
| Producto: | VIVAit Call v5.1
VIVAit Suite |
|---|
Sumario
1 Introducción a VIVAit Tracker 5.1
Con la versión 5.1 de la plataforma VIVAit Call se ha lanzado un nuevo tracker: VIVAit Tracker, que supone una mejora sobre el producto anterior: Tracker WEB.
Los puntos claves del portal VIVAit Tracker son:
- • Adaptación para facilitar su uso en entornos de telefonía corporativa.
- • Permite seguir llamadas y escuchar/descargar grabaciones en caso de existir.
- • Integrado con entornos de texto (TBC y desarrollos futuros).
Volver arriba / Volver al índice
1.1 Arquitectura de VIVAit Tracker 5.1
Los bloque funcionales, servicios y elementos que componen la aplicación están divididos en dos capas principales:
- - Frontend
- Reside en un servidor web Apache.
- Se invoca desde un navegador mediante una URL del tipo https://host/ws/
- Reside en un servidor web Apache.
https://172.25.128.252/Tracker-Corporativo/
- Es la parte visual: HTML, CSS, JavaScript.
- No accede directamente a la base de datos; solo obtiene datos desde una API.
- Es la parte visual: HTML, CSS, JavaScript.
- - Backend / API REST
- Corre en un servidor web Tomcat.
- Expone la API en:
- Corre en un servidor web Tomcat.
https://172.25.128.252/Tracker-Rest/tracker/.
- Contiene la lógica que permite interactuar con la BBDD.
- Responde en JSON para que el frontend pueda ofrecérselo al navegador.
- Contiene la lógica que permite interactuar con la BBDD.
Diagrama funcional de la arquitectura de VIVAit Tracker 5.1
Volver arriba / Volver al índice
1.1.1 Flujo completo del ciclo de datos
Siguiendo el proceso se contemplan los siguientes pasos:
Paso 1 El usuario invca el frontend residente en Apache2 desde un navegador mediante la URL:
https://host/Vivait-Corporativo/
El navegador carga la página estática HTML servida por Apache2.
Una vez superada la fase de validación se muestra un formulario que permite al usuario parametrizar una consulta Paso 2 Al recibir los datos del formulario
El frontend (JavaScript) hace una petición a la API REST. 3. La API se conecta a la base de datos, ejecuta las consultas necesarias y devuelve la respuesta. 4. El frontend recibe el JSON y lo representa en pantalla. En ningún momento el navegador accede directamente a la base de datos; todo pasa por la API.
- - FRONT (navegador + página web)
- El usuario abre en su navegador e invoca una URL del tipo:
- El usuario abre en su navegador e invoca una URL del tipo:
https://host/ws/
- El navegador carga la página estática HTML servida por Apache. Una vez superada la fase de validación se muestra un formulario que permite al usuario parametrizar una consulta.
- La página del formulario hace una petición Fetct con método GET, por ejemplo:
GET https://172.25.128.252/Tracker-Corporativo/
- - WEB SERVICE Apache → Tomcat (parte del BACK pero “capa web”)
- Apache actúa como reverse proxy delante de Tomcat, escucha en los puertos :80 / :443. y redirige ciertas rutas (en nuestro caso /Tracker-Corporativo) a Tomcat, que está en localhost:8180.
- Apache actúa como reverse proxy delante de Tomcat, escucha en los puertos :80 / :443. y redirige ciertas rutas (en nuestro caso /Tracker-Corporativo) a Tomcat, que está en localhost:8180.
GET http://host/ws
- Apache lo reenvía internamente a Tomcat
- Apache lo reenvía internamente a Tomcat
http://localhost:8180/Tracker-Corporativo/
- - BACKEND real: Tomcat + Java + MySQL
- En Tomcat hay desplegada una aplicación Java (Tracker-Rest) que:
- - Recibe la petición /ws.
- - Con Java (servlet) abre una conexión JDBC a MySQL (DBHIST).
- - Lanza consultas sobre las tablas DAT_LLAMADAS y DAT_SEGMENTOS de BDHIST.
- - Monta una respuesta JSON (fichero comprimido) y la devuelve como resultado Fesch con método PUSH al navegador (Tomcat → Apache → navegador).
- En Tomcat hay desplegada una aplicación Java (Tracker-Rest) que:
POST https://172.25.128.252/Tracker-Rest/tracker/lista
Se muestra a continuación un esquema funcional de esta arquitectura:
Volver arriba / Volver al índice
1.2 Seguridad de VIVAit Tracker 5.1
3. Seguridad del sistema El acceso está controlado mediante validación de tokens: 1. Autenticación inicial o El usuario se valida a través de un daemon llamado sercen. o Sercen genera un token firmado que identifica al usuario. 2. Validación interna de permisos o Una vez que el frontend tiene el token, cada petición pasa por: tracker-rest/validarToken o Ahí se comprueba que: El token es válido. El usuario tiene permisos para el recurso que está intentando usar. No se ejecuta ninguna acción de negocio si el token no es validado primero. 4. Apache y Tomcat mediante proxy inverso Apache actúa como punto de entrada único: • El usuario solo ve URLs de Apache. • Las peticiones que requieren lógica del backend se redirigen internamente a Tomcat. • Esto se consigue mediante proxy inverso, por ejemplo: o /Tracker-Hugo → servido por Apache. o /Tracker-Rest → Apache las pasa a Tomcat sin que el cliente lo note.
Volver arriba / Volver al índice
2 Descripción de la interfaz de VIVAit Tracker 5.1
La tabla que se muestra a continuación detalla la jerarquía de menús y submenús del portal de administración, e incluye enlaces directos a las respectivas secciones:
Volver arriba / Volver al índice
2.1 Acceso a VIVAit Tracker 5.1
La tabla que se muestra a continuación detalla la jerarquía de menús y submenús del portal de administración, e incluye enlaces directos a las respectivas secciones:
Volver arriba / Volver al índice
3 Utilización de VIVAit Tracker
La tabla que se muestra a continuación detalla la jerarquía de menús y submenús del portal de administración, e incluye enlaces directos a las respectivas secciones:
Volver arriba / Volver al índice
FIN
FIN
FIN
FIN
FIN
FIN
FIN
FIN
FIN
FIN
FIN
