Saltar a contenido

Arquitectura#

Empowerment Center 8 es una aplicación web: los usuarios trabajan con un navegador y todo se calcula en el servidor. Esta página describe las piezas que forman una instalación, qué guarda cada una y cómo viaja una petición, para que pueda decidir dónde instalar cada cosa y qué proteger.

Las piezas#

Qué se instala Instalación con Docker Compose: solo el frontal nginx publica un puerto y recibe el tráfico HTTPS; reparte las rutas del backend, que usa la BD propia con PostGIS y, por perfil, Chromium y Valhalla, y sale a las BD de los clientes, al SMTP de la organización y al proveedor de identidad. DOCKER COMPOSE (RED INTERNA) HTTPS /api/ · /embed/ · /.well-known/… · SSO DevTools abre el documento Navegadores, aplicaciones anfitrionas, clientes de la API y del MCP ÚNICO PUERTO PUBLICADO Frontal (nginx) :8080 la aplicación web y el proxy Backend (Spring Boot) :8080 Chromium :9222 perfil render sin publicar BD propia PostgreSQL 18 + PostGIS volumen db-data Valhalla :8002 perfil routing volumen routing-data BD de los clientes Oracle, SQL Server, PostgreSQL SMTP de la organización Proveedor de identidad OIDC/SAML TLS en el frontal o en un proxy delante Entrada pública Red interna Sale de la instalación Opcional, por perfil
Qué se instala Instalación con Docker Compose: solo el frontal nginx publica un puerto y recibe el tráfico HTTPS; reparte las rutas del backend, que usa la BD propia con PostGIS y, por perfil, Chromium y Valhalla, y sale a las BD de los clientes, al SMTP de la organización y al proveedor de identidad. DOCKER COMPOSE (RED INTERNA) HTTPS /api/ · /embed/ · /.well-known/… · SSO DevTools abre el documento Navegadores, aplicaciones anfitrionas, clientes de la API y del MCP ÚNICO PUERTO PUBLICADO Frontal (nginx) :8080 la aplicación web y el proxy Backend (Spring Boot) :8080 Chromium :9222 perfil render sin publicar BD propia PostgreSQL 18 + PostGIS volumen db-data Valhalla :8002 perfil routing volumen routing-data BD de los clientes Oracle, SQL Server, PostgreSQL SMTP de la organización Proveedor de identidad OIDC/SAML TLS en el frontal o en un proxy delante Entrada pública Red interna Sale de la instalación Opcional, por perfil
Qué se instala Ver a tamaño completo Ver a tamaño completo

Una instalación tiene tres piezas obligatorias (el frontal, el backend y la BD propia), se conecta a las bases de datos de los clientes y, si se quiere, a otros servicios de la organización.

