Modelar la automatización de larga duración como un registro de ejecución con máquina de estados
Cuando la automatización abarca varios pasos, sistemas o días, cada ejecución necesita identidad, estado y guardas por paso, para poder esperar, fallar, reanudarse y terminar exactamente una vez.
Elaborado de forma independiente. No contiene detalles de implementación, nombres internos ni cifras de ningún empleador o cliente.
01Contexto
Un ciclo comercial mensual refresca datos, calcula KPI, clasifica clientes, escribe los resultados en el CRM y genera acciones. Se ejecuta como un único job programado. Cuando falla un paso, el job se relanza desde el principio, los pasos que ya habían terminado se repiten y algunas cuentas reciben sus acciones dos veces. Nadie fuera del equipo de plataforma puede ver en qué punto está una ejecución.
02Factores de decisión
- F01
Los pasos dependen de trabajo que la automatización no controla
- F02
Un relanzamiento no debe repetir pasos terminados
- F03
El responsable de negocio necesita ver el avance y los fallos
- F04
Las ejecuciones de prueba no deben tener efectos
03Opciones consideradas
Un único job programado que llama a todos los pasos
Trabajo corto, local e idempotente
Coste: Relanzar desde cero; sin identidad; sin visibilidadUna cadena de triggers, uno por paso
Dos o tres pasos locales
Coste: Sin identidad de ejecución; un fallo rompe la cadena en silencioRegistro de ejecución con máquina de estados y guardas por paso
Trabajo de varios pasos, entre sistemas o de larga duración
Coste: Un modelo de ejecución, una guarda por paso y una pequeña vista de ejecuciones04Decisión
Crear un registro de ejecución por clave de negocio (por ejemplo, periodo y alcance), que se rechaza si ya existe. La ejecución recorre estados declarados (creada, en curso, en espera, completada, fallida, abortada) y cada paso registra su propio resultado y comprueba su propia guarda de “ya hecho en esta ejecución”. El trabajo largo se divide en lotes con clave y continuaciones. Un fallo detiene la ejecución en el paso fallido; al reanudarla, continúa desde ahí. Un indicador de simulación ejecuta todas las comprobaciones sin efectos.
05Consecuencias
- Cualquiera puede abrir una ejecución y ver su estado, paso, avance, fallos y responsable.
- Una reanudación nunca repite un paso ni un efecto ya completados.
- Las dependencias se convierten en estados de espera explícitos, con presupuesto.
- Las automatizaciones locales sencillas siguen siendo sencillas: el patrón se reserva para el trabajo que lo necesita.
06Cuándo revisarla
El trabajo cabe en una transacción y en un sistema.
Un orquestador de plataforma ofrece de forma nativa identidad de ejecución, estado y reanudación.
07Dónde se aplica esta decisión
Casos que adoptan esta decisión, y por qué importa en cada uno.