Jobs de fondo y alertas¶

WorkDone Sanitarios no es un sistema puramente reactivo: no todo nace de un tap sobre una placa NFC. Hay un conjunto de procesos periódicos (@Scheduled) que corren en el backend cada cierto tiempo, sin que nadie los dispare, y que se encargan de generar alertas, cerrar estado colgado y limpiar datos.

Esta página explica esos jobs, el catálogo real de alertas, cómo viven y mueren las alertas (incluida la deduplicación y la auto-atención), y los estados de conexión que el backend deriva de cada dispositivo.

1. Schedulers @Scheduled¶

Cada job es un método @Scheduled + @Transactional independiente: si uno falla, su transacción hace rollback sola y no afecta a los demás. La cadencia es configurable por properties (se muestra el default).

cerrarTrabajosColgados en detalle¶

Busca trabajos abiertos cuyo inicio_ts es anterior a now - app.scheduler.trabajos-colgados-max-hours y los cierra con estado EGRESO_CIERRE_AUTOMATICO. Sobre el cierre:

• Trunca el fin_ts al máximo de app.tap.cierre-automatico-max-minutes (no inventa una duración gigante).
• Setea cuenta_para_sla = false: un trabajo colgado durante horas no es una limpieza real medida, así que no debe contar para el SLA.
• Agrega el warning scheduler_cierre al trabajo.

2. Generación de alertas¶

El catálogo real es el enum TipoAlerta (domain/enumeration/TipoAlerta.java). Estas son las 9 clases de alerta y quién las dispara:

3. Ciclo de vida de una Alerta¶

Una alerta tiene dos timestamps clave:

• generada_en — cuándo se creó.
• atendida_en — cuándo se cerró. null significa que está abierta.

stateDiagram-v2
    [*] --> Abierta: generada_en = now\natendida_en = null
    Abierta --> Atendida: alguien la atiende\n(operario/admin)
    Abierta --> AutoAtendida: el sistema detecta\nque la condición se normalizó
    Atendida --> [*]
    AutoAtendida --> [*]
    note right of Abierta
        Mientras hay una abierta del mismo
        (tipo, sanitario/dispositivo) NO se
        crea otra: dedup.
    end note

Deduplicación¶

Antes de crear una alerta, el backend chequea si ya existe una abierta equivalente y, si la hay, no crea una nueva. La clave de equivalencia es (tipo, sujeto, atendida_en IS NULL), donde el sujeto es el sanitario o el dispositivo según el tipo:

// SlaSchedulerService.java:112
if (alertaRepository.existsByTipoAndSanitario_IdAndAtendidaEnIsNull(TipoAlerta.SLA_VENCIDO, s.getId())) continue;

Este patrón se repite igual en TENDENCIA_NEGATIVA, DISPOSITIVO_SIN_REPORTAR, RELOJ_DESVIADO y TAG_DEFECTUOSO. Resultado: una sola alerta abierta por sujeto y tipo.

Auto-atención¶

Algunas alertas las cierra el propio sistema (atendida_por_usuario = "sistema") cuando detecta que la condición que las generó se normalizó. No requieren intervención humana.

4. Estados derivados de conexión del dispositivo¶

El backend no persiste el estado de conexión: lo deriva en memoria a partir de ultimo_contacto_ts y now, sin un hit extra a la base. La lógica vive en DispositivoMonitorService.derivarEstado (DispositivoMonitorService.java:90-108).

Si ultimo_contacto_ts es null → NUNCA_CONECTADO. En el resto, los umbrales dependen del tipo de dispositivo:

Los valores son los defaults de MonitorDispositivoProperties y son configurables (app.monitor.*).

5. Tendencia negativa (Smiley)¶

La detección de tendencias vive en SmileyTendenciaService. Lo no obvio es cómo se delimita la ventana de análisis y qué opiniones cuentan.

Ventana de análisis¶

La ventana arranca en el más reciente entre:

1. el fin_ts de la última limpieza válida del sanitario, y
2. now - ventanaMin (el inicio "natural" de la ventana configurada).

// SmileyTendenciaService.java:191-195
Instant calcularVentanaInicio(Instant now, int ventanaMin, Instant ultimaLimpieza) {
    Instant porVentana = now.minusSeconds(ventanaMin * 60L);
    if (ultimaLimpieza == null) return porVentana;
    return ultimaLimpieza.isAfter(porVentana) ? ultimaLimpieza : porVentana;
}

La consecuencia: una limpieza reciente reinicia el conteo. Las negativas previas a esa limpieza dejan de pesar, porque ya fueron "respondidas" por la limpieza correctiva.

Qué opiniones cuentan¶

Las opiniones con origen = QR_PUBLICO se EXCLUYEN de las tendencias. Solo cuentan las de origen TERMINAL_SMILEY. Las consultas de OpinionRepository filtran explícitamente:

// OpinionRepository.java
"  AND o.origen = ar.com.lubeca.workdone.domain.enumeration.OrigenOpinion.TERMINAL_SMILEY "

Para seguir¶

• Reglas operativas — cierres automáticos, SLA y semántica de los taps.
• Modelo de datos — entidad Alerta, enums y relaciones.
• Kiosk Smiley — terminales, opiniones y orígenes.

Resumen. WorkDone corre 7 jobs @Scheduled independientes que generan alertas y mantienen el estado sin depender de taps. El catálogo real son los 9 valores de TipoAlerta; cada alerta vive con generada_en/atendida_en (null = abierta), se deduplica por (tipo, sujeto, atendida_en IS NULL) y algunas el sistema las auto-atiende al normalizarse la condición. El estado de conexión se deriva de ultimo_contacto_ts con umbrales distintos para celular (30/120) y terminal (15/30). Para tendencias, la ventana arranca en la última limpieza válida y solo cuentan opiniones TERMINAL_SMILEY (ADR-041).