Pieza Qué es Qué guarda Obligatoria
Frontal Un nginx sin privilegios que sirve la aplicación web y los manuales (en /ayuda/) y hace de proxy inverso hacia el backend. Es lo único que se publica. Nada: solo los ficheros de la aplicación web y de los manuales, que vienen en su imagen. Sí
Backend El servidor de ECenter, una aplicación Java 25. Atiende la API, calcula cubos, gráficos, mapas, formularios y listas, lanza las tareas programadas, envía el correo y lleva la auditoría. En memoria, los trabajos en curso y sus resultados (los cubos calculados, por ejemplo). En disco, solo los ficheros temporales de las subidas de datos externos y de capas geográficas. Sí
BD propia PostgreSQL 18 con las extensiones PostGIS y pg_trgm. Todo lo de ECenter: metadata, usuarios, roles y privilegios, libros y sus copias, listas, agrupaciones, publicaciones y plantillas del portal, capas geográficas, tareas programadas y su historial, suscripciones y alertas, credenciales de servicio (con sus secretos cifrados), sesiones, auditoría, actividad de la consola y licencia. Sí
BD de los clientes Las bases de datos que se analizan: Oracle, SQL Server o PostgreSQL. Se dan de alta como conexiones desde la aplicación. Los datos de negocio, que ECenter consulta. ECenter crea en ellas tablas de trabajo (listas, agrupaciones, valores de condiciones largas y datos externos) en el esquema que se le indique. Al menos una para tener algo que analizar
Servidor de correo (SMTP) El de la organización. Nada en ECenter. No: sin él no sale ningún correo (suscripciones, alertas de datos, avisos de la operación y de la planificación) y lo demás funciona.
Navegador sin interfaz Un Chromium en un contenedor aparte. Nada: cada dibujo empieza en limpio. No: sin él no se ofrecen el PDF de gráficos, mapas y páginas del portal ni la imagen del documento en el cuerpo del correo.
Motor de rutas Valhalla (autoalojado) u OpenRouteService. Valhalla guarda su grafo de carreteras en su propio volumen. No: sin él solo hay isócronas de distancia radial (círculos) y no hay matriz de tiempos y distancias.
Proveedor de identidad El de la organización, por OIDC o SAML 2.0, y opcionalmente SCIM. Nada en ECenter, salvo el enlace de cada usuario con su cuenta. No: sin él, los usuarios entran con login y contraseña.
Mapa base Un proveedor de teselas o de estilos para el fondo de los mapas, externo o autoalojado. Nada en ECenter. No: sin él las capas se dibujan sobre un fondo liso.

Importante

La BD propia es lo único que hay que copiar para recuperar una instalación, junto con la clave de los secretos (ECENTER_SECRETS_KEY) y la configuración. El frontal y el backend no guardan nada que no se pueda reconstruir desde sus imágenes. Véase Copias de seguridad y restauración.

Un mismo origen#

El navegador solo habla con el frontal. El frontal sirve la aplicación web y manda al backend, sin tocarlas, las rutas que son suyas:

Ruta Qué es
/api/ La API de la aplicación, la API de consulta, el servidor MCP, SCIM y el intercambio del metadata.
/embed/ La página que se incrusta en otras aplicaciones y el modo de impresión que usa el navegador sin interfaz.
/.well-known/oauth-protected-resource/ Los metadatos del servidor MCP para los clientes que entran con OAuth.
/oauth2/, /login/oauth2/, /saml2/, /login/saml2/ La ida al proveedor de identidad y la vuelta (OIDC y SAML).

/ayuda/ son los manuales de usuario y de administración, que sirve el propio frontal sin pasar por el backend (véase Los manuales en /ayuda/). Todo lo demás es la aplicación web: un fichero si existe y, si no, su página principal, que resuelve la ruta en el navegador.

