Aller au contenu
AdiosDocumentation
Référence de l’API
FR
Ouvrir le tableau de bord
Parcourir la documentation

Workflows

Adios Workflows relie API, scripts, bases de données, e-mails, stockage d’objets et agents IA dans une suite d’actions suivies. Lancez une exécution manuellement, à partir d’un webhook ou d’un événement, ou à intervalles réguliers. Ajoutez une approbation humaine avant une action qui nécessite une vérification.

Commencez par un exemple complet : traiter un webhook, envoyer un rapport planifié, ou vérifier avant publication. La présentation des workflows comprend aussi des exemples S3 et de scripts.

Sur cette page : manifeste, déclencheurs, les dix actions, sorties et dépendances, secrets et variables d’environnement, et créer et inspecter.

Manifeste de workflow

Un manifeste de workflow décrit les déclencheurs, le contexte partagé et les étapes ordonnées. Dans un dépôt dédié aux workflows, vous pouvez nommer le fichier adios.yaml. Dans un dépôt d’application, conservez le manifeste de l’environnement d’exécution à la racine du projet et les manifestes de workflow dans un répertoire tel que workflows/.

workflow_id: daily-market-brief
title: Daily market brief
team_id: team-local
enabled: true
version: "1"

triggers:
  - type: schedule
    interval: 24h
  - type: webhook
    event: market.brief.requested

context:
  market_api_url: https://api.example.com
  symbols:
    - AAPL
    - MSFT
    - NVDA

steps:
  - step_id: fetch-prices
    name: Fetch prices
    kind: http
    command:
      method: GET
      url: "{{ .context.market_api_url }}/quotes?symbols=AAPL,MSFT,NVDA"
      headers:
        X-API-Key: secret://MARKET_DATA_API_KEY

  - step_id: select-close
    name: Select close prices
    kind: data-json
    dependencies:
      - fetch-prices
    command:
      from_step: fetch-prices
      path: ".quotes"

  - step_id: publish-brief
    name: Publish brief
    kind: http
    dependencies:
      - select-close
    command:
      method: POST
      url: https://dashboard.example.com/api/market-briefs
      body: "{{ index .steps \"select-close\" \"output\" }}"

Remplacez team-local par l’identifiant de votre équipe, configurez les points de terminaison API et créez MARKET_DATA_API_KEY dans les secrets Adios avant de déployer cet exemple. L’API source attend un en-tête X-API-Key ; sa destination reçoit les citations sélectionnées en JSON. La planification se répète toutes les 24 heures. Supprimez triggers pour un test uniquement manuel avant d’activer l’envoi récurrent.

Déclencheurs et planification

  • Manuel : omettez triggers et lancez une exécution depuis Workflows.
  • Webhook : utilisez type: webhook et un nom d’événement, par exemple order.created. Les données de l’événement entrant sont disponibles sous .payload.
  • Événement : utilisez type: event et le nom de l’événement interne doivent correspondre.
  • Intervalle: utilisez type: schedule avec une durée positive telle que interval: 1h ou interval: 24h.
  • Cron: le planificateur actuel prend en charge @every 1h, * * * * *, ainsi que des intervalles en minutes, par exemple */5 * * * *. Il n’évalue pas les expressions cron générales fondées sur le calendrier, telles que 0 8 * * *.

Les intervalles mesurent le temps écoulé ; ils ne sont pas alignés sur une heure fixe. Une planification nouvellement détectée peut s’exécuter au prochain contrôle du planificateur. Redémarrer celui-ci réinitialise son suivi des intervalles en mémoire. Bien que timezone et concurrency sont des champs acceptés dans le manifeste, mais le planificateur actuel ne les applique pas. Ne comptez pas sur concurrency: forbid pour éviter que plusieurs exécutions se chevauchent.

Pour une heure locale fixe, utilisez un planificateur externe qui envoie un webhook. Si une répétition risque de dupliquer des rapports ou des écritures, mettez en place une déduplication dans votre application ou à destination.

Les dix actions prises en charge

Chaque étape possède un identifiant unique step_id, une kind, et éventuellement dependencies et command. La configuration ci-dessous décrit l’exécution sur la plateforme. Le moteur d’exécution de la CLI locale ne prend en charge qu’une partie de ces actions.

