Diferencia entre revisiones de «VIVAit Tracker»

Revisión del 12:12 22 dic 2025

Producto:	VIVAit Call v5.1 VIVAit Suite

Sumario

1 Introducción a VIVAit Tracker 5.1
- 1.1 Arquitectura de VIVAit Tracker 5.1
  - 1.1.1 Flujo completo del ciclo de datos
- 1.2 Seguridad de VIVAit Tracker 5.1
2 Descripción de la interfaz de VIVAit Tracker 5.1
3 Utilización de VIVAit Tracker

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 más enfocado al mundo Call Center.
Los puntos claves del nuevo portal VIVAit Tracker dirigido al entorno corporativo 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/

       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.

- Backend / API REST

Corre en un servidor web Tomcat.

Expone la API en:

       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.

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 invoca el frontend residente en Apache desde un navegador, usando javascript, mediante la URL del tipo:

       https://host/Traker_Corporativo/

El navegador carga la página web servida por Apache.

Paso 2 Una vez superada la fase de validación se muestra un formulario que permite al usuario definir los parámetros de una consulta.

La página del formulario inicia una transacción para efectuar una solicitud HTTP POST al endpoint correspondiente, por ejemplo:

               https://172.25.128.252/Tracker_Corporativo/

siendo la carga util de esta solicitud los datos del formulario rellenado por el usuario:

               {fechaInicio: "", fechaFin: "", horaInicio: "", horaFin: "", listaExtensiones: [], listaGrupos: [],…}

Paso 3 Al recibir los datos del formulario el frontend hace una petición a la API REST de Tomcat.

Paso 4 La API se conecta a la base de datos, ejecuta las consultas necesarias y devuelve la respuesta.

Paso 5 El frontend recibe el JSON con los datos de la consulta en la respuesta:

               POST https://172.25.128.252/Tracker-Rest/tracker/lista

El navegador lo representa en pantalla. En ningún momento el navegador accede directamente a la base de datos; todo pasa por la API.

Volver arriba / Volver al índice

1.2 Seguridad de VIVAit Tracker 5.1

El acceso está controlado mediante validación de tokens.

Paso 1 Autenticación inicial

• Al introducir sus credenciales el usuario se valida a través del servicio de autenticación sercen

               https://172.25.128.252/sercen/postautenticar1

• Sercen genera un token firmado que identifica la sesión del usuario.

Paso 2 Validación interna de permisos

• Una vez que el frontend tiene el token, cada petición pasa por una validación de la API del tomcat:

               https://172.25.128.252/Tracker-Rest/tracker/verificarToken

En la misma se comprueba que:

- El token es válido.

- El usuario tiene permisos para el recurso que está intentando usar.

Es necesario que el usuario tenga acceso a la aplicación Grabador, ver Usuarios.

• No se ejecuta ninguna acción si el token no es validado primero.

Paso 3 Proxy inverso apache-tomcat

• 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:

/Tracker_Corporativo → servido por apache

               https://172.25.128.252/Tracker_Corporativo/

/Tracker-Rest → Apache las pasa a Tomcat de forma transparente para el usuario

               https://172.25.128.252/Tracker-Rest/tracker/extensiones

• El navegador utilizado por el usuario nunca ve a tomcat.

Volver arriba / Volver al índice