Workflows — exécutions & exemples - Solya Docs

Exécutions

Chaque exécution est une exécution de workflow.

Champ	Signification
`status`	`PENDING → RUNNING → COMPLETED / FAILED / CANCELLED`.
`triggeredAt` / `completedAt`	Horodatages de début et terminal.
`triggerContext`	`{ entityType, matchedEntityIds, includeTags, excludeTags }` — ce que le déclencheur a appareillé.
`outputSummary`	Compteurs agrégés : `totalPlansCreated`, `totalItemsAdded`, `totalItemsSkipped`, `totalErrorsRecorded`.
`errorMessage`	Raison d’erreur terminal, si échouée.

Étapes

Chaque nœud produit une étape d’exécution, vous pouvez donc voir exactement ce qui s’est passé à chaque nœud.

Champ	Signification
`nodeId` / `nodeType` / `actionType`	Quel nœud a été exécuté.
`status`	`PENDING` · `RUNNING` · `SUCCEEDED` · `FAILED` · `SKIPPED` · `CANCELLED`.
`startedAt` / `completedAt` / `durationMs`	Chronométrage.
`resolvedInput`	La config du nœud après interpolation — ce qui a réellement été exécuté.
`output`	La sortie du nœud (alimente `{{steps.<nodeId>.output.*}}`).
`errorMessage` / `errorCode` / `errorDetails`	Détail de l’échec.
`retryCount`	Numéro de tentative.
`logs`	Journaux par étape.

Les étapes sont clés de manière unique par (workflowRunId, nodeId), la plateforme données peut donc retenter une exécution de manière idempotente sans dupliquer les enregistrements d’étape. Une étape SKIPPED est intentionnelle (par ex. un filtre ne correspondait à rien ou une fenêtre de démarque n’était pas active).

Exemple complet

Une automatisation minimale de réassort : quand un PRODUCT est étiqueté, créer un plan de réassort et ajouter 10 unités de chaque article.

{
  "nodes": [
    {
      "id": "n-trigger",
      "type": "trigger",
      "position": { "x": 0, "y": 0 },
      "data": { "nodeType": "TRIGGER", "entityType": "PRODUCT", "includeTags": ["fast-mover"], "excludeTags": [] }
    },
    {
      "id": "n-create",
      "type": "createPlan",
      "position": { "x": 250, "y": 0 },
      "data": {
        "nodeType": "ACTION",
        "actionType": "CREATE_OR_GET_PLAN",
        "planType": "RESTOCK",
        "brandSource": { "kind": "fromTrigger" },
        "collectionSource": { "kind": "fromTrigger" },
        "deadline": { "kind": "relative", "offsetDays": 30 }
      }
    },
    {
      "id": "n-add",
      "type": "addItems",
      "position": { "x": 500, "y": 0 },
      "data": {
        "nodeType": "ACTION",
        "actionType": "ADD_ITEMS_TO_PLAN",
        "planType": "RESTOCK",
        "sourcePlanNodeId": "n-create",
        "quantityStrategy": { "kind": "fixed", "quantity": 10 },
        "shopScope": { "kind": "all" },
        "sizeScope": { "kind": "all" }
      }
    },
    {
      "id": "n-email",
      "type": "sendEmail",
      "position": { "x": 750, "y": 0 },
      "data": {
        "nodeType": "ACTION",
        "actionType": "SEND_EMAIL",
        "to": ["buyer@example.com"],
        "cc": [], "bcc": [],
        "fromAddress": "no-reply@solya.app",
        "fromName": "Solya",
        "subject": "Restock plan {{steps.n-create.output.planName}} ready",
        "bodyFormat": "markdown",
        "bodyTemplate": "Added **{{steps.n-add.output.addedCount}}** items to plan {{steps.n-create.output.planId}}."
      }
    }
  ],
  "edges": [
    { "id": "e1", "source": "n-trigger", "target": "n-create" },
    { "id": "e2", "source": "n-create",  "target": "n-add" },
    { "id": "e3", "source": "n-add",     "target": "n-email" }
  ]
}

Ce qu’il faut remarquer

Le déclencheur appareille les entités PRODUCT étiquetées fast-mover.
Le nœud créer-plan dérive la marque et la collection fromTrigger, avec une date limite relative de 30 jours.
Le nœud ajouter-articles référence le nœud créer-plan via sourcePlanNodeId et ajoute 10 unités fixes dans tous les magasins et tailles.
Le nœud e-mail interpole le nom du plan, le nombre d’articles ajoutés et l’id du plan à partir des sorties des deux étapes antérieures.