Schlafen
Verwende den Schlafen-Schritt, um einen Flow für eine konfigurierte Zeit zu pausieren, bevor der nächste Schritt läuft. Er ist das richtige Werkzeug, wenn ein nachgelagertes System Zeit zum Reagieren braucht oder ausgehende Aufrufe gedrosselt werden sollen.
Typische Anwendungsfälle:
- Ausgehende Aufrufe drosseln. Setze ein kurzes Schlafen zwischen HTTP-Anfragen, um unter dem Rate-Limit eines externen Systems zu bleiben.
- Externem System Zeit zum Verarbeiten geben. Eine Anfrage senden, schlafen, dann einen nachgelagerten Schritt laufen lassen, der das Ergebnis abfragt, sobald das externe System es bereitgestellt hat.
Schritt konfigurieren
Öffne den Flow-Editor, füge Schlafen hinzu und fülle die Konfigurationskarte aus.
Beschreibung
- Zweck: Verdeutliche, warum diese Pause im Flow existiert.
- Wann ausfüllen: Immer. Die Beschreibung wird im Editor und im Ausführungsverlauf angezeigt.
- Tipps: Nenne sowohl die Absicht als auch die Größenordnung, zum Beispiel
30 s warten, bis ERP committet hatoderDHL-Aufrufe drosseln.
Dauer
- Zweck: Wie lange der Flow pausieren soll.
- Wann ausfüllen: Erforderlich. Verwende eine positive ganze Zahl oder ein SmartField-Token, um den Wert aus einem vorherigen Schritt zu lesen (zum Beispiel
{{retryDelay}}). - Tipps: SmartField-Tokens werden beim Ausführen des Schritts aufgelöst — derselbe Schritt kann pro Ausführung unterschiedlich lange warten.
Einheit
- Zweck: Die Einheit, die auf den Wert in Dauer angewendet wird.
- Wann ausfüllen: Erforderlich. Wähle Millisekunden, Sekunden (Standard), Minuten oder Stunden.
- Tipps: Wähle die kleinste Einheit, die passt — kurze Millisekunden-Pausen bleiben in-process und sind günstig; Minuten- und Stunden-Pausen geben den Worker frei (siehe Verhalten).
Verhalten
Schlafen erzeugt keine Ausgaben. Was intern passiert, hängt von Dauer und Einheit ab:
- In-process — Bei Einheit Millisekunden und Dauer unter 10 000 ms wird der Worker für diese Zeit blockiert; der nächste Schritt läuft anschließend direkt weiter. Kein Job-Queue-Overhead.
- Verzögert — In allen anderen Fällen (Sekunden, Minuten, Stunden oder ≥ 10 000 ms in Millisekunden) wird die laufende Ausführung committet und ein neuer Single-Run-Job-Queue-Entry mit dem berechneten Wiederaufnahmezeitpunkt eingeplant. Der aktuelle Lauf endet; sobald die Job Queue den Eintrag feuert, ruft die Engine denselben Schlafen-Schritt erneut auf, der sofort zurückkehrt und den Flow weiterlaufen lässt.
Jedes verzögerte Schlafen, das gerade wartet, belegt einen Job-Queue-Entry. Flows mit vielen gleichzeitig schlafenden Ausführungen belegen entsprechend viele parallele Einträge.
Einschränkungen
- Nur auf dem Job-Queue-Pfad. Schlafen ist auf die Job Queue angewiesen, um die Ausführung wieder aufzunehmen. Der Schritt darf nur in Flows verwendet werden, die aus einem Job-Queue-Entry laufen — also dem normalen asynchronen Pfad. Verwende Schlafen nicht innerhalb eines SubFlows oder in der synchronen Phase eines Webhook-Triggers — die Engine kann dort nicht verzögern. Eine Validator-Erzwingung dieser Einschränkung wird separat unter CHN-119 (SubFlows) und CHN-123 (Webhooks) verfolgt.
- Frühestens, nicht exakt. Die konfigurierte Zeit ist der frühestmögliche Startzeitpunkt des Wiederaufnahme-Job-Queue-Entries. Der tatsächliche Aufwachzeitpunkt hängt vom Durchsatz der Job Queue ab und kann später liegen, wenn die Queue ausgelastet ist.
Best Practices
- Einheit zur Wartezeit passend wählen. Verwende Millisekunden nur, wenn du wirklich eine Sub-Sekunden-Pause brauchst — sie blockiert den Worker. Für längere Pausen wähle Sekunden, Minuten oder Stunden, damit der Worker während der Wartezeit frei ist.
- Schleifen explizit machen. Für Polling-Muster (Aufruf → Schlafen → Aufruf wiederholen) baue die Schleife mit einem Entscheidungs-Schritt, statt mehrere Schlafen-Schritte zu verketten. So bleibt die Absicht im Flow-Graphen sichtbar.
- Nicht für SubFlow-Wartezeiten verwenden. SubFlows laufen inline; der aufrufende Flow blockiert ohnehin, solange sie ausgeführt werden. Setze Schlafen nur zwischen Schritten im Hauptflow ein, wo eine Verzögerung sinnvoll ist.