Diferencia entre revisiones de «VIVAit Tracker»

De VIVAitwiki
Ir a la navegaciónIr a la búsqueda
 
(No se muestran 20 ediciones intermedias del mismo usuario)
Línea 8: Línea 8:
 
== Introducción a VIVAit Tracker 5.1 ==
 
== Introducción a VIVAit Tracker 5.1 ==
 
<br><br>
 
<br><br>
<big>Con la versión 5.1 de la plataforma '''''VIVA'''''it Call se ha lanzado un nuevo tracker: ''VIVAit Tracker'', que supone una mejora sobre el producto anterior: ''Tracker WEB''.
+
<big>Con la versión 5.1 de la plataforma '''''VIVA'''''it Call se ha lanzado un nuevo tracker: ''VIVAit Tracker'', que supone una mejora sobre el producto anterior: ''Tracker WEB''.<br>
 +
Los puntos claves del '''''portal VIVAit Tracker''''' son:<br>
 +
: • Adaptación para facilitar su uso en entornos de telefonía corporativa.<br>
 +
: • Permite seguir llamadas y escuchar/descargar grabaciones en caso de existir.<br>
 +
: • Integrado con entornos de texto (TBC y desarrollos futuros).
 +
<br><br>
 +
[[#Introducción a VIVAit Tracker 5.1 | Volver arriba]] / [http://vivait-wiki.mdnova.local/wiki/vivait/index.php/VIVAit_Tracker Volver al índice]
 +
<br><br>
 +
 
 +
=== Arquitectura de VIVAit Tracker 5.1 ===
 +
<br><br>
 +
Los bloque funcionales, servicios y elementos que componen la aplicación están divididos en dos capas principales:
 +
<br><br>
 +
: - '''Frontend'''<br>
 +
::Reside en un servidor web Apache.<br>
 +
::Se invoca desde un navegador mediante una URL del tipo https://host/ws/<br>
 +
        https://172.25.128.252/Tracker-Corporativo/
 +
::Es la parte visual: HTML, CSS, JavaScript.<br>
 +
::No accede directamente a la base de datos; solo obtiene datos desde una API.
 +
<br><br>
 +
: - '''Backend / API REST'''<br>
 +
::Corre en un servidor web Tomcat.<br>
 +
::Expone la API en: <br>
 +
        https://172.25.128.252/Tracker-Rest/tracker/.
 +
::Contiene la lógica que permite interactuar con la BBDD.<br>
 +
::Responde en JSON para que el frontend pueda ofrecérselo al navegador.<br>
 +
<br><br>
 +
Diagrama funcional de la arquitectura de VIVAit Tracker 5.1
 +
<br><br>
 +
[[File:arquitectura_tracker_V5.1.png|1500px|center|thumb]]
 +
<br><br>
 +
[[#Introducción a VIVAit Tracker 5.1 | Volver arriba]] / [http://vivait-wiki.mdnova.local/wiki/vivait/index.php/VIVAit_Tracker Volver al índice]
 +
<br><br>
 +
 
 +
==== Flujo completo del ciclo de datos ====
 +
<br><br>
 +
Siguiendo el proceso se contemplan los siguientes pasos:<br>
 +
'''Paso 1''' El usuario invca el frontend residente en Apache2 desde un navegador mediante la URL:<br>
 +
        https://host/Vivait-Corporativo/
 +
El navegador carga la página estática HTML servida por Apache2.<br>
 +
 
 +
Una vez superada la fase de [[#Seguridad de VIVAit Tracker 5.1 |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.
 +
 
  
El '''''portal de administración de la plataforma ''VIVA''it ''''' proporciona a los administradores un interfaz gráfico basado en web, para la gestión y configuración de los productos '''''VIVA'''''it Call y '''''VIVA'''''it  Suite.
 
  
  
: • Mejoras para uso de VIVAit-Tracker en entornos de telefonía corporativa.<br>
+
: - '''FRONT''' (navegador + página web)<br>
: • Permite seguir llamadas y escuchar/descargar grabaciones en caso de existir.<br>
+
::El usuario abre en su navegador e invoca una URL del tipo:<br>
: • Integrado con entornos de texto (TBC y próximos).<br>
+
          https://host/ws/
 +
::El navegador carga la página estática HTML servida por ''Apache''. Una vez superada la fase de [[#Seguridad de VIVAit Tracker 5.1 |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:<br>
 +
          GET https://172.25.128.252/Tracker-Corporativo/
 +
<br><br>
 +
: - '''WEB SERVICE''' Apache → Tomcat (parte del BACK pero “capa web”)<br>
 +
::''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.<br>
 +
          GET http://host/ws
 +
::Apache lo reenvía internamente a Tomcat<br>
 +
          http://localhost:8180/Tracker-Corporativo/
 +
<br><br>
 +
: - '''BACKEND''' real: Tomcat + Java + MySQL<br>
 +
::En Tomcat hay desplegada una aplicación Java (Tracker-Rest) que:<br>
 +
:: - Recibe la petición /ws.<br>
 +
:: - Con Java (servlet) abre una conexión JDBC a MySQL (DBHIST).<br>
 +
:: - Lanza consultas sobre las tablas DAT_LLAMADAS y DAT_SEGMENTOS de BDHIST.<br>
 +
:: - Monta una respuesta JSON (fichero comprimido) y la devuelve como resultado Fesch con método PUSH al navegador (Tomcat → Apache → navegador).
 +
            POST https://172.25.128.252/Tracker-Rest/tracker/lista
 +
<br><br>
 +
Se muestra a continuación un esquema funcional de esta arquitectura:
 +
<br><br>
 +
 
 +
<br><br>
 +
[[#Introducción a VIVAit Tracker 5.1 | Volver arriba]] / [http://vivait-wiki.mdnova.local/wiki/vivait/index.php/VIVAit_Tracker Volver al índice]
 +
<br><br>
 +
 
 +
=== 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.
  
  

Revisión actual del 15:29 3 dic 2025

Producto: VIVAit Call v5.1

VIVAit Suite



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/
       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

Arquitectura tracker V5.1.png



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:
          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.
          GET http://host/ws
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).
           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