El canal schedule dispara un pipeline según un calendario definido. Es el equivalente de un cron, pero configurado en el editor del modelo y registrado como cualquier otro exchange.
Por qué este canal
No todos los pipelines son reactivos (a un email, una llamada, un webhook). Muchos son proactivos: informe diario, seguimiento semanal, comprobación horaria de un sistema externo. Eso es lo que cubre el canal schedule.
Configuración
- En el editor del modelo, configura el nodo Start con un receptor Disparador programado.
- Elige:
- Calendario — constrúyelo visualmente con el CronBuilder (diario, semanal o mensual, a la hora que elijas), o pasa al modo avanzado para introducir una expresión cron clásica de 5 campos (
0 8 * * 1-5= 8h en días laborables). No se requiere conocimiento de la sintaxis cron. - Zona horaria — nombre IANA (
Europe/Paris,UTC…) en el que se interpreta el calendario. Por defecto:UTC. - Objetivo — una etiqueta libre (p. ej.
briefing_hebdo,alerte_impayes) que se pasa al pipeline para enrutarlo. - Si se pierde un tick — la política de recuperación (
catchup), ver más abajo. Por defecto: recuperar todo.
- Calendario — constrúyelo visualmente con el CronBuilder (diario, semanal o mensual, a la hora que elijas), o pasa al modo avanzado para introducir una expresión cron clásica de 5 campos (
Un pipeline, varios objetivos. Un mismo Start puede llevar varios disparadores programados, cada uno con un objectif diferente. Las condiciones (filter) al inicio del pipeline dirigen entonces la ejecución según el objetivo recibido — por ejemplo un briefing semanal el lunes y una alerta diaria en la misma plantilla (consulta CFO IA).
Qué recibe el pipeline
En cada disparo, se crea un exchange con:
schedule.objectif— la etiqueta de objetivo configurada (para el enrutamiento multi-disparador)schedule.cron— la expresión cron configuradaschedule.occurrence— la marca de tiempo planificada (UTC)schedule.fired_at— la marca de tiempo real del disparo (UTC)schedule.catchup—truesi este disparo es una recuperación
Tolerancia y recuperación
Cada disparo se pone en una cola duradera antes de ejecutarse: un reinicio durante la ejecución no lo pierde.
Si betool no está disponible en el momento de un disparo (mantenimiento, incidente), el destino de las ocurrencias perdidas depende del ajuste Si se pierde un tick (catchup) del disparador:
| Opción | Valor | Efecto |
|---|---|---|
| recuperar todo (por defecto) | all | Las ocurrencias perdidas se vuelven a ejecutar, dentro de una ventana de 24 horas y con un límite de las 12 más recientes. |
| solo el más reciente | run_once | Solo se vuelve a ejecutar la ocurrencia perdida más reciente. |
| ninguno | skip | No se vuelve a ejecutar ninguna ocurrencia perdida; el pipeline se reanuda en el siguiente disparo previsto. |
Una ocurrencia recuperada se ejecuta una sola vez y se marca con schedule.catchup = true, lo que permite al pipeline señalar un informe producido con retraso. Una ocurrencia omitida a propósito (run_once, skip) lo queda definitivamente: no vuelve a aparecer más tarde, aunque cambies de política después.
Más allá de la ventana de 24 horas, no se vuelve a ejecutar nada: un informe ausente es mejor que una avalancha de informes tardíos. Un disparador que todavía no se ha ejecutado nunca no tiene nada que recuperar.
Elige solo el más reciente para un estado instantáneo (sincronización, verificación) en el que solo cuenta la última ejecución, y ninguno cuando una ejecución tardía ya no tendría sentido (alerta horaria, recordatorio a hora fija).
Casos de uso típicos
- Informe diario a las 8h — un agente que consulta varios sistemas, resume y envía un resumen por email.
- Sincronización horaria — un pipeline que extrae los nuevos elementos de un sistema externo, los pasa a un agente clasificador y envía los resultados a tu CRM.
- Comprobación semanal — un agente que audita el estado de una infraestructura y señala discrepancias.
- Seguimiento a D+7 — sobre los leads enviados hace una semana y todavía sin respuesta.
Buenas prácticas
- Evita los arranques al minuto en punto — muchos sistemas pulsan a
0 * * * *. Prefiere7 * * * *para repartir la carga. - Registra las tareas que no tienen nada que hacer. Una tarea que se ejecuta pero no hace nada (porque no hay elementos que procesar) debe dejar constancia explícita. De lo contrario, no podrás distinguir «todo va bien» de «la tarea ya no se ejecuta».