Documentation

Planification (cron)

Déclencher un pipeline à intervalles réguliers — quotidien, hebdomadaire, mensuel, ou expression cron arbitraire.

Planification (cron)

Le canal schedule déclenche un pipeline selon un calendrier défini. C'est l'équivalent d'un cron, mais configuré dans l'éditeur du modèle et journalisé comme tous les autres exchanges.

Pourquoi ce canal

Tous les pipelines ne sont pas réactifs (à un email, un appel, un webhook). Beaucoup sont proactifs : rapport quotidien, relance hebdomadaire, vérification horaire d'un système externe. C'est ce que couvre le canal schedule.

Configuration

  1. Dans l'éditeur du modèle, configurez le nœud Start avec un récepteur Déclencheur planifié.
  2. Choisissez :
    • Calendrier — composez-le visuellement avec le CronBuilder (quotidien, hebdomadaire ou mensuel, à l'heure de votre choix), ou passez en mode avancé pour saisir une expression cron classique à 5 champs (0 8 * * 1-5 = 8h en semaine). Aucune connaissance de la syntaxe cron requise.
    • Fuseau horaire — nom IANA (Europe/Paris, UTC…) dans lequel le calendrier est interprété. Par défaut : UTC.
    • Objectif — une étiquette libre (ex. briefing_hebdo, alerte_impayes) passée au pipeline pour le router.

Un pipeline, plusieurs objectifs. Un même Start peut porter plusieurs déclencheurs planifiés, chacun avec un objectif différent. Des conditions (filter) en début de pipeline dirigent alors l'exécution selon l'objectif reçu — par exemple un briefing hebdomadaire le lundi et une alerte quotidienne dans le même modèle (voir CFO IA).

Ce que le pipeline reçoit

À chaque déclenchement, un exchange est créé avec :

  • schedule.objectif — l'étiquette d'objectif configurée (pour le routage multi-déclencheurs)
  • schedule.cron — l'expression cron configurée
  • schedule.occurrence — l'horodatage prévu (UTC)
  • schedule.fired_at — l'horodatage réel du déclenchement (UTC)
  • schedule.catchup — true si ce déclenchement est un rattrapage

Tolérance & rattrapage

Chaque déclenchement est mis en file durable avant d'être exécuté : un redémarrage pendant l'exécution ne le perd pas.

Si betool est indisponible au moment d'un déclenchement (maintenance, incident), les occurrences manquées sont rattrapées automatiquement au redémarrage, dans une fenêtre de 24 heures et dans la limite des 12 plus récentes. Chacune est exécutée une seule fois et marquée schedule.catchup = true, ce qui permet au pipeline de signaler un rapport produit en retard.

Au-delà de la fenêtre, les occurrences ne sont pas rejouées : mieux vaut un rapport manquant qu'une avalanche de rapports tardifs. Un déclencheur qui ne s'est encore jamais exécuté n'a rien à rattraper.

Cas d'usage typiques

  • Rapport quotidien 8h — agent qui interroge plusieurs systèmes, synthétise et envoie un brief par email.
  • Sync horaire — pipeline qui pull les nouveaux items d'un système externe, les passe à un agent classifier, et pousse les résultats dans votre CRM.
  • Vérification hebdomadaire — agent qui audite l'état d'une infrastructure et signale les écarts.
  • Relance J+7 — sur les leads soumis il y a une semaine et toujours sans réponse.

Bonnes pratiques

  • Évitez les démarrages de minute pile — beaucoup de systèmes pulsent à 0 * * * *. Préférez 7 * * * * pour répartir la charge.
  • Loggez les tâches qui n'ont rien à faire. Une tâche qui s'exécute mais ne fait rien (parce qu'aucun item à traiter) doit le tracer explicitement. Sinon, vous ne saurez pas distinguer « tout va bien » de « la tâche ne s'exécute plus ».