Geplante Ausführungen

Der Scheduler von Braidrun unterstützt vier Trigger-Typen: CRON (periodischer Ausdruck), INTERVAL (festes Intervall), ONE_TIME (einmalig), DELAYED_COMPLETION (verkettete Workflow-Auslösung). Alle schedule werden vom Zeitplandienst der Plattform einheitlich verwaltet und lösen nach einem Serviceneustart gemäß ihrem jeweiligen Zeitplan weiter aus.

Konzept: Zeitplan und Ausführung

Ein schedule beschreibt, „wann ausgelöst wird“; jede Auslösung erzeugt eine execution. Ein Schedule ist selbst ein langlebiges Objekt, eine execution ein einmaliger Laufdatensatz. Ein Schedule kann eine statische inputs-Menge (Schlüssel-Wert-Paare) mitführen, die bei jeder Auslösung als Eingabevariablen der execution dienen.

Die vier Zeitplantypen

Die vier Typen teilen einen Satz gemeinsamer Felder: enabled (ob aktiviert), maxRuns (maximale Auslösezahl), inputs (statische Eingabevariablen). Ist endTime überschritten oder erreicht die Auslösezahl maxRuns, wird der schedule automatisch deaktiviert, aber nicht gelöscht.

Einen CRON-schedule erstellen

curl -X POST https://braidrun.com/api/schedules \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{
    "workflowId": "<workflow-id>",
    "name": "Daily 9 AM report",
    "scheduleType": "CRON",
    "cronExpression": "0 9 * * *",
    "timezone": "Asia/Shanghai",
    "inputs": {
      "environment": "production"
    }
  }'

Der cron-Ausdruck ist 5-teilig: Minute Stunde Tag Monat Wochentag. Unterstützt werden *, Listen (1,3,5), Bereiche (1-5) und Schritte (*/6); Sonntag lässt sich als 0 oder 7 schreiben. Die Auslösezeit wird nach der eigenen timezone des schedule berechnet.

Interval: festes Intervall

Der Request-Body wird wie bei CRON an POST /api/schedules gesendet, nur mit anderen Feldern:

{
  "workflowId": "<workflow-id>",
  "name": "每 5 分钟同步一次",
  "scheduleType": "INTERVAL",
  "interval": 300000,
  "startTime": 1785542400000,
  "endTime": 1788220800000,
  "maxRuns": 500
}

• interval — Auslöseintervall in Millisekunden; Werte unter 1 Sekunde werden auf 1 Sekunde angehoben
• startTime / endTime — Optional, epoch-Millisekunden-Zeitstempel; ist startTime gesetzt, wird bis zu diesem Zeitpunkt gewartet, bevor begonnen wird, und nach Überschreiten von endTime automatisch deaktiviert
• maxRuns — Optional, nach so vielen Auslösungen automatisch deaktiviert

ONE_TIME: einmalig

{
  "workflowId": "<workflow-id>",
  "name": "上线前补跑一次",
  "scheduleType": "ONE_TIME",
  "startTime": 1785546000000
}

startTime ist ein epoch-Millisekunden-Zeitstempel. Nach einer einmaligen Auslösung zum Zeitpunkt wird der schedule automatisch deaktiviert; bei einem Multi-Instanz-Deployment stellt eine Einmalsperre sicher, dass nur einmal ausgelöst wird.

Verkettete Workflow-Planung (DELAYED_COMPLETION)

DELAYED_COMPLETION verkettet zwei Workflows: Nachdem der vorgelagerte Workflow A jeweils im Status COMPLETED endet, wird nach delaySeconds Sekunden automatisch der an diesen schedule gebundene Workflow B ausgelöst. Typische Verwendung: 10 Minuten nach Abschluss des Datenabruf-Workflows automatisch den Report-Workflow ausführen.

{
  "workflowId": "<workflow-B-id>",
  "name": "A 完成 10 分钟后跑 B",
  "scheduleType": "DELAYED_COMPLETION",
  "triggerWorkflowId": "<workflow-A-id>",
  "delaySeconds": 600,
  "maxRuns": 10
}

