Workflows

Liest die Workflow-Automatisierungen einer Einrichtung: die Workflows, den vollständigen Graphen eines Workflows, die in einem Graphen verwendbaren Knotentypen und kuratierte Vorlagen. Lesen Sie node_types, bevor Sie einen Graphen erstellen oder bearbeiten, damit jeder Typ und Parameter an der Einrichtung gültig ist.

Aktionen:

• list: Workflows auflisten. Jeder Workflow mit Live-Status, veröffentlichter Version, Anzahl der Ausführungen, letzter Ausführung und seinen Knoten (id, name, type). Workflows von Marken und der Organisation werden nicht aufgeführt.
• get: Workflow abrufen. Der vollständige Entwurfsgraph (nodes, connections, notes, settings) und meta: active, publishedVersionId und nach der Veröffentlichung publishedWorkflow, der aktuell live geschaltete Graph. Nur Workflows dieser Einrichtung. Erfordert workflowId.
• node_types: Knotentypen. Palettenelemente mit type, label, category, outputs (Verzweigungen) und inputSchema, den auszufüllenden Parametern. available ist false, mit Begründung, wenn der Einrichtung ein vom Knoten benötigtes Modul fehlt. MCP-Tools erscheinen als mcp..-Knoten.
• templates: Vorlagen. Ausgangspunkte für gängige Automatisierungen mit risk und riskNote (was bei unbedachter Veröffentlichung schiefgehen kann), Knotentypen, erforderlichen Modulen, Verfügbarkeit an dieser Einrichtung und einem Vorschaugraphen. Wandeln Sie eine Vorlage mit workflow_definitions_write instantiate_template in einen Graphen um.

Erstellt, bearbeitet, veröffentlicht, stoppt und löscht die Workflow-Automatisierungen einer Einrichtung. Ablauf beim Erstellen: Lesen Sie node_types mit workflow_definitions_read, bauen Sie den Graphen (oder beginnen Sie mit instantiate_template), legen Sie ihn als Entwurf an, testen Sie ihn mit workflow_runs_write test (simuliert) und veröffentlichen Sie ihn dann. Änderungen an einem Entwurf wirken sich erst nach der Veröffentlichung auf die Live-Version aus.

Aktionen:

• create: Workflow erstellen. Speichert einen neuen, inaktiven Entwurf aus einem vollständigen Graphen mit mindestens einem Knoten; name ist standardmäßig "Untitled workflow". Validierungsprobleme werden in errors mit Knotendetails zurückgegeben. Erfordert nodes.
• update: Entwurf speichern. Ersetzt den gesamten Entwurf: Senden Sie jeden Knoten und jede Verbindung, nicht nur die Änderungen. Die Live-Version läuft weiter, bis Sie veröffentlichen. Validierungsprobleme werden in errors mit Knotendetails zurückgegeben. Erfordert workflowId, nodes.
• patch_meta: Umbenennen. Ändert nur Name oder Beschreibung; der Graph und die Live-Version bleiben unverändert. changed ist false, wenn beide bereits übereinstimmen. Erfordert workflowId.
• duplicate: Duplizieren. Kopiert einen Workflow in einen neuen Entwurf namens " (copy)" mit neuen Knoten-IDs, nie veröffentlicht oder aktiv. Das Original bleibt unverändert. Erfordert workflowId.
• delete: Löschen. Löscht den Workflow endgültig: Entwurf, veröffentlichte Versionen, Ausführungsverlauf und Trigger-Routing. set_active false stoppt ihn, behält ihn aber; discard_draft setzt nur Entwurfsänderungen zurück. Erfordert workflowId. Fordert eine Bestätigung an.
• discard_draft: Entwurfsänderungen verwerfen. Setzt den Entwurf auf die zuletzt veröffentlichte Version zurück und verwirft seitdem vorgenommene Änderungen. Die Live-Version ist nie betroffen; erfordert eine veröffentlichte Version. Erfordert workflowId. Fordert eine Bestätigung an.
• publish: Veröffentlichen. Validiert den Entwurf, speichert ihn als Live-Version und aktiviert den Workflow, sodass seine Trigger auslösen und seine Aktionen tatsächlich ausgeführt werden. Laufende Ausführungen werden mit der alten Version beendet. Würden wartende Delay-Schritte zeitlich neu angesetzt, enthält das Ergebnis den Code WAIT_RETARGET_CONFIRMATION_REQUIRED und impacts: Rufen Sie erneut mit confirmWaitRetargets und diesen impacts auf. Erfordert workflowId. Fordert eine Bestätigung an.
• set_active: Ein- oder ausschalten. active true schaltet einen veröffentlichten Workflow wieder ein. active false stoppt ihn: Trigger lösen nicht mehr aus, und ausstehende Delay-Schritte werden abgebrochen, sodass sie nie abgeschlossen werden. Es wird nichts gelöscht. Fragt zuerst nach, sofern er sich nicht bereits in diesem Zustand befindet. Erfordert workflowId, active. Fordert ggf. eine Bestätigung an.
• instantiate_template: Graph aus Vorlage. Wandelt eine Vorlage in einen Graphen um, der für create bereit ist: { name, description, nodes, connections } mit neuen Knoten-IDs. Vorlagen lassen Empfänger, Türen und Zeiten bewusst leer; füllen Sie diese zuerst aus. Speichert nichts. Erfordert templateId.
• generate: Graph generieren. Erstellt mit der KI der Einrichtung einen Graphen aus einem Prompt in natürlicher Sprache und gibt { name, description, nodes, connections } zurück, nur mit gültigen Knotentypen. Übergeben Sie workflow, um einen bestehenden zu überarbeiten; der vollständige überarbeitete Graph wird zurückgegeben. Speichert nichts, verbraucht aber KI-Guthaben der Einrichtung. Erfordert prompt. Fordert eine Bestätigung an.

