Version: 1.0
Fecha: 23 de Mayo, 2026
Estado: NORMATIVO - Inventario de capacidades nuevas disponibles
Arquitecto: Carlos Alberto Torres Camargo
Inventario de las funcionalidades nuevas que llegan al ecosistema Centrica con stack-2026-05-23. Para cada feature: descripcion, estado de activacion en Centrica, beneficios y consideraciones para activarla.
Capacidad arquitectonica para aislar datos por tenant (cliente + compania + subsidiaria) en todas las capas: queries Hibernate, Mongo, Kafka, Async, Audit. Ver detalle completo en Migracion Multitenant F1-F5.
Estado en Centrica: entregado el codigo, flags false por defecto. Activacion controlada cuando la infra tenant este lista.
JpaPasswordEncryptionConverter)SimappeAdmin.DatabaseConfigV2.password se cifra automaticamente con @AttributeConverter al escribir y se descifra al leer. Algoritmo AES-256-GCM, IV aleatorio de 12 bytes por encrypt, auth tag 128 bits.
Estado en Centrica: activo. La key se genero durante el deploy (2026-05-23) y vive en .env del compose (DB_ENCRYPTION_KEY=<32 bytes base64>). El converter se inicializa al startup.
Beneficios:
enc:v1: se leen como plaintext sin requerir la key). Permite migracion gradual.Consideraciones:
INSERT/UPDATE a database_config_v2 fallan con SimappeException. Las lecturas de rows ya en plaintext siguen funcionando.database_config_v2 via API REST de SimappeAdmin reciben siempre plaintext (el converter desencripta antes de mapear al DTO). Cero impacto en esos consumidores.Hibernate ya no es responsable de crear/actualizar el schema del Admin. Flyway gestiona las migraciones SQL versionadas de db/migration del JAR.
Estado en Centrica: activo. Configuracion en simappe-admin-{dev,local,localhost}.yml:
spring:
flyway:
enabled: true
baseline-on-migrate: true
baseline-version: '3.8'
default-schema: admin
schemas: admin
validate-on-migrate: false
Beneficios:
baseline-on-migrate: true permite incorporar Flyway sobre un schema pre-existente sin reset.baseline-version: '3.8' define el punto de inicio (estado actual de la BD al momento del upgrade).validate-on-migrate: false es tolerante con divergencias minores entre el contenido del classpath y la BD (util en ambientes mixtos).Consideraciones:
flyway migrate automaticamente. Si una migracion falla, el servicio no arranca.V001__..., V002__...).Bloque completo de configuracion para emitir notificaciones email, SMS y WhatsApp desde SimappeClient. Consume eventos Kafka, agrupa en batches, aplica rate-limiting por canal.
Estado en Centrica: entregado el codigo y config, master switch simappe.notification.enabled=false por defecto. El cliente decide cuando activar.
Estructura del bloque:
simappe:
notification:
enabled: false # master switch
admin-send-url: http://simappe-admin/api/v1/notification/send-direct
batch:
email: { size: 50, pause-sec: 10 }
sms: { size: 10, pause-sec: 60 }
whatsapp:{ size: 5, pause-sec: 120 }
rate-limit:
email: { per-second: 5, per-minute: 30, per-hour: 500, per-day: 5000 }
sms: { per-second: 1, per-minute: 10, per-hour: 200, per-day: 2000 }
whatsapp: { per-second: 1, per-minute: 5, per-hour: 150, per-day: 1000 ,
base-delay-ms: 12000, jitter-min-ms: 2000, jitter-max-ms: 8000,
max-consecutive-fails: 3 }
kafka:
group-id: notification-send-group
topic: notification-send-events
partitions: 1
Beneficios:
Consideraciones:
| Property | Valor | Beneficio |
|---|---|---|
spring.main.lazy-initialization: true |
activo | Beans se inicializan on-demand. Mejora el cold start del container. |
spring.threads.virtual.enabled: true |
activo | Virtual threads (Project Loom) para concurrency liviana. Util en servicios web reactivos y consumidores Kafka de alto throughput. |
server.forward-headers-strategy: framework |
activo | Spring procesa correctamente X-Forwarded-For/X-Forwarded-Proto cuando hay reverse-proxy (gateway) delante. |
Estado en Centrica: activo en todos los servicios via .env por grupo de compose. Las 3 viven como env var inyectada al container.
spring:
cloud:
gateway:
default-filters:
- DedupeResponseHeader=Access-Control-Allow-Origin Access-Control-Allow-Credentials
server:
webflux:
globalcors:
cors-configurations:
'[/**]':
allowed-origins: ...
allowed-headers: ...
Estado en Centrica: entregado pero el CORS y allowed-origins/headers del cliente prevalecen sobre los defaults entregados (el cliente tiene sus propias propiedades de allowed-origins por ambiente).
Beneficio: DedupeResponseHeader evita headers duplicados cuando ambos el upstream y el gateway agregan CORS headers (caso comun con frontends Angular).
acks=allspring.kafka.producer.acks: all en SimappeGatewayServer. Garantia de entrega: el broker espera ack de TODAS las replicas antes de confirmar.
Beneficio: mejora durabilidad de los eventos audit y notificaciones, especialmente si el topic tiene replicas configuradas.
Consideracion: baja latencia de produccion levemente. En topics con una sola replica, el comportamiento es identico a acks=1.
OptionMenuDto.actionsSimappeModel 3.3.0 agrega:
Action DTOs para representar acciones disponibles por opcion de menu y por rol.OptionMenuDto.actions como campo nuevo en el DTO de menu.GET /menu-with-actions retorna el menu jerarquico + acciones aplicables segun el rol del usuario.Estado en Centrica: disponible. El frontend Angular puede consumir el nuevo endpoint para resolver acciones dinamicamente sin hardcodear permisos.
Beneficio: definicion centralizada de acciones por rol. Cambios de permisos no requieren rebuild del frontend.
SimappeModel 3.3.0 agrega AiQuotaDto (cuota por proveedor y tenant) y AiProviderConfigDto (con flag isDefault y mapa de capabilities).
Estado en Centrica: disponible como contrato. La feature de AI Client (Gemini) vive en SimappeShared y puede activarse en servicios consumidores.
SimappeShared ahora declara profile centrica en su pom.xml, permitiendo mvn deploy -P centrica al Nexus del cliente. Antes la libreria caia al perfil repsy por defecto.
Estado en Centrica: activo. La libreria 1.0.2 esta publicada en https://nexus.centricasoluciones.com/repository/centrica/com/catcsoft/simappe/SimappeShared/.
SimappeAdmin 4.5.4 incluye ShedLock para coordinar @Scheduled entre multiples replicas del Admin. Backend del lock: Redis.
Beneficio: soporte para escalado horizontal del Admin sin riesgo de doble ejecucion de jobs (notificaciones, limpieza de tokens, etc.).
Consideracion: requiere Redis disponible (ya esta en dev-network del cliente). La tabla shedlock se crea automaticamente al primer arranque.
SimappeClient 2.3.3 soporta Mongo per-tenant cuando se activa simappe.multitenant.mongo.enabled=true. Cada tenant tiene su propio MongoTemplate y BD aislada.
Estado en Centrica: entregado, desactivado por defecto. Activacion requiere configuracion de conexiones Mongo por tenant en database_config_v2.
SimappeClient 2.3.3 activa el @Filter("multitenantFilter") de Hibernate cuando simappe.multitenant.query-filter.enabled=true. Todas las queries sobre entidades tenant-aware aplican WHERE automatico por tenant.
Estado en Centrica: entregado, desactivado por defecto.
SimappeClient 2.3.3 se refactorizo para soportar Postgres y Oracle como motor de la BD del cliente. Centrica usa Oracle como motor de negocio (Nebula) y Postgres como template de Simappe. Este refactor permite que el mismo servicio Client opere contra ambos motores segun el cliente.
Estado en Centrica: activo. El servicio Client en nodo-01 se conecta a Postgres del template (simappe_template_structure) y Oracle para tenants productivos.
| Documento | Relacion |
|---|---|
| Migracion Multitenant F1-F5 | Modelo conceptual del que dependen varias features de esta lista |
| Estrategias Operativas | Como activar cada feature de forma controlada |
| Cambios por Repositorio | Mapeo de features a versiones de componentes |
| Version | Fecha | Autor | Descripcion |
|---|---|---|---|
| 1.0.0 | 2026-05-24 | Carlos Torres | Inventario de mejoras y nuevas features para stack-2026-05-23 |