Por eso ECenter va en la raíz de su propio nombre (https://ecenter.example.org/) y no bajo una ruta de otro sitio (https://intranet.example.org/ecenter/ no está previsto). La sesión es una cookie del propio sitio, la API y la aplicación comparten origen y el navegador no necesita permisos entre orígenes.

Cómo viaja una petición#

Cómo viaja una petición Secuencia de una consulta: el navegador pide la aplicación al frontal, que reenvía las rutas /api/ al backend; el backend comprueba sesión, licencia y privilegios en la BD propia, envía un trabajo, consulta la BD del cliente, audita y sirve el resultado por ventanas desde su memoria. GET / (la aplicación web) index.html y ficheros con huella (caché de un año) /api/… (cookie SESSION) la misma petición + X-Forwarded-* sesión, licencia y privilegios envía un trabajo a su cola consulta (pool de la conexión) filas auditoría de la consulta sigue el trabajo y lee el resultado por ventanas resultado en la memoria del backend Navegador Frontal (nginx) Backend BD propia BD del cliente Los trabajos y sus resultados viven en la memoria de la instancia que los calcula.
Cómo viaja una petición Secuencia de una consulta: el navegador pide la aplicación al frontal, que reenvía las rutas /api/ al backend; el backend comprueba sesión, licencia y privilegios en la BD propia, envía un trabajo, consulta la BD del cliente, audita y sirve el resultado por ventanas desde su memoria. GET / (la aplicación web) index.html y ficheros con huella (caché de un año) /api/… (cookie SESSION) la misma petición + X-Forwarded-* sesión, licencia y privilegios envía un trabajo a su cola consulta (pool de la conexión) filas auditoría de la consulta sigue el trabajo y lee el resultado por ventanas resultado en la memoria del backend Navegador Frontal (nginx) Backend BD propia BD del cliente Los trabajos y sus resultados viven en la memoria de la instancia que los calcula.
Cómo viaja una petición Ver a tamaño completo Ver a tamaño completo
  1. El usuario abre https://ecenter.example.org/. El frontal le sirve la aplicación web. Los ficheros con huella se guardan en el navegador un año; la página principal se vuelve a comprobar en cada visita, así que tras una actualización se carga la versión nueva.
  2. La aplicación pide sus datos a /api/… en el mismo origen. El frontal los pasa al backend con las cabeceras X-Forwarded-* que dicen el esquema, el nombre y la dirección del cliente originales.
  3. El backend comprueba la sesión (en la BD propia), la licencia y los privilegios del usuario.
  4. Si la petición pide un cálculo que puede tardar (un cubo, un gráfico, una lista), el backend lo envía como trabajo a una cola. El trabajo consulta la BD del cliente con las sesiones del pool de esa conexión y deja el resultado en la memoria del backend.
  5. La aplicación sigue el trabajo y, cuando termina, lee el resultado por ventanas. Lo que cada consulta lee de la BD del cliente queda en la auditoría, en la BD propia.

Las tareas programadas, las suscripciones y las alertas de datos siguen el mismo camino desde el propio backend, en nombre de quien las creó.

Una instancia, y varias si hace falta#

Lo previsto es una instancia del backend. Las sesiones, la configuración y todo lo compartido están en la BD propia, pero los trabajos y sus resultados viven en la memoria de la instancia que los calcula.

Con varias instancias detrás de un balanceador:

  • Las peticiones de un mismo cliente tienen que ir siempre a la misma instancia (afinidad). Si no, una instancia no encuentra el trabajo que lanzó otra. La clave de la afinidad y un ejemplo de configuración están en El proxy inverso y TLS.
  • Cada instancia lleva su propio nombre (ECENTER_INSTANCE_NAME) y, si se usa, su propio navegador sin interfaz.
  • Las tareas programadas, las alertas operativas y las purgas se reparten solas entre las instancias con bloqueos en la BD propia: no se ejecutan dos veces.
  • Un cambio en una conexión (su URL, su usuario o su contraseña) se nota en todas las instancias.
  • Revocar una credencial de servicio solo corta en el momento las consultas que están en curso en la instancia que procesa el cambio. Las que corren en otra terminan solas o al llegar a su tiempo máximo. Las peticiones nuevas con esa credencial se rechazan en todas.
  • Para actualizar de versión hay que parar todas las instancias antes de arrancar la primera nueva (véase Actualizar de versión).

Qué sale de la instalación#

Conviene saber qué conexiones abre cada pieza para preparar el cortafuegos:

Origen Destino Para qué
Navegadores, aplicaciones anfitrionas, clientes de la API y del MCP Frontal (HTTPS) Todo el uso de ECenter.
Frontal Backend Las rutas de la tabla de arriba.
Backend BD propia Todo lo que guarda ECenter.
Backend BD de cada cliente Consultas, tablas de trabajo y los cambios de los formularios.
Backend Servidor SMTP El correo.
Backend Proveedor de identidad El inicio de sesión único y, con el MCP por OAuth, las claves de sus tokens.
Backend Navegador sin interfaz (DevTools) Pedirle que dibuje un documento.
Navegador sin interfaz Frontal Abrir el documento que dibuja, con sus datos.
Navegador sin interfaz y navegadores de los usuarios Mapa base El fondo de los mapas.
Backend Motor de rutas Isócronas y matrices de tiempos y distancias.
Proveedor de identidad Frontal SCIM, si da de alta los usuarios.

Los puertos de cada pieza están en Requisitos.

Véase también#