⏰ DTM — Distributed Task Manager (Análisis y Absorción)¶

Fecha: 1 de abril de 2026 Propósito: Documentar qué es DTM, qué hace actualmente, y cómo Pet Flows lo absorbe Fuente: investigacion_dkv_pet_cloud.md, arquitectura general del ecosistema DKV

1. ¿Qué es DTM?¶

dkv-distributed-task-manager (DTM) es un servicio Java independiente que utiliza Quartz Scheduler para ejecutar tareas periódicas en el ecosistema DKV PET. Es un contenedor aislado que se conecta a su propia base de datos PostgreSQL para persistir los jobs de Quartz.

Posicionamiento en el Ecosistema¶

graph TB
    subgraph "Ecosistema DKV PET"
        PC["🐾 dkv-pet-cloud<br/>Spring Boot<br/>API + Lógica de negocio"]
        NC["🦎 netcomp<br/>Erlang<br/>Platform legacy"]
        NTF["📲 dkv-notifications<br/>Erlang OTP<br/>Push notifications"]
        DTM["⏰ DTM<br/>Java + Quartz<br/>Tareas planificadas"]
        PF["📊 dkv-pet-flows<br/>Quarkus + Dapr<br/>Customer Engagement"]
    end

    DTM -->|"HTTP calls"| PC
    DTM -->|"HTTP calls"| NTF
    PC <-->|"RabbitMQ"| NC

    style DTM fill:#6366f1,color:#fff
    style PC fill:#009BE0,color:#fff
    style NTF fill:#D97706,color:#fff
    style PF fill:#7C3AED,color:#fff

2. Tipos de Tareas que DTM Ejecuta¶

Basado en el análisis del ecosistema, DTM se encarga de tareas como:

Categoría	Ejemplos	Frecuencia típica
Limpieza	Purgar encounters inactivos, limpiar tokens expirados	Diaria / Semanal
Reportes	Generar reportes de actividad, métricas de colas	Diaria
Sincronización	Sincronizar datos entre sistemas, reindexar ES	Periódica
SLA / Alertas	Verificar tiempos de respuesta de colas, enviar alertas	Cada N minutos
Mantenimiento	Rotación de logs, compactación de datos	Semanal

Características Técnicas¶

Aspecto	Detalle
Lenguaje	Java
Scheduler	Quartz Scheduler
Persistencia	PostgreSQL (tablas QRTZ_*)
Ejecución	Cron expressions
Distribución	Quartz clustering (múltiples instancias)
Imagen Docker	Container independiente en el stack

3. ¿Por Qué Absorber DTM?¶

Problema actual¶

DTM es un servicio aislado sin dashboard ni visibilidad
Las tareas planificadas están dispersas entre DTM (Quartz), las notificaciones de cola (pet-cloud), y configuraciones ad-hoc
No hay un lugar único donde un operador pueda ver "¿qué tareas periódicas tenemos y cuándo se ejecutan?"

Valor de la absorción¶

ANTES                                    DESPUÉS
──────                                   ───────

DTM (Quartz):                            Pet Flows (Dapr Timers + Cron Bindings):
  - tarea_limpieza_diaria                  - Flujo: Limpieza diaria
  - tarea_reporte_semanal                  - Flujo: Reporte semanal
  - tarea_alerta_sla                       - Flujo: Alerta SLA
  - tarea_sync_datos                       - Flujo: Sync datos

Cola (pet-cloud):                          ┌────────────────────────┐
  - notify_encounter_*                     │  TODO en un solo lugar │
  - notify_inactive_*                      │  con editor visual     │
  - notify_unassigned_*                    │  y dashboard unificado │
                                           └────────────────────────┘
Config ad-hoc:  
  - cron en docker-compose
  - scripts de bash con crontab

4. Estrategia de Absorción: Strangler Fig¶

[!IMPORTANT] NO hacemos una migración big-bang. DTM sigue corriendo. Los nuevos scheduling van a Pet Flows. Los históricos expiran solos.

Fases de la Absorción¶

