betool betool

Dokumentation

Schedule (Cron)

Eine Pipeline in regelmäßigen Abständen auslösen — täglich, wöchentlich oder mit einem beliebigen Cron-Ausdruck.

Schedule (Cron)

Der Kanal Schedule löst eine Pipeline gemäß einem definierten Kalender aus. Er entspricht einem Cron, wird aber aus dem Adminbereich gesteuert und wie jeder andere exchange protokolliert.

Warum dieser Kanal

Nicht alle Pipelines sind reaktiv (auf eine E-Mail, einen Anruf, einen Webhook). Viele sind proaktiv: täglicher Bericht, wöchentliche Nachverfolgung, stündliche Prüfung eines externen Systems. Genau das deckt der Schedule-Kanal ab.

Konfiguration

  1. Administration → Schedule → Neue Aufgabe.
  2. Wählen Sie:
    • Ziel-Pipeline
    • Kalender — bauen Sie ihn visuell mit dem CronBuilder (täglich, wöchentlich, Tage und Uhrzeiten) oder geben Sie einen klassischen Cron-Ausdruck ein (0 8 * * 1-5 = 8 Uhr an Werktagen) oder eine Abkürzung (@daily, @hourly). Keine Kenntnis der Cron-Syntax erforderlich.
    • Zeitzone — standardmäßig die Zeitzone der Organisation. Pro Aufgabe konfigurierbar.
    • Ziel — eine frei wählbare Bezeichnung (z. B. briefing_hebdo, alerte_impayes), die an die Pipeline übergeben wird, um sie zu routen.
    • Statische Nutzlast — beliebiges JSON, das als Eingabe an die Pipeline übergeben wird.

Eine Pipeline, mehrere Ziele. Dieselbe Pipeline kann von mehreren geplanten Aufgaben ausgelöst werden, jede mit einem anderen objectif. Bedingungen (filter) am Anfang der Pipeline steuern dann die Ausführung entsprechend dem empfangenen Ziel — zum Beispiel ein wöchentliches Briefing montags und eine tägliche Warnung im selben Template (siehe CFO IA).

Was die Pipeline erhält

Bei jedem Auslösen wird ein exchange erstellt mit:

  • schedule.task_id — Kennung der geplanten Aufgabe
  • schedule.objectif — die konfigurierte Zielbezeichnung (für das Routing mehrerer Aufgaben)
  • schedule.scheduled_at — geplanter Zeitstempel
  • schedule.actual_at — tatsächlicher Zeitstempel (bei Drift)
  • schedule.payload — das konfigurierte statische JSON (falls vorhanden)

Toleranz & Nachholen

Wenn betool zum Zeitpunkt eines Auslösers nicht verfügbar ist (Wartung, Störung), wird die Aufgabe beim Neustart automatisch nachgeholt, innerhalb des von Ihnen konfigurierten Toleranzfensters (standardmäßig 1 Stunde).

Jenseits des Fensters wird der Auslöser im Verlauf als verpasst markiert und nicht erneut abgespielt — ein fehlender Bericht ist besser als ein verspäteter und nicht mehr synchroner.

Typische Anwendungsfälle

  • Täglicher Bericht um 8 Uhr — ein Agent, der mehrere Systeme abfragt, zusammenfasst und per E-Mail eine Kurzfassung sendet.
  • Stündliche Synchronisierung — eine Pipeline, die neue Elemente aus einem externen System zieht, sie an einen Klassifizierungs-Agent übergibt und die Ergebnisse in Ihr CRM überträgt.
  • Wöchentliche Prüfung — ein Agent, der den Zustand einer Infrastruktur prüft und Abweichungen meldet.
  • Nachverfolgung nach 7 Tagen — bei Leads, die vor einer Woche eingereicht wurden und noch ohne Antwort sind.

Bewährte Praktiken

  • Vermeiden Sie Starts auf die volle Minute — viele Systeme takten bei 0 * * * *. Bevorzugen Sie 7 * * * *, um die Last zu verteilen.
  • Protokollieren Sie Aufgaben, die nichts zu tun haben. Eine Aufgabe, die läuft, aber nichts tut (weil es keine zu verarbeitenden Elemente gibt), muss dies ausdrücklich nachvollziehbar machen. Andernfalls können Sie „alles in Ordnung" nicht von „die Aufgabe läuft nicht mehr" unterscheiden.
  • Warnen Sie bei verpassten Aufgaben. Siehe Credits & Metering → Warnungen.