http — Appeler une API

Définissez command.method, url, avec un champ facultatif headers, et body. Le corps de la réponse devient la sortie de l’étape. Utilisez le champ .output pour transmettre du JSON sous forme de texte. Consultez le bloc exemple de webhook.

- step_id: deliver
  kind: http
  dependencies: [order]
  command:
    method: POST
    url: https://api.example.com/orders
    headers:
      X-API-Key: secret://API_TOKEN
    body: "{{ .steps.order.output }}"

request-parser — Extraire les champs de requête

Utiliser command.extract pour construire un objet à partir de sélecteurs comme .payload.order, ou command.path pour sélectionner une valeur. Les métadonnées de la requête, lorsqu’elles sont fournies par le déclencheur, sont accessibles sous .request. L'extraction ne valide pas un schéma.

- step_id: parse
  kind: request-parser
  command:
    extract:
      order: .payload.order

data-json — Sélectionner des valeurs JSON

Utiliser command.from_step avec l'identifiant de l'étape source et path avec la valeur à sélectionner. path: . conserve toute la valeur; .rows[0].orders sélectionne un champ à partir de la première ligne. Vous pouvez également fournir command.input ; sans source, l’action utilise les données de l’exécution. Il s’agit d’un sélecteur, pas d’un moteur d’expressions jq.

bash — Exécuter les commandes shell

Mettez le script dans command: | et son environnement dans le bloc env. Le worker de workflow l’exécute et capture stdout comme sortie de l’étape. Utilisez une sortie stdout en JSON lorsqu’une autre étape a besoin de données structurées.

python — Exécuter un script Python

Utilisez la même structure command et le champ d’étape env comme pour Bash. Lisez les variables avec os.environ et affiche le résultat. Le exemple de script transmet du JSON de Bash à Python et calcule un total de 97 sans identifiants externes.

sql — Interroger PostgreSQL ou MySQL

Définissez command.driver à postgres ou mysql, dsn à un secret de connexion, et query à SQL. Les requêtes de lecture renvoient columns, rows, et row_count, avec un maximum de 100 lignes. Les requêtes qui modifient des données nécessitent write: true et renvoyer rows_affected. Consultez le bloc exemple de rapport.

email — Envoyer un message

Définissez command.provider, from, to, subject, et text ou html, ainsi que les identifiants du fournisseur. Les fournisseurs pris en charge sont smtp, sendgrid, postmark, mailgun, brevo, mailjet, et mailchimp-transactional (également mandrill). SMTP utilise host, port, username, et password; SendGrid utilise api_key. Les autres fournisseurs exigent leurs propres champs d’identifiants et de domaine. Le champ exemple de rapport présente la configuration de SendGrid. Une action réussie confirme l’envoi au fournisseur, sans garantir la livraison dans la boîte de réception.

s3 — Gérer un objet

Définissez command.operation à put, get, head (ou stat), ou delete. Configurez endpoint sous forme de nom d’hôte sans protocole d’URL, region, use_ssl, access_key, secret_key, bucket, et key. Pour les imports, fournissez body et, éventuellement, content_type. Utilisez un bucket existant. Le bloc Exemple d'instantané écrit du JSON sous une clé contenant l’identifiant d’exécution.

wait — Suspendre pour une approbation humaine

Une étape wait crée une demande d’approbation en attente et suspend l’exécution. L’approbation permet aux étapes dépendantes de continuer. Le rejet fait échouer l’étape et arrête l’exécution ; sans réponse, l’approbation reste en attente. Aucun champ de commande ne permet de définir un délai d’attente, d’attribuer un réviseur ou de prévoir une expiration automatique.

- step_id: approve
  kind: wait
  dependencies: [draft]

Faites dépendre l’action protégée de approve. Consultez le bloc exemple d’approbation pour le parcours complet.

agent — Exécuter un agent IA configuré

Une action agent nécessite un identifiant fixé agent_binding_id, agent_binding_revision_id, agent_binding_revision_digest, et workspace_id dans command. L’empreinte doit être sha256: suivi de 64 caractères hexadécimaux. Utilisez les valeurs exactes de la révision de liaison configurée, puis définissez input à la tâche. Le workflow attend que l'agent termine avant de continuer.