graph LR
    subgraph "Fase 1: Coexistencia"
        DTM1["⏰ DTM<br/>Tareas históricas<br/>siguen corriendo"]
        PF1["📊 Pet Flows<br/>NUEVAS tareas<br/>Dapr Cron Bindings"]
    end

    subgraph "Fase 2: Migración gradual"
        DTM2["⏰ DTM<br/>Menos tareas<br/>solo las que no expiran"]
        PF2["📊 Pet Flows<br/>Absorbe tareas<br/>una por una"]
    end

    subgraph "Fase 3: Apagado"
        PF3["📊 Pet Flows<br/>TODAS las tareas<br/>DTM eliminado"]
    end

    DTM1 --> DTM2
    PF1 --> PF2
    DTM2 -.->|"se apaga"| PF3
    PF2 --> PF3

    style DTM1 fill:#6366f1,color:#fff
    style DTM2 fill:#f97316,color:#fff
    style PF1 fill:#7C3AED,color:#fff
    style PF2 fill:#7C3AED,color:#fff
    style PF3 fill:#059669,color:#fff

Reglas de la Absorción¶

Regla	Descripción
R1	Toda NUEVA tarea planificada se crea como flujo en Pet Flows (con trigger Cron)
R2	DTM NO recibe nuevos jobs. Solo ejecuta los existentes
R3	Cada tarea de DTM se evalúa: ¿expira sola? Si sí → no hacer nada. Si no → migrar a Pet Flows
R4	Cuando DTM no tiene jobs activos → apagar contenedor
R5	No hay ETL de datos. Las tablas QRTZ_* se archivan, no se migran

5. Equivalencia Técnica: Quartz vs Dapr¶

Capacidad	Quartz (DTM)	Dapr (Pet Flows)
Cron scheduling	✅ `CronTrigger`	✅ `Cron Binding` (YAML)
One-time scheduling	✅ `SimpleTrigger`	✅ `ctx.createTimer(duration)`
Persistencia de jobs	✅ `QRTZ_*` tables	✅ Built-in (state store)
Clustering	✅ Quartz Cluster Mode	✅ Dapr sidecar per instance
Retry / failover	✅ Misfire policies	✅ Dapr retry policies
Dashboard / visibilidad	❌ No tiene	✅ Pet Flows UI + SSE monitor
Editor visual	❌	✅ Canvas con nodo Cron Trigger

6. Impacto en el MVP Backlog¶

Para el MVP Backlog de Pet Flows, la absorción de DTM no es prioridad. El flujo de encuesta no necesita nada de DTM. Pero el segundo flujo (SLA de colas) sí se beneficiaría de tener un trigger tipo Cron.

Flujo MVP Backlog	¿Necesita DTM?	Tipo de trigger
Encuesta post-consulta	❌ No	Event-based (webhook)
Alerta SLA de cola	🟡 Parcial	Podría ser cron (polling SLA) o event-based
Re-engagement por inactividad	✅ Sí	Cron (diario) + segmento

Timeline Recomendado¶

MVP Backlog (Semana 1-5):     Sin DTM. Solo event-based triggers.
Sprint 4 (Semana 6-7): Implementar Cron Binding en Dapr. Primer flujo cron.
Sprint 5+ (Semana 8+): Migrar tareas DTM existentes a flujos Pet Flows.
Post-GoLive (Julio+):  Apagar contenedor DTM.

7. Beneficio Estratégico¶

Cuando Pet Flows absorba DTM, DKV tendrá:

Un único dashboard donde ver flujos de engagement + tareas de mantenimiento
Un único motor (Dapr) para ejecutar todo tipo de scheduling
Un único formato (flow JSON) para definir tanto campañas como tareas operativas
Menos contenedores en producción (DTM desaparece)

Esto posiciona a Pet Flows como el "centro de control de operaciones automatizadas" del ecosistema DKV PET.

Documentos Relacionados¶

Documento	Propósito
01 — Mapa de Piezas	Vista general del ecosistema
aux_03 — Netcomp Webhooks	Análisis de webhooks y Leader/Follower
05 — Direcciones Estratégicas	Sprint plan