• Unabhängig davon, ob A manuell, per Webhook, zeitgesteuert oder verkettet ausgelöst wurde, zählt es, sobald es erfolgreich abgeschlossen ist; fehlgeschlagene oder abgebrochene Ausführungen lösen den nachgelagerten Workflow nicht aus
• delaySeconds — Pflicht, 0 bis 30 Tage (2592000 Sekunden); 0 bedeutet sofortige Auslösung nach Abschluss
• maxRuns — Ohne Angabe unbegrenzt oft; 1 bedeutet nur einmal verketten; N bedeutet höchstens N-mal verketten, danach automatisch deaktiviert
• triggerWorkflowId — Darf nicht gleich workflowId sein (sich selbst auszulösen ergäbe eine Endlosschleife), und der Ersteller benötigt Leserechte für den vorgelagerten Workflow
• Ausstehende verzögerte Auslösungen werden persistent gespeichert und gehen bei einem Serviceneustart oder Rolling-Release nicht verloren: Zum Zeitpunkt wird wie gewohnt ausgelöst

Schedules verwalten

# 立即执行一次（返回这次 execution）
curl -X POST https://braidrun.com/api/schedules/<schedule-id>/run \
  -H "Authorization: Bearer <token>"

# 停用（enabled=true 则启用；不带参数则在两者间切换）
curl -X POST "https://braidrun.com/api/schedules/<schedule-id>/toggle?enabled=false" \
  -H "Authorization: Bearer <token>"

# 最近 50 条触发历史
curl "https://braidrun.com/api/schedules/<schedule-id>/history?limit=50" \
  -H "Authorization: Bearer <token>"

Das enabled von toggle lässt sich als query-Parameter oder im JSON-body übergeben; wird beides nicht übergeben, wird zwischen aktiviert / deaktiviert umgeschaltet. Jeder Datensatz von history enthält Status, Erfolg oder Misserfolg sowie Start- und Endzeit; limit ist standardmäßig 50, maximal 500.

Gemeinsame Eingaben und Parametervoreinstellungen

Neben dem direkten Setzen von inputs am schedule lassen sich für einen Workflow auch „Parameter-Presets“ anlegen: Derselbe workflow läuft mit verschiedenen Presets in unterschiedlichen Konfigurationen.

# 创建一个参数预设
curl -X POST https://braidrun.com/api/workflows/<wf>/presets \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "生产环境",
    "description": "生产环境参数",
    "variables": {
      "environment": "production",
      "debug_mode": "false",
      "max_retries": "3"
    }
  }'

# 用预设触发执行
curl -X POST https://braidrun.com/api/workflows/<wf>/presets/<id>/execute \
  -H "Authorization: Bearer <token>"

Parallelität mehrerer Workflow-Batches

Wählen Sie mehrere Elemente aus der Workflow-Liste aus und klicken Sie auf „Gleichzeitige Ausführung“, um jeweils einen Stapel von Ausführungen zu starten.

• Jeder ausgewählte Workflow erstellt seinen eigenen Ausführungsdatensatz
• Eine Ausführung, die maxConcurrency überschreitet, wird zunächst in den Status PENDING versetzt
• Nachdem die zuvor laufende Ausführung abgeschlossen ist, wird die nächste in der Warteschlange automatisch in RUNNING umgewandelt
• 0 Zeigt keine Begrenzung an und startet die gesamte Charge gleichzeitig

Verhalten nach Dienstneustart

• Ausgelöste Ausführung: Der Standardwert ist UNTERBROCHEN, es sei denn, die automatische Fortsetzung ist aktiviert (sieheNeustart und automatische Fortsetzung）
• Noch nicht fällige CRON / INTERVAL / ONE_TIME: lösen nach einem Neustart wie gewohnt aus
• Ausstehende verzögerte DELAYED_COMPLETION-Auslösungen: bereits persistiert, warten nach einem Neustart weiter bis zum Auslösezeitpunkt
• Verpasste Triggerpunkte während der Ausfallzeit: kein Nachholen (um das Risiko einer Doppelbeschriftung zu vermeiden)

Verwandte Seiten

• Webhook-trigger
• Auto-Resume nach Service-Neustart