Exécutions planifiées

Le planificateur de Braidrun prend en charge quatre types de déclenchement : CRON (expression périodique), INTERVAL (intervalle fixe), ONE_TIME (unique), DELAYED_COMPLETION (déclenchement en chaîne de workflows). Tous les schedule sont gérés de façon unifiée par le service de planification de la plateforme et continuent de se déclencher selon leur propre calendrier après un redémarrage du service.

Concept : calendrier et exécution

Un schedule décrit « quand se déclencher » ; chaque déclenchement crée une execution. Le schedule est lui-même un objet durable, tandis que l'execution est un enregistrement d'exécution ponctuel. Un schedule peut porter un ensemble statique d'inputs (paires clé-valeur), utilisées comme variables d'entrée de l'execution à chaque déclenchement.

Les quatre types de planification

Les quatre types partagent un jeu de champs communs : enabled (activé ou non), maxRuns (nombre maximal de déclenchements), inputs (variables d'entrée statiques). Lorsque endTime est dépassé ou que le nombre de déclenchements atteint maxRuns, le schedule est automatiquement désactivé, mais pas supprimé.

Créer un schedule CRON

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"
    }
  }'

L'expression cron est à 5 champs : minute heure jour mois jour-de-semaine. Elle prend en charge *, les listes (1,3,5), les plages (1-5) et les pas (*/6) ; le dimanche peut s'écrire 0 ou 7. L'heure de déclenchement est calculée selon le timezone propre au schedule.

Interval : intervalle fixe

Le corps de requête est envoyé à POST /api/schedules comme pour CRON ; seuls les champs diffèrent :

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

• interval — Intervalle de déclenchement, en millisecondes ; une valeur inférieure à 1 seconde est relevée à 1 seconde
• startTime / endTime — Facultatif, horodatage epoch en millisecondes ; si startTime est défini, le déclenchement n'attend cet instant avant de démarrer, et le dépassement de endTime entraîne une désactivation automatique
• maxRuns — Facultatif, désactivation automatique après ce nombre de déclenchements

ONE_TIME : unique

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

startTime est un horodatage epoch en millisecondes. Après un déclenchement unique à l'heure prévue, le schedule est automatiquement désactivé ; dans un déploiement multi-instances, un verrou à usage unique garantit un déclenchement unique.

Planification en chaîne de workflows (DELAYED_COMPLETION)

DELAYED_COMPLETION enchaîne deux workflows : chaque fois que le workflow amont A se termine à l'état COMPLETED, on attend delaySeconds secondes, puis le workflow B lié à ce schedule est déclenché automatiquement. Usage typique : le workflow de rapport s'exécute automatiquement 10 minutes après la fin du workflow de récupération de données.

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

• Que A ait été déclenché manuellement, par Webhook, par planification ou en chaîne, tout achèvement réussi est pris en compte ; une exécution échouée ou annulée ne déclenche pas l'aval
• delaySeconds — Obligatoire, de 0 à 30 jours (2592000 secondes) ; 0 signifie un déclenchement immédiat après l'achèvement
• maxRuns — Laissé vide, le nombre de fois est illimité ; 1 signifie un seul enchaînement ; N signifie au plus N enchaînements, avec désactivation automatique une fois atteint
• triggerWorkflowId — Ne peut pas être égal à workflowId (se déclencher soi-même provoquerait une boucle infinie), et le créateur doit disposer d'un droit de lecture sur le workflow amont
• Un déclenchement différé en attente est stocké de façon persistante et n'est pas perdu lors d'un redémarrage du service ou d'un déploiement progressif : il se déclenche normalement à l'heure prévue

Gérer les schedule

# 立即执行一次（返回这次 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>"

Le enabled de toggle peut être placé dans un paramètre query ou dans le body JSON ; si aucun des deux n'est fourni, on bascule entre activé et désactivé. Chaque enregistrement de history contient l'état, le succès ou l'échec, et les heures de début et de fin ; limit vaut 50 par défaut et 500 au maximum.

Entrées partagées et préréglages de paramètres

Outre le réglage direct des inputs sur un schedule, vous pouvez créer des « presets de paramètres » pour un workflow : un même workflow s'exécute avec différentes configurations selon le preset.

# 创建一个参数预设
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>"

Concurrence par lots de plusieurs flux de travail

Sélectionnez plusieurs éléments dans la liste des flux de travail et cliquez sur « Exécution simultanée » pour démarrer un lot d'exécutions à la fois.

• Chaque workflow sélectionné créera son propre enregistrement d'exécution
• L'exécution dépassant maxConcurrency entrera d'abord en attente.
• Une fois l'exécution en cours terminée, la suivante dans la file d'attente est automatiquement convertie en RUNNING
• 0 N'indique aucune limite et démarre l'ensemble du lot en même temps

Comportement après redémarrage du service

• Exécution déclenchée : La valeur par défaut est INTERROMPUE sauf si la poursuite automatique est activée (voirRedémarrage et reprise automatique）
• Les CRON / INTERVAL / ONE_TIME dont l'heure n'est pas encore venue : se déclenchent normalement après un redémarrage
• Un déclenchement différé DELAYED_COMPLETION en attente : déjà persisté, il continue d'attendre après un redémarrage et se déclenche à l'heure prévue
• Points de déclenchement manqués lors d'un temps d'arrêt : pas de rattrapage (pour éviter le risque de double écriture)

Pages connexes

• Déclencheur Webhook
• Reprise automatique après redémarrage du service