Saltar a contenido

Arquitectura — CDP Unomi

Visión general

El CDP centraliza el comportamiento de los clientes de Compulandia en un perfil único por persona. Los eventos llegan exclusivamente por API servidor a servidor (Jitsu como única capa de mapeo, alimentado por Cloudflare Zaraz para la web y por n8n para SAP). Unomi valida cada evento contra un esquema JSON, ejecuta reglas, recalcula segmentos y puntuaciones y persiste todo en Elasticsearch. Marketing administra definiciones y consulta perfiles desde Inoyu OSS UI; los sistemas integradores usan la API REST. Ningún navegador de cliente final habla con Unomi.

Componentes

Componente Responsabilidad Tecnología
cdp-unomi Motor CDP: API pública de eventos (/cxs/eventcollector, /cxs/context.json), API administrativa (/cxs/*, Basic auth karaf), validación por esquemas JSON, reglas, segmentos, scoring, goals, purga por retención, privacidad. apache/unomi:3.0.0 (Java 17, Karaf 4.4)
cdp-es Persistencia de perfiles, sesiones, eventos y definiciones. Un solo nodo, 1 shard y 0 réplicas por índice, rotación de índices de eventos y sesiones por tamaño. elasticsearch:9.1.3, seguridad desactivada (solo red interna del stack)
cdp-inoyu-ui Interfaz de administración. El navegador solo habla con su servidor Next.js, que reenvía a Unomi por /api/cxs/* con las credenciales de karaf. Un único usuario administrador; la identidad de cada persona la aporta Cloudflare Access. Inoyu OSS UI commit e78c1bd (Next.js 16, React 19) + seis parches propios (unomi-eval/inoyu-ui/)
Cloudflare Tunnel + Access Entrada única desde internet: cdp.compulandia.com.py (UI, SSO) y cdp-api.compulandia.com.py (API, token de servicio). El conector cloudflared corre fuera del stack, en la VM o en otro servidor de la VPC. Zero Trust
Jitsu, n8n, Zaraz Captura, extracción y normalización. Externos a este repositorio. Infraestructura existente

Definición de los servicios: unomi-eval/deploy/docker-compose.yml.

Dependencias externas

Dependencia Uso ¿Qué pasa si no está?
Elasticsearch (cdp-es, mismo stack) Todo el estado de Unomi Unomi no arranca (el entrypoint espera _cat/health); en caliente, cada petición falla y los eventos se pierden
Cloudflare Tunnel (cloudflared en la VPC) Único camino de entrada para UI y API Ni marketing ni Jitsu/n8n alcanzan el CDP; la VM sigue sana y acumula nada: los eventos quedan en la cola de reintentos de Jitsu
Cloudflare Access Autenticación de personas (UI) y de sistemas (API) Sin Access, cdp-api queda abierto: los endpoints públicos de Unomi aceptan eventos de cualquiera (verificado el 2026-09-11 antes de crear la política)
Jitsu Única fuente de eventos de producción Sin eventos nuevos; perfiles y segmentos quedan congelados
Zaraz / n8n Captura web y extracción de SAP hacia Jitsu Igual que arriba, por origen
Docker en devops-vm Ejecución del stack Caída total; restart: unless-stopped recupera al reiniciar el demonio
DNS de la VPC de GCE Resolución de nombres al construir la imagen de Inoyu El build de la imagen falla (apk add sin DNS); se mitiga con build.network: host

Diagrama

flowchart LR
  subgraph fuentes[Fuentes]
    web["Navegador del cliente<br/>tienda"]
    sap["ERP SAP"]
  end
  subgraph edge[Cloudflare]
    zaraz["Zaraz"]
    access["Access<br/>SSO / token de servicio"]
    tun["Tunnel"]
  end
  n8n["n8n"]
  jitsu["Jitsu<br/>función de destino Unomi"]
  mkt["Navegador de marketing"]
  subgraph vpc["GCP VPC · devops-vm · Docker"]
    cfd["cloudflared<br/>(servicio del host o de otro servidor)"]
    ui["cdp-inoyu-ui :3131"]
    unomi["cdp-unomi :8181"]
    es[("cdp-es :9200")]
  end
  web --> zaraz --> jitsu
  sap --> n8n --> jitsu
  jitsu -->|"HTTPS cdp-api<br/>POST /cxs/eventcollector"| access
  n8n -.->|"HTTPS cdp-api<br/>API administrativa (Basic)"| access
  mkt -->|"HTTPS cdp"| access
  access --> tun -.->|"QUIC saliente"| cfd
  cfd -->|"http://10.158.0.22:3131"| ui
  cfd -->|"http://10.158.0.22:8181"| unomi
  ui -->|"Basic karaf"| unomi
  unomi --> es

Flujo principal: un evento de compra en la web

  1. El cliente confirma una compra en la tienda. Zaraz captura el evento purchase en el edge y lo envía a Jitsu con el identificador anónimo del visitante y el de sesión.
  2. La función de destino de Jitsu lo transforma al contrato de Unomi (eventType: purchase, scope: tienda-web, properties.orderId/total/items, target con properties.total) y hace POST /cxs/eventcollector en cdp-api.compulandia.com.py con las cabeceras del token de servicio de Access.
  3. Cloudflare verifica el token, el túnel entrega la petición a cdp-unomi por la VPC.
  4. Unomi resuelve el perfil por profileId (lo crea si no existe) y la sesión por sessionId, valida el evento contra el esquema purchase; si no cumple, lo descarta y responde igual 200 {"updated":0}.
  5. Se ejecutan las reglas que coinciden: por ejemplo incrementar totalPurchases, fijar lastPurchaseDate, sumar montoCompras. El perfil cambia, se re-evalúan segmentos (compradores recurrentes, salida de carrito abandonado) y scoring en la misma petición (decenas de milisegundos).
  6. Perfil y sesión se guardan en Elasticsearch de inmediato; el evento se escribe por lotes (flush de 5 s).
  7. Al iniciar sesión el cliente, Jitsu envía un login protegido (X-Unomi-Peer) con su correo; Unomi copia los datos al perfil y lo fusiona con cualquier otro perfil que tenga el mismo correo (web o SAP), dejando el id absorbido como alias.
  8. Marketing ve el perfil, sus segmentos y su historial en Inoyu; n8n puede consultar segmentos por la API para campañas.