Digou ya tiene Dynatrace para monitoreo técnico. El gap real está en otro nivel: órdenes que SAP ERP rechaza con HTTP 200, precios inconsistentes, clientes bloqueados por crédito sin notificación. Esos errores son invisibles para cualquier APM.
Distinción clave: un error de integración ERP suele llegar con HTTP 200 OK. Dynatrace ve éxito. El cliente ve un carrito que no avanza. NODUS ve el proceso de negocio fallido.
ya cubre APM · infra · JVM
cobertura actual de errores ERP de negocio
gaps nuevos a cubrir (Sentry + NODUS)
Decisiones clave
Dynatrace — no tocar
Ya cubre APM técnico en Digou. El equipo técnico lo usa. NODUS no duplica esto.
Sentry SDK — gap frontend
Dynatrace no cubre el browser del cliente. Sentry captura errores JS que bloquean el flujo de compra.
NODUS — gap de negocio ERP
Dashboard para el equipo de negocio. Muestra procesos fallidos en Digou ↔ SAP ERP en lenguaje de negocio, no técnico.
Spring EventListener — puente
Capta eventos de negocio en Hybris (orden rechazada, crédito bloqueado) y los publica a NODUS. Sin logs, sin APM.
Cada herramienta cubre lo que la otra no puede ver
APM · Infra · JVM · Logs de servidor
Errores JavaScript en el browser del cliente
Procesos de negocio fallidos en Digou ↔ SAP ERP
| Tipo de evento | Dynatrace | Sentry | NODUS | ¿Por qué importa? |
|---|---|---|---|---|
| Error 5xx en OCC API | ✓ | — | — | Dynatrace lo ve, es error técnico |
| TypeError JS en carrito | ✗ | ✓ | — | Ocurre en browser, fuera del servidor |
| Orden rechazada por ERP | ✗ | ✗ | ✓ | HTTP 200 — Dynatrace ve éxito, el cliente ve error |
| Precio inconsistente Digou ≠ ERP | ✗ | ✗ | ✓ | No es error técnico — es discrepancia de datos |
| Stock desincronizado | ✗ | ✗ | ✓ | Sync técnicamente OK, datos de negocio incorrectos |
| Crédito bloqueado en ERP | ✗ | ✗ | ✓ | Regla de negocio ERP, invisible para APM |
| CronJob Sync fallido | ✓ | — | Impacto | Dynatrace ve el fallo técnico; NODUS muestra el impacto en negocio |
Anatomía de un error ERP que Dynatrace no puede detectar
Cliente
Genera una orden en Digou
Todo fluye normal. Carrito, checkout, datos de envío.
Digou / Hybris
Procesa y envía a ERP
OCC API responde. Hybris crea la orden. Dynatrace: ✓ todo OK.
SAP ERP — El gap
ERP rechaza la orden
Límite de crédito excedido. Pero devuelve HTTP 200 con body: status: REJECTED.
Dynatrace
No detecta nada
Ve HTTP 200. Sin excepción. Sin error de log. Sin alerta. Dashboard verde.
NODUS
Lo detecta y alerta
Spring EventListener captura el evento de negocio y publica el proceso fallido con impacto comercial (R3).
Cliente intenta comprar. ERP rechaza por límite de crédito. Hybris no notifica al cliente. El carrito queda "colgado". HTTP 200 en todos los requests.
Digou confirma la orden. SAP ERP no genera el picking. El cliente recibió confirmación pero el pedido nunca entra en el proceso logístico.
Digou muestra S/ 450. SAP ERP tiene S/ 480. El cliente paga un precio, la factura dice otro. Riesgo de reclamación comercial.
Digou muestra 200 bolsas disponibles. ERP tiene 0. El cliente compra, la orden se crea, pero no puede despacharse. Diferencia >10% dispara R5.
Producto activo en SAP ERP pero no indexado en Digou/Solr. El cliente no puede comprarlo. Revenue perdido sin error técnico.
Orden exitosa en Digou pero SAP ERP no genera el documento comercial. Se detecta en la siguiente conciliación, no en tiempo real.
Dos perspectivas del mismo evento. Seleccioná el rol para ver la vista correspondiente.
Sin procesos fallidos
Todos los procesos de negocio Digou ↔ SAP ERP funcionando correctamente.
5 entidades principales de la App NODUS
{
"id": "evt-9b2c1",
"eventType": "ORDER_REJECTED",
"timestamp": "2026-06-11T14:23:17Z",
"customerId": "CLI-00482",
"orderId": "DGO-2026-08821",
"revenueAtRisk": 24500,
"severity": "CRÍTICO",
"source": "erp_event",
"technicalHttpStatus": 200
}
{
"id": "INC-B001",
"eventId": "evt-9b2c1",
"status": "NUEVO",
"persona": "negocio",
"assignee": null,
"slaMinutes": 15,
"slaBreached": false,
"dynatraceAlertId": null
}
{
"id": "R3",
"eventTypes": ["ORDER_REJECTED","CREDIT_BLOCKED"],
"severity": "CRÍTICO",
"channels": ["slack-negocio","email-comercial"],
"audience": "negocio",
"enabled": true
}
{
"operation": "order_create",
"httpStatus": 200,
"businessStatus": "rejected",
"erpResponseBody": {
"status": "REJECTED",
"reason": "CREDIT_LIMIT_EXCEEDED",
"creditLimit": 50000,
"currentExposure": 51200
}
}
Cada R# se convierte 1:1 en una historia de backlog · Dynatrace cubre las reglas técnicas, NODUS cubre las de negocio
Orden rechazada por SAP ERP → CRÍTICO aunque el HTTP sea 200
NODUS inspecciona el body de respuesta de las llamadas a SAP ERP. Si el campo status contiene REJECTED o similar, crea un BusinessEvent de tipo ORDER_REJECTED con severidad CRÍTICO. No depende del HTTP status code.
Error JS que bloquea flujo de checkout/carrito → CRÍTICO
Excepción capturada por Sentry (I1) en rutas /cart o /checkout. No cubierta por Dynatrace porque ocurre en el browser del cliente. NODUS recibe el evento de Sentry vía webhook y lo muestra en la vista técnica.
Crédito bloqueado sin notificación al cliente → CRÍTICO
Cuando SAP ERP devuelve CREDIT_LIMIT_EXCEEDED, Hybris silencia el error. NODUS captura el evento vía Spring EventListener (I3), crea un incidente CRÍTICO para el equipo comercial e incluye el monto de crédito en riesgo.
Precio inconsistente Digou ≠ SAP ERP (>1% de diferencia) → ALTO
NODUS compara precios del catálogo Digou vs los precios enviados por ERP en la última sincronización. Diferencia superior al 1% en cualquier SKU activo genera un incidente ALTO. Umbral configurable por categoría de producto.
Stock desincronizado: diferencia >10% entre Digou y ERP → ALTO
Si la cantidad disponible en Digou supera en más del 10% la cantidad real en SAP ERP para un producto activo, NODUS genera un incidente ALTO de tipo STOCK_DRIFT. Umbral configurable por SKU o familia.
Orden sin picking en ERP pasados 30 min → ALTO
Si una orden confirmada en Digou no genera un documento de picking en SAP ERP dentro de 30 minutos, NODUS crea un incidente ALTO. El cliente ya recibió confirmación pero el pedido no entra en logística. Ventana de tiempo configurable.
SLA CRÍTICO negocio: respuesta ≤15 min — canal: Slack #negocio-criticos + Email comercial
Incidentes R1 y R3 deben ser reconocidos por el equipo comercial en ≤15 min. El canal técnico (PagerDuty) solo se activa si existe correlación con un error técnico real en Dynatrace.
SLA ALTO negocio: respuesta ≤1 hora — canal: Slack #negocio-high + Email
Incidentes R4, R5 y R6 deben gestionarse en ≤60 min. Si el SLA vence sin assignee, NODUS escala automáticamente y notifica al responsable de guardia del área comercial.
NODUS no reemplaza Dynatrace — lo complementa con la capa de negocio
| # | Integración | Dirección | Mecanismo | Nota | Propietario |
|---|---|---|---|---|---|
| I1 | Sentry SDK → Storefront Digou | Outbound (browser) | Snippet JS / módulo @sentry/angular (Spartacus) | Dynatrace no cubre errores JS del browser | Matty / Frontend |
| I2 | Dynatrace → NODUS (webhook) | Inbound a NODUS | Dynatrace Problem Notification webhook | Correlaciona alerta técnica con impacto de negocio. Enriquece incidentes técnicos con contexto ERP. | DevOps |
| I3 | SAP ERP EventListener → NODUS | Outbound (Hybris) | Spring @EventListener en Hybris. Captura OrderPlacedEvent, CheckoutFailedEvent, CreditCheckEvent | Integración clave. Intercepta la respuesta ERP y detecta rechazos con HTTP 200. | Dev backend |
| I4 | NODUS → Slack Webhook | Outbound | HTTP POST JSON (Incoming Webhook). Canales separados por audience. | #negocio-criticos · #negocio-high · #tech-alerts | Equipo NODUS |
| I5 | NODUS → Email SMTP | Outbound | Email diferenciado por persona: lenguaje comercial (negocio) o técnico | PagerDuty solo si hay correlación técnica real (I2) | Equipo NODUS |
✓ No configurar Filebeat ni Log4j2 HttpAppender
Dynatrace ya centraliza los logs técnicos del servidor en CCv2. Duplicar con Filebeat generaría ruido y costo innecesario. I3 (Spring EventListener) es el mecanismo correcto para los eventos de negocio que Dynatrace no interpreta.
Situaciones límite específicas del gap ERP-negocio
Dynatrace ya alertó del mismo problema — no duplicar notificación
Situación: Un CronJob fallido causa errores técnicos (Dynatrace alerta) Y datos desincronizados (NODUS alerta). El equipo recibe dos alertas del mismo incidente.
Comportamiento esperado: Si NODUS recibe via I2 una alerta de Dynatrace correlacionada, enriquece el incidente técnico con el impacto de negocio en lugar de crear uno nuevo. Campo dynatraceAlertId en Incident.
ERP devuelve HTTP 200 con status REJECTED — clasificar correctamente
Situación: La mayoría de errores de negocio ERP llegan con HTTP 200. El Spring EventListener (I3) debe parsear el body para detectar rechazos, no confiar en el HTTP status.
Comportamiento esperado: El EventListener inspecciona campos como status, result, errorCode en el body ERP. Lista de patrones de rechazo configurables.
Error de Backoffice sin impacto en cliente — no notificar a negocio
Situación: Errores en Backoffice/HMC afectan al administrador pero no al storefront del cliente.
Comportamiento esperado: El EventListener filtra por origen del evento. Eventos de Backoffice van al log de NODUS como MEDIO sin notificación push al equipo comercial.
Stock desincronizado pero sin órdenes activas del SKU
Situación: Un SKU tiene stock incorrecto pero ningún cliente lo ha comprado en las últimas 24h.
Comportamiento esperado: NODUS clasifica el incidente como MEDIO (R8 SLA: día hábil) en lugar de ALTO. El umbral de urgencia R5 solo aplica si hay actividad de compra reciente del SKU.
Crédito bloqueado legítimamente — no es un error
Situación: El bloqueo de crédito es una regla de negocio válida, no un fallo del sistema. Pero el cliente necesita saber por qué no puede comprar.
Comportamiento esperado: NODUS crea el incidente para el equipo comercial (notificación al ejecutivo de cuenta del cliente). El ERP no siempre notifica al storefront, así que Hybris debe mostrar un mensaje claro al cliente basado en el evento capturado por I3.
Dynatrace ya está. Lo nuevo se divide en tres frentes paralelos.
Por qué este formato funciona
El reencuadre: Dynatrace ya cubre el APM. El argumento de venta de NODUS no es "monitoreo" — es "observabilidad del proceso de negocio ERP", un gap que ninguna herramienta técnica puede llenar.
Dos audiencias, un artefacto: el equipo comercial no lee Dynatrace. NODUS les habla en su idioma: órdenes rechazadas, clientes bloqueados, valor en riesgo.
Demo Reel paralelo: la app ya está prototipada con ambas vistas. El equipo valida con usuarios reales antes de codear una línea del EventListener.