Arquitectura y seguridad
Tres piezas, dentro de su red.
Escrito para quien va a aprobar la entrada de la plataforma en el entorno — TI, DBA y seguridad.
Portal
La aplicación web donde se registra, valida y programa. No ejecuta procesos.
Ejecutor
Servicio en contenedor que sondea la cola y ejecuta las rutinas. Puede haber varios, en máquinas distintas. (En el código y en los registros aparece como Worker — es el mismo componente.)
HUB de orquestación
Guarda definiciones, permisos, la cola y el historial. Es el único canal entre portal y ejecutor — y corre sobre la base de datos que usted elija.
El HUB
Por qué el componente central es una base de datos.
Es una decisión de arquitectura, no un ahorro. Vale la pena explicarlo, porque quien evalúa suele esperar un servicio propio en su lugar.
Nada más que operar
Sin cola de mensajes que instalar, monitorizar, actualizar y proteger. En la operación de una empresa mediana eso no es ahorro de infraestructura — es ahorro de personas.
Consistencia transaccional
La cola y el dato viven en la misma transacción. Un broker traería doble escritura y el problema de la entrega exactamente-una-vez; este diseño no lo tiene.
Recuperar es una consulta
Una ejecución interrumpida por una caída se encuentra y se reencola leyendo una tabla — no reprocesando un registro de eventos.
Su DBA ya sabe operarlo
Copia de seguridad, monitorización, réplica y alta disponibilidad del HUB son los procedimientos que su casa ya tiene, en la herramienta que ya usa.
Dónde corre el HUB
En su servidor, o en una nube gestionada. Usted decide.
Es la misma instalación — cambia una línea de configuración. La elección tiene consecuencias, así que están escritas aquí y no en la letra pequeña del contrato.
HUB en su servidor
El dato y el control quedan enteramente dentro de su red.
Ganha: funciona sin nada de internet, y nada sale de casa.
Assume: la alta disponibilidad del HUB es la que usted monte.
HUB en nube gestionada
Azure SQL, Amazon RDS, Cloud SQL u Oracle Autonomous — los mismos proveedores, por cadena de conexión.
Ganha: la alta disponibilidad del HUB pasa a ser la de su proveedor.
Assume: los ejecutores necesitan enlace hasta él — deja de funcionar sin conexión.
Los ejecutores siguen donde está el trabajo: junto al ERP heredado, al Firebird de la sucursal, al recurso compartido de archivos. Es el HUB el que puede subir a la nube — no la ejecución.
Seguridad
Dónde viven los secretos.
Credenciales cifradas
Las contraseñas de base de datos y de SMTP se cifran con las claves de protección de la instalación. Ninguna pantalla las muestra una vez guardadas, y nunca aparecen enteras en un registro.
Inyección sin contraseñas en el código
El script recibe conexión y credencial como variables de entorno. Nada de contraseñas en texto dentro del proceso — y lo que la etapa recibe es una declaración explícita, comprobada al guardar.
Autorización por capas
5 perfiles de usuario, vínculos por proceso, etiquetas restringidas y modo oculto. La comprobación es en el servidor, en cada acción — esconder el botón nunca se consideró protección.
Importación controlada
Importar un paquete hace entrar código que el ejecutor ejecutará. Por eso es un elemento cada vez, con límites de tamaño y rechazo de contenido malicioso — nunca por lotes.
Operación
Qué corre solo, y dónde.
| Rutina | Frecuencia | Dónde corre |
|---|---|---|
| Ejecución de la cola | cada 5 s | todos los ejecutores |
| Disparo por programación | cada 30 s | todos los ejecutores (una sola vez) |
| Señal de vida | cada 1 min | todos los ejecutores |
| Limpieza de datos de ejecución | cada 1 h | todos los ejecutores |
| Purga de historial y métricas | medianoche local | solo el ejecutor principal |
| Vaciado de la papelera | cada 6 h | solo el ejecutor principal |
Continuidad
Un portal caído no detiene sus rutinas.
Es consecuencia directa de la arquitectura: la cola vive en la base de datos y quien ejecuta son los ejecutores, procesos separados. Si el portal se cae a las 3 de la madrugada, las programaciones siguen disparando y la cola sigue consumiéndose — usted pierde la pantalla, no la operación.
Ejecutores
Varios sobre la misma base, de forma nativa. La disputa por la cola se resuelve en la propia base, así que un ejecutor puede entrar y salir sin coordinar nada — y la ejecución interrumpida por una caída se recupera cuando vuelve.
Nativo — nada que configurar más allá de levantar otro ejecutor.
Base de datos
Es la suya. Use la alta disponibilidad que ya tiene — clúster, réplica o servicio gestionado. La plataforma no se mete en el asunto.
Su estándar — 5 bases soportadas como base de control.
Portal
Una instancia por instalación es la topología probada. La continuidad viene de la infraestructura que usted ya opera: un clúster de hipervisor u orquestador de contenedores reinicia el portal en otro nodo, como hace con cualquier otra aplicación suya.
Su infraestructura — Proxmox, Hyper-V, VMware, Kubernetes.
Lo que no existe es el escalado automático: la plataforma no levanta ni tumba ejecutores por sí sola según la carga. Cuántos ejecutores corren es decisión suya, y el coste no cambia con el volumen.