La sortie est l’enveloppe de résultat de l’agent au format JSON, comprenant les informations d’exécution et les résultats ; elle ne se limite pas au texte du brouillon. Examinez-la avant de sélectionner un champ ou de transmettre le résultat complet. Le champ exemple d’approbation affiche tous les champs requis.

Dépendances et sorties des étapes

Listez les identifiants des étapes préalables dans dependencies et placez ces étapes plus tôt dans le manifeste. Si une dépendance échoue, l’action qui en dépend ne s’exécute pas. L’environnement d’exécution actuel exécute les étapes de manière séquentielle ; déclarer des étapes indépendantes ne les fait pas fonctionner en parallèle.

Les modèles utilisent la syntaxe des templates Go. Voici quelques valeurs utiles :

  • {{ .context.destination_url }} pour la configuration partagée.
  • {{ .steps.report.output }} pour la chaîne de sortie brute d’une étape, adaptée à un corps JSON.
  • {{ .steps.count.value }} pour sa valeur analysée, adaptée à l’insertion d’un scalaire dans du texte.
  • {{ index .steps "fetch-prices" "output" }} pour un identifiant contenant un trait d’union.
  • {{ .run.ID }} pour l’identifiant de l’exécution actuelle.

Utiliser .output pour transmettre un objet JSON complet sous forme de texte. Le rendu d’un objet analysé via .value ne l’encode pas en JSON. Pour sélectionner un élément d’un tableau, utilisez des chemins tels que .rows[0].orders dans une data-json.

Secrets et variables d'environnement

Pour les actions HTTP, SQL, e-mail et S3, placez secret://NAME directement dans le champ de commande qui a besoin de la valeur. La référence doit occuper l'ensemble du champ: X-API-Key: secret://API_TOKEN est résolu, mais Authorization: "Bearer secret://API_TOKEN" est envoyé tel quel. Pour une authentification bearer, stockez la valeur complète de l’en-tête Bearer … dans un secret et utilisez Authorization: secret://API_AUTHORIZATION.

Les actions Bash et Python reçoivent les variables d’environnement via le champ env de l’étape. Le worker résout les références aux secrets avant de lancer le script :

steps:
  - step_id: fetch
    kind: python
    env:
      API_TOKEN: secret://API_TOKEN
      API_URL: https://api.example.com/data
    command: |
      import os
      import urllib.request

      request = urllib.request.Request(
          os.environ["API_URL"],
          headers={"Authorization": "Bearer " + os.environ["API_TOKEN"]},
      )
      with urllib.request.urlopen(request, timeout=30) as response:
          print(response.read().decode())

Le bloc de premier niveau secrets est conservé par le modèle de données, mais l’environnement d’exécution actuel ne l’utilise pas pour remplir les environnements des étapes ni résoudre des alias. Il n’est nécessaire pour aucun des deux exemples ci-dessus. Les modèles d’étapes peuvent lire le contexte du workflow, les données du déclencheur et de la requête, ainsi que les sorties des étapes précédentes.

Créer et inspecter une exécution

Créez ou appliquez ce manifeste depuis l’éditeur de workflows, l’agent IA ou la CLI des workflows. Le moteur d’exécution local de la CLI permet des vérifications simples en développement, mais ne prend en charge qu’une partie des types d’étapes de la plateforme.

adios workflow deploy ./workflows/daily-market-brief.yaml

Commencez par une exécution manuelle et des données d’exemple. Vérifiez le statut, la sortie et l’erreur de chaque étape dans Workflows avant de connecter une source d’événements réelle ou une planification récurrente. Pour les approbations, testez l’acceptation et le rejet, puis vérifiez que l’étape protégée reste en attente jusqu’à la décision.

Utiliser timeout_seconds sur les étapes HTTP, script, SQL ou agent lorsque la valeur par défaut ne convient pas. Les étapes HTTP, script et SQL ont un délai par défaut de 30 secondes ; les étapes agent, de 30 minutes. Une étape d’attente dépend de son état d’approbation, et non de ce délai.