Der Ausführungsverlauf eines Workflows, neueste zuerst, und eine einzelne Ausführung Schritt für Schritt. Damit prüfen Sie, ob eine Automatisierung gelaufen ist, verfolgen eine mit workflow_runs_write gestartete Ausführung oder finden heraus, welcher Knoten warum fehlgeschlagen ist.

Aktionen:

• list: Ausführungen auflisten. Jede Ausführung mit Status, Modus (live oder test), Nebenwirkungen, Trigger, Auslöser, Zeiten, Schrittanzahl, dem Knoten, auf den sie wartet, und etwaigen Fehlern. Erfordert workflowId.
• get: Ausführung abrufen. Der Status der Ausführung und jeder Schritt der Reihe nach, mit Eingabe, Ausgabe, Notiz und Fehler jedes Knotens. Ausführungen sind asynchron: Eine Ausführung mit Delays wartet, bis ihre Fortsetzung fällig ist. Erfordert workflowId, executionId.

Startet, testet, bricht ab und wiederholt Workflow-Ausführungen. Bevorzugen Sie test, das den Entwurf mit simulierten Nebenwirkungen ausführt; run führt den veröffentlichten Workflow tatsächlich aus. Ausführungen sind asynchron: Verfolgen Sie sie mit workflow_runs_read get.

Aktionen:

• run: Jetzt ausführen. Führt den veröffentlichten Workflow über seinen manuellen Trigger (custom.manualTrigger) mit echten Nebenwirkungen aus. Geplante, Webhook- und Ereignis-Trigger lösen selbstständig aus. Gibt die executionId der Ausführung und den ersten Status zurück. Erfordert workflowId. Fordert eine Bestätigung an.
• test: Entwurf testen. Führt den gespeicherten Entwurf aus, ohne ihn zu veröffentlichen, und erfasst dies als Testausführung. Nebenwirkungen werden standardmäßig simuliert: Es wird nichts gesendet oder geschaltet, und jeder Knoten meldet, was er getan hätte. Bei sideEffects live wird zuerst nachgefragt. Erfordert workflowId. Fordert ggf. eine Bestätigung an.
• cancel: Wartende Ausführung abbrechen. Bricht eine Ausführung ab, die auf ein Delay wartet: Ihre ausstehenden Wartezeiten werden geschlossen, und die nachfolgenden Schritte werden nie ausgeführt. Abgeschlossene Ausführungen und Ausführungen mitten in einem Schritt können nicht abgebrochen werden. Erfordert workflowId, executionId. Fordert eine Bestätigung an.
• retry: Ausführung wiederholen. Wiederholt eine abgeschlossene Ausführung mit ihrer erfassten Trigger-Eingabe, über retryOf zurückverknüpft. published (Standard) führt die damals verwendete Version erneut tatsächlich aus und fragt zuerst nach; draft-test führt den aktuellen Entwurf simuliert aus, die richtige Wahl beim Beheben eines Fehlers. Erfordert workflowId, executionId. Fordert ggf. eine Bestätigung an.