Der Kanal Schedule löst eine Pipeline gemäß einem definierten Kalender aus. Er entspricht einem Cron, wird aber im Editor des Modells konfiguriert 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
- Konfigurieren Sie im Editor des Modells den Knoten Start mit einem Empfänger Geplanter Trigger.
- Wählen Sie:
- Kalender — bauen Sie ihn visuell mit dem CronBuilder (täglich, wöchentlich oder monatlich, zur Uhrzeit Ihrer Wahl) oder wechseln Sie in den erweiterten Modus, um einen klassischen Cron-Ausdruck mit 5 Feldern einzugeben (
0 8 * * 1-5= 8 Uhr an Werktagen). Keine Kenntnis der Cron-Syntax erforderlich. - Zeitzone — IANA-Name (
Europe/Paris,UTC…), in dem der Kalender interpretiert wird. Standard:UTC. - Ziel — eine frei wählbare Bezeichnung (z. B.
briefing_hebdo,alerte_impayes), die an die Pipeline übergeben wird, um sie zu routen. - Bei verpasstem Tick — die Nachholrichtlinie (
catchup), siehe weiter unten. Standard: alle nachholen.
- Kalender — bauen Sie ihn visuell mit dem CronBuilder (täglich, wöchentlich oder monatlich, zur Uhrzeit Ihrer Wahl) oder wechseln Sie in den erweiterten Modus, um einen klassischen Cron-Ausdruck mit 5 Feldern einzugeben (
Eine Pipeline, mehrere Ziele. Derselbe Start kann mehrere geplante Trigger tragen, jeder 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.objectif— die konfigurierte Zielbezeichnung (für das Routing mehrerer Trigger)schedule.cron— der konfigurierte Cron-Ausdruckschedule.occurrence— der geplante Zeitstempel (UTC)schedule.fired_at— der tatsächliche Zeitstempel der Auslösung (UTC)schedule.catchup—true, wenn diese Auslösung nachgeholt wird
Toleranz & Nachholen
Jede Auslösung wird vor ihrer Ausführung in eine dauerhafte Warteschlange gestellt: Ein Neustart während der Ausführung geht nicht verloren.
Wenn betool zum Zeitpunkt einer Auslösung nicht verfügbar ist (Wartung, Störung), hängt das Schicksal verpasster Vorkommen von der Einstellung Bei verpasstem Tick (catchup) des Triggers ab:
| Auswahl | Wert | Wirkung |
|---|---|---|
| alle nachholen (Standard) | all | Verpasste Vorkommen werden erneut ausgeführt, innerhalb eines Fensters von 24 Stunden und begrenzt auf die 12 neuesten. |
| nur den neuesten | run_once | Nur das neueste verpasste Vorkommen wird erneut ausgeführt. |
| keinen | skip | Kein verpasstes Vorkommen wird erneut ausgeführt; die Pipeline setzt bei der nächsten geplanten Auslösung wieder ein. |
Ein nachgeholtes Vorkommen wird genau einmal ausgeführt und mit schedule.catchup = true markiert, sodass die Pipeline einen verspätet erstellten Bericht kennzeichnen kann. Ein absichtlich übersprungenes Vorkommen (run_once, skip) bleibt endgültig übersprungen: Es taucht später nicht wieder auf, auch wenn Sie die Richtlinie danach ändern.
Jenseits des 24-Stunden-Fensters wird nichts erneut ausgeführt: Ein fehlender Bericht ist besser als eine Lawine verspäteter Berichte. Ein Trigger, der noch nie ausgeführt wurde, hat nichts nachzuholen.
Wählen Sie nur den neuesten für einen Momentanzustand (Synchronisierung, Prüfung), bei dem nur die letzte Ausführung zählt, und keinen, wenn eine verspätete Ausführung keinen Sinn mehr hätte (stündliche Warnung, Erinnerung zu fester Uhrzeit).
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 Sie7 * * * *, 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.