ADR-0001 · Backend NestJS como middleware ante SAP Service Layer¶

Estado: aceptado
Decisores: equipo OMS
Fecha de la decisión: no registrada (ADR retroactivo, decisión de origen del proyecto)

Contexto y problema¶

El OMS reemplaza el flujo de ventas sobre el cliente SAP B1 con un dashboard web propio. SAP expone el Service Layer (OData/HTTPS), así que técnicamente el frontend podría consumirlo directo. Pero el Service Layer autentica por sesión de base de datos, no distingue roles de negocio del OMS (vendedor, cajero, logística), y exponerlo al browser implica publicar el ERP completo a la red. Además hay funcionalidad que SAP no cubre: búsqueda instantánea, pagos electrónicos, notificaciones, impresión.

Opciones consideradas¶

Backend propio (NestJS) como middleware entre el frontend y SAP — elegida
Frontend consumiendo el Service Layer directamente
Integración a nivel de base de datos / DI-API de SAP

Decisión¶

Todo el tráfico del OMS pasa por un backend NestJS que autentica con SSO/JWT propio (roles, salesPersonCode, sucursal), traduce operaciones de negocio a llamadas Service Layer a través de un cliente único (common/sap-client/), y orquesta las integraciones no-SAP. Si mañana alguien pregunta "¿por qué no pegarle directo al Service Layer?": porque el control de acceso, el caching, la observabilidad y las integraciones necesitan un punto central que SAP no ofrece, y exponer el ERP al browser es inaceptable en seguridad.

Consecuencias¶

Positivas¶

SAP nunca queda expuesto fuera de la red interna; el OMS decide qué se puede hacer y quién.
Punto único para caché (Redis), correlación de errores y sesiones SAP.
Las integraciones (Algolia, Bancard, Firebase, PrintNode) viven en un solo lugar.

Negativas / deuda asumida¶

Doble salto de red: cada operación paga la latencia backend + Service Layer.
Hay que mantener DTOs e interfaces espejo de las entidades SAP.
La gestión de sesiones Service Layer (expiración, renovación por usuario) es responsabilidad nuestra.