Referenz der Knoten

Jede Art von Knoten, die ein Experiment enthalten kann, in den Gruppen des Hinzufügen-Menüs: Aktionen, Warteknoten, Emulation, Störungen, Daten, Prüfungen und Ablauf. Wie man sie hinzufügt und verdrahtet, steht in Der Editor; signallab nodes gibt denselben Katalog als JSON aus, für Skripte und Assistenten (Die Kommandozeile).

Diese Seite lesen

Jeder Knoten hat eine Tabelle seiner Felder:

• Feld ist der Name im Bereich der Eigenschaften; In der Datei ist der Schlüssel im JSON des Experiments.
• Standard ist, was ein Knoten erhält, wenn Sie ihn im Editor hinzufügen. Wo eine Datei einen Schlüssel weglassen darf, ist der Wert, den er dann annimmt, als falls nicht vorhanden angegeben; andere Schlüssel sind in einer Datei erforderlich.
• Vorlagen: ja — das Feld nimmt {{templates}}: Parameter, früher gesetzte Variablen, Geheimnisse und Generatoren, aufgelöst, während der Schritt läuft (Daten und Vorlagen). Nur Parameter — es wird vor dem ersten Schritt geöffnet, wenn nur Parameter bekannt sind. Nein — der Wert wird so genommen, wie er geschrieben ist.

Zeiten sind in Millisekunden. Grenzen werden vor dem Start eines Durchlaufs geprüft; ein Feld außerhalb des Bereichs hält das Experiment vom Laufen ab und wird am Knoten angezeigt.

Ein Knoten in einer Datei

In einer Experimentdatei ist ein Knoten ein Objekt mit einer id (eindeutig im Experiment), seinem type, seinem Platz auf der Arbeitsfläche (x, y, null oder mehr), seinen Feldern und den Einstellungen, die er verwendet (retry, repeat, load, weggelassen, wenn aus). Eine Verbindung ist eine Kante von einem Ausgang eines Knotens (port, next falls nicht vorhanden) zu einem anderen Knoten:

{
  "nodes": [
    { "id": "start", "type": "start", "x": 40, "y": 80 },
    { "id": "ping", "type": "udp", "x": 270, "y": 80, "target": "127.0.0.1:9000", "text": "PING",
      "retry": { "attempts": 3, "delay_ms": 500, "backoff": "fixed" } },
    { "id": "end", "type": "end", "x": 500, "y": 80 }
  ],
  "edges": [
    { "from": "start", "to": "ping", "port": "next" },
    { "from": "ping", "to": "end", "port": "next" }
  ]
}

Die Beispiele unten zeigen je einen Knoten, wie eine Datei ihn hält.

Von vielen Knoten geteilte Einstellungen

Diese werden im unteren Teil der Eigenschaften eines Knotens eingeschaltet. Welcher Knoten welche annimmt, steht unter jedem Knoten.

Einstellung	Nimmt sie	Was sie tut
Neuversuch	Knoten, die senden oder lauschen: HTTP-Anfrage, TCP-Nachricht, OSC-Nachricht, UDP-Datagramm, MQTT veröffentlichen, WebSocket verbinden, WebSocket senden, und jeden Warteknoten	Versucht es erneut, wenn der Schritt fehlschlägt
Wiederholung	Knoten, die senden: HTTP-Anfrage, TCP-Nachricht, OSC-Nachricht, UDP-Datagramm, MQTT veröffentlichen, WebSocket senden	Sendet immer wieder, eine Anzahl von Malen oder eine Zeit lang
Last	HTTP-Anfrage	Sendet die Anfrage nach einem Lastprofil, gemessen und an Schwellenwerten beurteilt
Auf eine Antwort warten	OSC-Nachricht, UDP-Datagramm	Sendet und wartet im selben Schritt auf die Antwort

Neuversuch

bei Fehler erneut versuchen: Wenn der Schritt fehlschlägt — keine Verbindung, eine Zeitüberschreitung, ein Warten ohne Treffer —, pausiert er und läuft erneut. Jeder fehlgeschlagene Versuch ist eine Zeile in der Zeitleiste; der Schritt schlägt fehl, wenn der letzte Versuch es tut. Eine Vorlage, die sich nicht auflösen lässt, wird nicht erneut versucht. Stoppen beendet auch eine Pause.

Feld	In der Datei	Was	Standard und Grenzen
Versuche	retry.attempts	Versuche insgesamt, der erste eingeschlossen	3; 2–10 im Editor (eine Datei darf auch 1 sagen)
Pause, ms	retry.delay_ms	Die Pause vor dem zweiten Versuch	500; 0–60 000
Pausen	retry.backoff	gleichbleibend (fixed): jede Pause gleich; verdoppelnd (exponential): nach jedem Fehlschlag doppelt so lang	fixed (auch falls nicht vorhanden)

Keine Pause ist länger als 60 Sekunden, wie sehr sie sich auch verdoppelt. Ein Warten, dessen Ausgang Timeout verdrahtet ist, schlägt bei einer Zeitüberschreitung nicht fehl — es geht durch diesen Ausgang —, wird dann also nicht erneut versucht.

Wiederholung

wiederholt senden: Der Knoten sendet immer wieder — ein Herzschlag, eine Abfrage, ein gleichmäßiger Strom —, ohne eine Schleife im Graphen. Jede Sendung liest ihre Vorlagen neu ({{counter}} ist ihre Nummer, {{now}} ihre Zeit), und Neuversuch, wenn an, gilt für jede Sendung. Der Schritt besteht, wenn jede Sendung es tat; eine Sendung, die endgültig fehlschlägt, lässt den Schritt fehlschlagen. Die Zeitleiste berichtet den Fortschritt höchstens einmal pro Sekunde.

Feld	In der Datei	Was	Standard und Grenzen
Wiederholen	repeat.until	nach Anzahl (count) oder nach Dauer (duration)	count (auch falls nicht vorhanden)
Anzahl	repeat.count	Sendungen insgesamt, die erste eingeschlossen	10 (auch falls nicht vorhanden); 2–10 000
Dauer, ms	repeat.duration_ms	Wie lange weiter gesendet wird, ab der ersten Sendung	10 000 (auch falls nicht vorhanden); 1–300 000
Intervall, ms	repeat.interval_ms	Die Pause zwischen zwei Sendungen	1 000; 10–60 000; in einer Datei erforderlich
Jitter, ms	repeat.jitter_ms	Jede Pause bis zu so viel länger, gezogen aus dem Startwert des Durchlaufs	0 (auch falls nicht vorhanden); 0–60 000

Die Wiederholungen müssen in die 300 Sekunden eines Durchlaufs passen, und eine Zeit lang muss weniger als 10 000 Sendungen brauchen (ihre Zeit geteilt durch das Intervall).

Last

unter Last senden, nur an einer HTTP-Anfrage: Die Anfrage wird nach einem Profil gesendet — eine konstante Rate, eine Rampe, Stufen, eine Spitze oder zufällige Ankünfte —, mit bis zu 512 gleichzeitig unterwegs (standardmäßig 32), und gemessen: Latenzen, Fehler, die erreichte Rate. Schwellenwerte entscheiden, ob der Schritt besteht. Last ersetzt Wiederholung und Neuversuch (eine fehlgeschlagene Anfrage wird gezählt, nicht erneut versucht) und hinterlässt keine Antwort für die Prüfungen danach. Ihre Felder und Ergebnisse stehen in Lasttests.

Auf eine Antwort warten

auf eine Antwort warten, an einer OSC-Nachricht oder einer UDP-Datagramm: Die Nachricht wird von dem Port gesendet, auf dem die Antwort erwartet wird, sodass ein Gerät, das dem Absender antwortet, gehört wird, und der Schritt besteht nur, wenn rechtzeitig eine passende Antwort eintrifft. Keine Antwort lässt den Schritt fehlschlagen — Neuversuch sendet erneut. Die Antwort wird in einer Variablen gespeichert, wie bei einem Warteknoten.

Feld	In der Datei	Was	Standard und Grenzen	Vorlagen
Antwort auf (IP:Port)	reply.bind	IP:port, von dem gesendet und auf dem gelauscht wird; Port 0 nimmt einen beliebigen freien Port	0.0.0.0:0	Nein
Adressmuster der Antwort (OSC)	reply.address	Das Adressmuster der Antwort, wie in Auf OSC warten	/*	Ja
Argumentregeln (OSC)	reply.args	Argumentregeln, wie in Auf OSC warten	keine; höchstens 16	Werte: ja
Nutzdaten der Antwort (UDP)	reply.mode	any, contains, regex oder hex — siehe Nutzdaten abgleichen	any (auch falls nicht vorhanden)	Nein
Muster (UDP)	reply.pattern	Was die Antwort enthalten oder worauf sie passen muss	leer; erforderlich außer bei any	Ja
Timeout, ms	reply.timeout_ms	Wie lange gewartet wird	2 000 (auch falls nicht vorhanden); 1–120 000	Nein
Antwortvariable	reply.variable	Die Variable, in die die Antwort geschrieben wird	reply (auch falls nicht vorhanden)	Nein

Der Port der Antwort wird vor dem ersten Schritt geöffnet, wie der eines Warteknotens.

Aktionen

Knoten, die senden. Ein Warten nach einer Aktion zählt Nachrichten ab dem Moment, in dem die Aktion begann.

HTTP-Anfrage

Sendet eine HTTP-Anfrage und behält die Antwort für die Prüfungen, Zweige und Knoten Wert extrahieren danach.

Feld	In der Datei	Was	Standard und Grenzen	Vorlagen
Methode	request.method	GET, HEAD, POST, PUT, PATCH, DELETE oder OPTIONS (eine Datei darf jede Methode nennen)	GET	Nein
URL	request.url	Eine http://- oder https://-URL	http://127.0.0.1:8080/	Ja
Timeout (ms)	request.timeout_ms	Für den ganzen Austausch	4 000 (10 000 falls nicht vorhanden); 1–120 000	Nein
Anfrage-Header	request.headers	[[name, value], …]; eine Zeile mit leerem Namen wird übersprungen	keine	Ja, Namen und Werte
Body	request.body	Text, oder null für keinen	null	Ja
Authentifizierung	request.auth	Keine, Basic, Bearer-Token oder Digest, mit Benutzername und Passwort, oder Token	keine	Ja

• Jede Antwort lässt den Schritt bestehen, 404 und 500 eingeschlossen: Prüfen Sie den Status mit HTTP-Status oder verzweigen Sie mit Statusverzweigung darauf. Eine Anfrage, die keine Antwort erhält — abgelehnt, eine Zeitüberschreitung, ein Name, der sich nicht auflöst, ein Zertifikat, dem nicht vertraut wird —, lässt den Schritt fehlschlagen.
• Weiterleitungen werden verfolgt, höchstens zehn. https://-Zertifikate werden geprüft.
• Der Antwort-Body wird bis zu 256 KiB für die Prüfungen behalten; ein größerer Body wird dort abgeschnitten (die Prüfungen sagen es, wenn das Gesuchte hinter dem Schnitt liegen könnte).
• Digest beantwortet die 401-Challenge des Servers und sendet die Anfrage erneut. Die Anmeldedaten gehen nur in die Anfrage: Schritte, Berichte und der Inspektor zeigen nie den Authorization-Header. Schreiben Sie ein Passwort als {{secret.NAME}}.
• Solange das Experiment Cookies behält (standardmäßig an, unter Parameter), wird, was Server setzen, mit den späteren Anfragen des Durchlaufs an sie zurückgesendet.

Ausgänge: Ausgang. Einstellungen: Neuversuch, Wiederholung, Last.

{ "id": "cue", "type": "http", "x": 270, "y": 80,
  "request": { "method": "POST", "url": "{{api}}/cue", "headers": [["Content-Type", "application/json"]],
               "body": "{\"cue\": 1}", "timeout_ms": 5000,
               "auth": { "scheme": "bearer", "token": "{{secret.API_TOKEN}}" } } }

Siehe auch HTTP.

TCP-Nachricht

Verbindet sich über TCP mit einem Host, schreibt die Nutzdaten, wartet bis zu 250 ms auf die ersten Bytes einer Antwort (es liest höchstens 1 024 Bytes, einmal) und schließt die Verbindung. Die Größe der Antwort wird berichtet, nicht geprüft.

Im Inspektor ist der Schritt zwei tcp-Frames mit der Quelle experiment: die geschriebenen Nutzdaten und, wenn eine kam, die gelesene Antwort. Verwendete Geheimnisse werden in beiden maskiert, wie in jedem Frame.

Feld	In der Datei	Was	Standard und Grenzen	Vorlagen
Host	host	Ein Hostname oder eine IP-Adresse	127.0.0.1	Ja
Port	port		9000; 1–65 535	Nein
Timeout (ms)	timeout_ms	Für Verbinden, Schreiben und die Antwort zusammen	4 000 (auch falls nicht vorhanden); 1–120 000	Nein
Nutzdaten	payload	Der Text, der nach dem Verbinden geschrieben wird, als UTF-8	hello	Ja

Der Schritt schlägt fehl, wenn die Verbindung abgelehnt wird, der Name sich nicht auflöst oder die Zeit abläuft. Ausgänge: Ausgang. Einstellungen: Neuversuch, Wiederholung. Jetzt senden verbindet sich und schreibt die Nutzdaten einmal, und das Ergebnis des Knotens sagt, wie viele Bytes gesendet wurden und zurückkamen.

{ "id": "go", "type": "tcp", "x": 270, "y": 80, "host": "127.0.0.1", "port": 5000, "payload": "GO\r\n", "timeout_ms": 2000 }

OSC-Nachricht

Sendet eine OSC-1.0-Nachricht über UDP.

Feld	In der Datei	Was	Standard und Grenzen	Vorlagen
Ziel Host:Port	target	IP:port oder host:port; ein Hostname wird beim Senden des Schritts aufgelöst, seine IPv4-Adresse genommen, wenn er eine hat	127.0.0.1:9000	Ja
OSC-Adresse	address	Beginnt mit /	/test	Ja
Argumente	args	[{ "type", "value" }, …] — int, float, str, long, double, bool, blob (Bytes), nil (kein Wert)	keine	Textwerte (str): ja
auf eine Antwort warten	reply	Optional: senden und auf die Antwort warten — siehe Auf eine Antwort warten	aus

Ausgänge: Ausgang; mit erwarteter Antwort wird er nur gefolgt, wenn die Antwort kam. Einstellungen: Neuversuch, Wiederholung, eine Antwort. ⚡ Über eine Störung leiten in seinen Eigenschaften stellt ihm eine Störung voran.

{ "id": "fader", "type": "osc", "x": 270, "y": 80, "target": "{{device}}", "address": "/fader/1",
  "args": [{ "type": "float", "value": 0.75 }] }

Siehe auch OSC.

UDP-Datagramm

Sendet eine Textnutzlast als ein UDP-Datagramm an ein oder mehrere Ziele.

Feld	In der Datei	Was	Standard und Grenzen	Vorlagen
Ziel Host:Port	target	IP:port oder host:port; mehrere durch Kommas, Semikolons oder Zeilenumbrüche getrennte erhalten je das Datagramm. Ein Hostname wird beim Senden des Schritts aufgelöst, seine IPv4-Adresse genommen, wenn er eine hat	127.0.0.1:9000	Ja
Nutzdaten	text	Die Nutzdaten, als UTF-8	hello; höchstens 65 507 Bytes	Ja
auf eine Antwort warten	reply	Optional: senden und auf die Antwort warten — siehe Auf eine Antwort warten	aus

Der Schritt schlägt fehl, wenn ein Ziel nicht erreichbar ist. Ausgänge: Ausgang. Einstellungen: Neuversuch, Wiederholung, eine Antwort.

{ "id": "ping", "type": "udp", "x": 270, "y": 80, "target": "{{device}}", "text": "PING {{run.id}}",
  "reply": { "bind": "0.0.0.0:0", "mode": "contains", "pattern": "PONG", "timeout_ms": 1000, "variable": "pong" } }

MQTT-Veröffentlichung

Verbindet sich mit einem MQTT-Broker, veröffentlicht eine Nachricht und trennt sich. Die Verbindung ist MQTT 3.1.1 über einfaches TCP, mit sauberer Sitzung und ohne Benutzername oder Passwort. Verbinden, Veröffentlichen und die Bestätigung des Brokers müssen alle innerhalb von 15 Sekunden geschehen.

Feld	In der Datei	Was	Standard und Grenzen	Vorlagen
Broker-Host	host	Der Hostname oder die Adresse des Brokers	127.0.0.1	Ja
Port	port		1883; 1–65 535	Nein
Topic	topic	Keine Wildcards (+, #)	lab/test	Ja
Nutzdaten	payload	Die Nachricht, als Text	hello	Ja
QoS	qos	0, 1 oder 2	0	Nein
Retain-Flag setzen	retain	true: Der Broker behält sie als Wert des Topics	false	Nein

Alle sechs Schlüssel sind in einer Datei erforderlich. Der Schritt schlägt fehl, wenn der Broker nicht erreichbar ist oder die Verbindung oder die Nachricht verweigert. Ausgänge: Ausgang. Einstellungen: Neuversuch, Wiederholung.

{ "id": "light", "type": "mqtt", "x": 270, "y": 80, "host": "{{broker}}", "port": 1883,
  "topic": "lab/light/1/set", "payload": "on", "qos": 1, "retain": false }

Siehe auch MQTT.

WebSocket verbinden

Öffnet einen WebSocket für den Rest des Durchlaufs oder bis zu einem WebSocket schließen. Was von da an eintrifft, wird für die Auf WebSocket warten-Schritte darauf behalten. URL und Header werden aufgelöst, wenn der Schritt läuft, sodass ein früher extrahiertes Token darin stehen kann. Erneut ausgeführt — in einer Schleife —, schließt er zuerst seine vorherige Verbindung und öffnet eine neue. Wenn der Durchlauf endet, wie auch immer, werden seine Verbindungen mit einem Close-Frame geschlossen.

Feld	In der Datei	Was	Standard und Grenzen	Vorlagen
URL	url	Eine ws://- oder wss://-URL	ws://127.0.0.1:9001/	Ja
Anfrage-Header	headers	[[name, value], …], mit der Upgrade-Anfrage gesendet	keine	Ja, Namen und Werte
Subprotokolle	protocols	Subprotokolle, die angeboten werden, in Reihenfolge der Präferenz; der Server wählt eines	keine	Nein
Timeout (ms)	timeout_ms	Für Verbinden und das Upgrade	5 000 (10 000 falls nicht vorhanden); 1–120 000	Nein

wss:// vertraut denselben Zertifikaten wie https://. Der Schritt schlägt fehl, wenn die Verbindung oder das Upgrade fehlschlägt; der Status des Servers steht im Grund. Ausgänge: Ausgang. Einstellungen: Neuversuch (keine Wiederholung).

{ "id": "socket", "type": "ws_connect", "x": 270, "y": 80, "url": "ws://127.0.0.1:9001/chat",
  "headers": [["Authorization", "Bearer {{token}}"]], "protocols": ["chat.v1"], "timeout_ms": 5000 }

Siehe auch WebSocket.

WebSocket senden

Sendet eine Nachricht auf der Verbindung, die ein WebSocket verbinden geöffnet hat.

Feld	In der Datei	Was	Standard und Grenzen	Vorlagen
Verbindung	connection	Die id eines WebSocket verbinden-Knotens dieses Experiments	der erste	Nein
Format	binary	Text (false) oder Binär (Hex) (true): Die Nutzdaten sind Bytes, als Hex geschrieben, de ad be ef	false (auch falls nicht vorhanden)	Nein
Nutzdaten	text	Die Nachricht	hello; höchstens 16 MiB	Ja

Der Connect muss auf seinem Pfad vor dem Senden kommen; ein Senden, dessen Verbindung nicht offen ist, schlägt fehl. Antworten zählen ab dem Moment, in dem die Nachricht geschrieben wird. Ausgänge: Ausgang. Einstellungen: Neuversuch, Wiederholung.

{ "id": "hello", "type": "ws_send", "x": 500, "y": 80, "connection": "socket",
  "text": "{\"type\":\"ping\",\"id\":\"{{uuid}}\"}", "binary": false }

WebSocket schließen

Schließt eine Verbindung mit einem Close-Handshake. Die Zeitleiste sagt, wer sie geschlossen hat: dieser Schritt, der Server früher (mit seinem Code) oder eine Verbindung, die abgerissen war.

Feld	In der Datei	Was	Standard und Grenzen	Vorlagen
Verbindung	connection	Die id eines WebSocket verbinden-Knotens	der erste	Nein
Schließcode	code	1000 (normal) oder 3000–4999 für einen eigenen einer Anwendung	1000 (auch falls nicht vorhanden)	Nein
Grund	reason	Wird mit dem Code gesendet	leer; höchstens 123 Bytes, nach den Vorlagen	Ja

Ausgänge: Ausgang. Keine Einstellungen.

{ "id": "bye", "type": "ws_close", "x": 960, "y": 80, "connection": "socket", "code": 1000, "reason": "done" }

Log-Marke

Schreibt eine Zeile in die Zeitleiste und den Bericht — einen Kontrollpunkt oder die Werte, die ein Durchlauf erreichte.

Feld	In der Datei	Was	Standard und Grenzen	Vorlagen
Nachricht	message	Der Text	Check point; höchstens 10 000 Zeichen	Ja

Ausgänge: Ausgang. Keine Einstellungen.

{ "id": "ready", "type": "log", "x": 500, "y": 80, "message": "device {{device}} ready" }

Warteknoten

Die Gruppe Beobachten: Knoten, die darauf warten, dass etwas eintrifft. Sie teilen diese Regeln:

• Sie lauschen vom Start des Durchlaufs an. Der Port oder das Broker-Abonnement eines Warteknotens wird vor dem ersten Schritt geöffnet, sodass ein Gerät, das schneller antwortet als der nächste Schritt beginnt, nicht verpasst wird. Zwei Warteknoten auf derselben Adresse teilen sich einen Socket.
• Sie zählen ab der letzten Aktion auf ihrem Zweig. Eine Nachricht, die vor der letzten Anfrage des Zweigs eintraf, ist keine Antwort darauf; vor jeder Aktion zählt alles seit dem Start des Durchlaufs.
• Die erste passende Nachricht wird genommen. Eine Nachricht, die ein Warteknoten genommen hat, wird von einem anderen nicht gesehen.
• Treffer oder Timeout. Bei einem Treffer wird die Nachricht in der Variablen des Warteknotens gespeichert und der Ablauf folgt Treffer. Wenn die Zeit abläuft, folgt er Timeout, wenn dieser Ausgang verdrahtet ist; andernfalls schlägt der Schritt fehl und sagt, wie viele andere Nachrichten eintrafen.
• Jeder Socket behält die neuesten 1 024 Nachrichten (und 64 MiB); ältere werden verworfen, und eine Zeitüberschreitung sagt, wie viele.
• Jetzt empfangen lauscht mit diesem einen Schritt, von jetzt an.

Ausgänge: Treffer (erforderlich), Timeout (optional). Einstellungen: Neuversuch.

Nutzdaten abgleichen

Auf UDP warten, Auf MQTT warten, Auf WebSocket warten und eine UDP-Antwort wählen, wie die Nutzdaten aussehen müssen:

Option	In der Datei	Passt, wenn die Nutzdaten
Beliebiges Datagramm	any	irgendetwas sind
Enthält Text	contains	als UTF-8-Text gelesen das Muster enthalten (Schreibweise beachtet)
Passt auf Regex	regex	als UTF-8-Text gelesen auf den regulären Ausdruck passen
Enthält Bytes (Hex)	hex	die Bytes enthalten, als Hex-Paare geschrieben: de ad be ef, deadbeef, 0xde,0xad, DE:AD

Die passende Nachricht wird als Objekt gespeichert. Spätere Schritte lesen ihre Felder als {{reply.text}} (mit dem Namen der Variablen anstelle von reply):

Feld	Was
text	Die Nutzdaten als Text
hex, bytes	Die Nutzdaten als Hex (ihre ersten 1 024 Bytes) und ihre Größe in Bytes
match	Was gepasst hat: der Text, die erste Gruppe des regulären Ausdrucks (oder der ganze Treffer) oder die Bytes
from	IP:port des Absenders
ms	Millisekunden von der letzten Aktion des Zweigs (oder dem Start des Durchlaufs) bis zur Nachricht
topic	Auf MQTT warten: das Topic, an das sie veröffentlicht wurde
json, kind	Auf WebSocket warten: die als JSON geparste Nachricht (null, wenn nicht), und text oder binary

Auf OSC warten

Wartet auf eine OSC-Nachricht, deren Adresse auf ein Muster passt und deren Argumente jede Regel erfüllen. In einem Bundle ist die erste passende Nachricht die genommene.

Feld	In der Datei	Was	Standard und Grenzen	Vorlagen
Empfang auf (IP:Port)	bind	IP:port, auf dem gelauscht wird; 0.0.0.0 für jede Netzwerkkarte	127.0.0.1:9001	Nein
Adressmuster	address	* beliebige Zeichen, ? eines, [0-9] eine Menge ([!0-9] außerhalb), {ping,pong} eines von beiden; Wildcards bleiben innerhalb eines /-Segments	/pong; höchstens 512 Zeichen	Ja
Argumentregeln	args	[{ "index", "op", "value" }, …]: Argument index wird mit value durch op verglichen (Vergleiche); alle müssen gelten	keine; höchstens 16, Index 0–63	Werte: ja
Timeout, ms	timeout_ms		2 000 (auch falls nicht vorhanden); 1–120 000	Nein
Antwortvariable	variable	Wo die Nachricht gespeichert wird	reply (auch falls nicht vorhanden)	Nein

Ein Argument wird als Text verglichen: Zahlen wie geschrieben, Zeichenketten ohne Anführungszeichen, true/false, ein Blob als Hex. Eine Regel zu einem Argument, das die Nachricht nicht hat, gilt nicht. Die gespeicherte Nachricht hat address, args ({{reply.args[0]}}), from und ms.

{ "id": "status", "type": "wait_osc", "x": 500, "y": 80, "bind": "0.0.0.0:9001", "address": "/status",
  "args": [{ "index": 0, "op": "eq", "value": "ready" }], "timeout_ms": 5000, "variable": "reply" }

Auf UDP warten

Wartet auf ein UDP-Datagramm, dessen Nutzdaten passen.

Feld	In der Datei	Was	Standard und Grenzen	Vorlagen
Empfang auf (IP:Port)	bind	IP:port, auf dem gelauscht wird	127.0.0.1:9001	Nein
Nutzdaten	mode	Siehe Nutzdaten abgleichen	contains (any falls nicht vorhanden)	Nein
Muster	pattern	Was die Nutzdaten enthalten oder worauf sie passen müssen	pong; erforderlich außer bei any	Ja
Timeout, ms	timeout_ms		2 000 (auch falls nicht vorhanden); 1–120 000	Nein
Antwortvariable	variable		reply (auch falls nicht vorhanden)	Nein

{ "id": "ready", "type": "wait_udp", "x": 500, "y": 80, "bind": "0.0.0.0:9002", "mode": "contains",
  "pattern": "READY", "timeout_ms": 5000, "variable": "reply" }

Auf MQTT warten

Wartet auf eine Nachricht, die an ein Topic bei einem Broker veröffentlicht wurde und deren Nutzdaten passen. Der Durchlauf verbindet sich und abonniert vor seinem ersten Schritt. Retained-Nachrichten, die der Broker beim Abonnieren erneut zustellt, werden ignoriert: Nur was nach dem Start des Durchlaufs veröffentlicht wird, zählt.

Feld	In der Datei	Was	Standard und Grenzen	Vorlagen
Broker-Host	host	Der Broker	127.0.0.1	Nur Parameter
Port	port		1883; 1–65 535	Nein
Topic-Filter	topic	Ein Filter: + ist genau eine Ebene, # alles darunter (nur zuletzt)	lab/#	Nur Parameter
Nutzdaten	mode	Siehe Nutzdaten abgleichen	any (auch falls nicht vorhanden)	Nein
Muster	pattern		leer; erforderlich außer bei any	Ja
Timeout, ms	timeout_ms		2 000 (auch falls nicht vorhanden); 1–120 000	Nein
Antwortvariable	variable		reply (auch falls nicht vorhanden)	Nein

{ "id": "state", "type": "wait_mqtt", "x": 500, "y": 80, "host": "{{broker}}", "port": 1883,
  "topic": "lab/+/state", "mode": "contains", "pattern": "on", "timeout_ms": 5000, "variable": "reply" }

Auf HTTP-Anfrage warten

Wartet auf eine HTTP-Anfrage — einen Webhook, einen Callback — an den Emulator des Durchlaufs auf dieser Adresse oder, wenn der Durchlauf dort keinen HTTP-Emulator hat, an einen eigenen Empfänger des Durchlaufs, der jede Anfrage mit 204 beantwortet. Die Anfrage muss zur Methode, zum Pfad und zu jeder Bedingung passen.

Feld	In der Datei	Was	Standard und Grenzen	Vorlagen
Empfang auf (IP:Port)	bind	IP:port	127.0.0.1:18080 — wo ein neuer Emulator lauscht	Nein
Methode	method	Eine Methode oder Beliebig (ANY); GET nimmt auch HEAD	ANY (auch falls nicht vorhanden)	Nein
Pfad	path	/hooks/:name benennt ein Segment ({{request.params.name}}); ein abschließendes /* nimmt den Rest	/* (auch falls nicht vorhanden); höchstens 512 Zeichen	Ja
Bedingungen	when	[{ "on", "name", "op", "value" }, …] zu einem header, einem query-Parameter, dem body oder einem json-Pfad; jede muss gelten	keine; höchstens 16	Ja, Namen und Werte
Timeout, ms	timeout_ms		5 000 (2 000 falls nicht vorhanden); 1–120 000	Nein
Antwortvariable	variable		request (auch falls nicht vorhanden)	Nein

Die gespeicherte Anfrage hat method, path, query, headers, body, json, params, from und ms: {{request.json.event}}, {{request.headers.x-key}}.

{ "id": "hook", "type": "wait_http", "x": 500, "y": 80, "bind": "127.0.0.1:18081", "method": "POST",
  "path": "/hooks/:name", "when": [{ "on": "json", "name": "$.event", "op": "eq", "value": "deploy" }],
  "timeout_ms": 5000, "variable": "request" }

Auf WebSocket warten

Wartet auf eine Nachricht auf der Verbindung, die ein WebSocket verbinden geöffnet hat, deren Nutzdaten passen. Nachrichten seit der letzten Aktion des Zweigs zählen — der Connect selbst, ein Senden oder jede andere Anfrage.

Feld	In der Datei	Was	Standard und Grenzen	Vorlagen
Verbindung	connection	Die id eines WebSocket verbinden-Knotens	der erste	Nein
Nutzdaten	mode	Siehe Nutzdaten abgleichen	any (auch falls nicht vorhanden)	Nein
Muster	pattern		leer; erforderlich außer bei any	Ja
Timeout, ms	timeout_ms		2 000 (auch falls nicht vorhanden); 1–120 000	Nein
Antwortvariable	variable		reply (auch falls nicht vorhanden)	Nein

Eine JSON-Nachricht ist Feld für Feld lesbar: {{reply.json.type}}. Der Connect muss auf seinem Pfad vor dem Warten kommen.

{ "id": "pong", "type": "wait_ws", "x": 730, "y": 80, "connection": "socket", "mode": "contains",
  "pattern": "pong", "timeout_ms": 3000, "variable": "reply" }

Emulation

Emulator

Spielt eine Abhängigkeit — eine HTTP-API, ein OSC-, UDP- oder TCP-Gerät, einen MQTT-Broker — für den ganzen Durchlauf. Er öffnet vor dem ersten Schritt und antwortet, bis der Durchlauf endet; im Ablauf besteht der Schritt sofort. Was er empfangen hat, wird Regel für Regel im Bericht des Durchlaufs gezählt.

Feld	In der Datei	Was	Standard
Bearbeiten…	emulator	Der Emulator: name, bind (IP:port), protocol (http, osc, udp, tcp, mqtt), seine Routen oder Regeln und ein optionaler outage	Eine HTTP-API namens API auf 127.0.0.1:18080, die /health beantwortet

Die Eigenschaften zeigen in einer Zeile, was er spielt. Bearbeiten… öffnet seine Regeln, denselben Editor wie in der Ansicht Emulatoren; In die Bibliothek behält eine Kopie in der Emulator-Bibliothek, und Aus der Bibliothek ersetzt diesen durch eine Kopie von dort. Die Regeln — Routen, Antworten, Fehlverhalten, Ausfälle — sind dort beschrieben.

• Ein HTTP-Emulator ist auch das, worauf ein Auf HTTP-Anfrage warten an seiner Adresse hört; ein OSC- oder UDP-Emulator teilt seinen Port mit den Warteknoten des Durchlaufs dort.
• Zwei Emulatoren eines Transports können sich in einem Durchlauf keinen Port teilen.
• Emulator aus/an schaltet ihn aus und wieder ein.

Ausgänge: Ausgang. Keine Einstellungen.

{ "id": "api", "type": "emulator", "x": 270, "y": 80,
  "emulator": { "name": "Orders API", "bind": "127.0.0.1:18080", "protocol": "http",
    "routes": [{ "method": "GET", "path": "/orders/:id", "order": "sequence",
                 "responses": [{ "status": 503 }, { "status": 200, "body": "{\"id\":\"{{request.params.id}}\"}" }] }] } }

Störungen

Knoten, die Dinge auf Kommando kaputtmachen. Ein Zweig aus Verzögerung-Knoten und diesen neben dem Verkehr liest sich als Zeitplan; Störungen nach Zeitplan zeigt, wie.

Störung

Ein Störungs-Relais für den ganzen Durchlauf: Das getestete System sendet an (oder verbindet sich mit) Empfang auf statt an das echte Ziel; das Relais leitet an Weiterleiten an weiter, und die Antworten kommen denselben Weg zurück, gestört durch das Profil. Es öffnet vor dem ersten Schritt und schließt, wenn der Durchlauf endet, wie auch immer, sodass nichts gestört bleibt; im Ablauf besteht der Schritt sofort. Jede Entscheidung zieht aus dem Startwert des Durchlaufs: Derselbe Startwert und derselbe Verkehr erleiden dasselbe Schicksal.

Feld	In der Datei	Was	Standard und Grenzen	Vorlagen
Empfang auf	listen	IP:port, an das das getestete System sendet	127.0.0.1:9010	Nur Parameter
Weiterleiten an	target	IP:port des echten Ziels oder host:port — ein Hostname wird beim Start des Durchlaufs aufgelöst, und ein Name, der nicht gefunden wird, stoppt den Durchlauf an diesem Knoten	127.0.0.1:9000	Nur Parameter
Protokoll	protocol	UDP (udp): jedes Datagramm erleidet sein eigenes Schicksal; TCP (tcp): jede Verbindung wird mit einer eigenen zum Ziel gekoppelt, und beide Ströme werden gestört	UDP (udp falls nicht vorhanden)	Nein
Vorgabe und die Werte darunter	profile	Was das Relais dem Verkehr antut — siehe Das Profil	LAN (keine Störung falls nicht vorhanden)	Nein

Die Lauschadresse eines Relais kann kein anderer Socket des Durchlaufs sein, und Relais dürfen nicht im Kreis zueinander weiterleiten. Ein per Name gegebenes Ziel wird verfolgt, sobald es aufgelöst ist, sodass ein Kreis über einen Namen den Durchlauf bei seinem Start stoppt. Der Bericht zählt jede Phase eines Relais einzeln.

Ausgänge: Ausgang. Keine Einstellungen.

{ "id": "relay", "type": "impairment", "x": 270, "y": 80, "listen": "127.0.0.1:9010", "target": "{{device}}",
  "profile": { "name": "lan", "latency_ms": 1, "jitter_ms": 1 } }

Das Profil

Ein Vorgabe-Chip — LAN, Volles WLAN, 4G, Satellit, Instabil, Offline — füllt jeden Wert aus; ändern Sie danach einen beliebigen davon. Ein Relais liest nur die Werte seines Protokolls; in einer Datei darf jeder Schlüssel weggelassen werden (null, aus).

Feld	In der Datei	Was	Grenzen	Protokoll
—	name	Eine Bezeichnung für die Zeitleiste und den Bericht: der Schlüssel einer Vorgabe (lan, wifi, 4g, satellite, intermittent, offline) oder eine eigene	höchstens 60 Zeichen	beide
Offline — nichts kommt durch	offline	Nichts kommt durch	true / false	beide
Latenz	latency_ms	Verzögerung, die jedem Paket oder Block eines Stroms hinzugefügt wird	0–60 000 (der Schieberegler geht bis 1 000)	beide
Jitter	jitter_ms	Eine zufällige zusätzliche Verzögerung bis zu so viel; ein TCP-Strom bleibt in der Reihenfolge	0–60 000 (der Schieberegler geht bis 500)	beide
Bandbreite, kbit/s	rate_kbps	Eine Bandbreitengrenze, 0 für keine. UDP: ab einer Sekunde Warteschlange werden Datagramme als gedrosselt verworfen; TCP: der Sender wird gebremst, nichts wird verworfen	0 oder 8–10 000 000	beide
Paketverlust	loss	Die Wahrscheinlichkeit, dass ein Datagramm verworfen wird	0–1 (der Schieberegler zeigt %)	UDP
Burst-Verlust, Burst-Länge, Datagramme	burst_start, burst_length	Die Wahrscheinlichkeit, dass ein Verlust-Burst beginnt, und wie viele Datagramme er im Mittel dauert	0–1; 1–1 000, wenn Bursts an sind	UDP
Duplizierung	duplicate	Die Wahrscheinlichkeit, dass ein Datagramm zweimal gesendet wird	0–1	UDP
Verfälschung	corrupt	Die Wahrscheinlichkeit, dass ein Bit eines Datagramms gekippt wird	0–1	UDP
Umordnung	reorder	Die Wahrscheinlichkeit, dass ein Datagramm zurückgehalten wird, sodass spätere es überholen	0–1	UDP
Verbindungs-Reset	reset	Die Wahrscheinlichkeit, dass ein Block eines Stroms stattdessen seine Verbindung zurücksetzt — beide Seiten erhalten ein Reset	0–1	TCP
Halboffen	stall	Die Wahrscheinlichkeit, dass ein Block seine Verbindung halboffen lässt: nichts geht mehr in beide Richtungen durch, und keiner Seite wird es gesagt	0–1	TCP

Mehr über Relais, Vorgaben und was sie modellieren auf der Seite Störung.

Störung ändern

Schaltet einen der Störung-Knoten des Durchlaufs ab diesem Schritt auf ein anderes Profil um, ohne seinen Port zu verlieren. Die bisherige Phase wird geschlossen und im Bericht gezählt.

Feld	In der Datei	Was	Standard	Vorlagen
Störung	relay	Die id eines Störung-Knotens dieses Experiments	der erste	Nein
Vorgabe und die Werte darunter	profile	Womit es von jetzt an stört — siehe Das Profil; das Relais liest die Werte seines eigenen Protokolls	Offline (keine Störung falls nicht vorhanden)	Nein

Der Schritt schlägt fehl, wenn das Relais nicht läuft — es konnte etwa nicht weiterleiten. Ausgänge: Ausgang. Keine Einstellungen.

{ "id": "cut", "type": "impairment_change", "x": 730, "y": 200, "relay": "relay",
  "profile": { "name": "offline", "offline": true } }

Emulator aus und an

Schaltet einen der Emulatoren des Durchlaufs aus oder wieder ein. Während er aus ist, antwortet ein HTTP-Emulator, wie Im Ausfall sagt; ein TCP-Gerät und ein MQTT-Broker trennen ihre Verbindungen und verweigern neue; OSC- und UDP-Geräte antworten nichts. Wieder an, folgt der Emulator seinem eigenen Ausfallplan, wenn er einen hat.

Feld	In der Datei	Was	Standard
Emulator	emulator	Die id eines Emulator-Knotens dieses Experiments	der erste
Zustand	down	Aus (true) oder An (false)	aus (false falls nicht vorhanden)
Im Ausfall	fault	Nur HTTP: 503 Unavailable (unavailable), Verbindung schließen (reset: die Verbindung wird ohne Antwort geschlossen) oder Keine Antwort (timeout: die Anfrage wird festgehalten, bis der Client aufgibt, höchstens 120 s)	unavailable (auch falls nicht vorhanden)

Ausgänge: Ausgang. Keine Einstellungen. Nichts wird mit Vorlagen gefüllt.

{ "id": "down", "type": "emulator_state", "x": 500, "y": 200, "emulator": "api", "down": true, "fault": "unavailable" }

Daten

Wert extrahieren

Speichert einen Teil der neuesten HTTP-Antwort auf seinem Pfad als Variable für spätere Felder ({{token}}), Prüfungen und Zweige. Eine HTTP-Anfrage muss auf jedem Pfad davor kommen. Ein Klick auf einen Wert in einer Jetzt senden-Antwort fügt einen für Sie hinzu.

Feld	In der Datei	Was	Standard und Grenzen	Vorlagen
Variable	variable	Der Name: Buchstaben, Ziffern und _, nicht mit einer Ziffer beginnend, kein reserviertes Wort, kein Name eines Parameters	token	Nein
Entnehmen aus	from	JSON-Feld (json), Header (header), Statuscode (status), Gesamter Body (body) oder Regulärer Ausdruck (regex)	json	Nein
JSON-Pfad, Header-Name oder Muster (Gruppe 1, falls vorhanden)	expr	Ein JSON-Pfad ($.data.token, $.items[0], $["first name"]), ein Headername (beliebige Schreibweise) oder ein regulärer Ausdruck — seine erste Gruppe oder der ganze Treffer	$.token; nicht verwendet für Status und Body	Nein

Der Schritt schlägt fehl, wenn es nichts zu nehmen gibt: Der Body ist kein JSON, der Pfad oder Header fehlt, der Ausdruck passt nicht, oder — bei einem JSON-Feld oder dem ganzen Body — der Body war länger als die behaltenen 256 KiB. Ein Status wird als Zahl gespeichert; der Rest als Text oder als der gefundene JSON-Wert. Ausgänge: Ausgang. Keine Einstellungen.

{ "id": "token", "type": "extract", "x": 500, "y": 80, "variable": "token", "from": "json", "expr": "$.data.token" }

Mehr über Variablen in Daten und Vorlagen.

Prüfungen

Eine Prüfung besteht oder lässt den Durchlauf fehlschlagen. Die vier Antwortprüfungen lesen die neueste HTTP-Antwort auf ihrem Pfad, daher muss eine HTTP-Anfrage — keine unter Last — auf jedem Pfad vor ihnen kommen.

HTTP-Status

Besteht, wenn der Status der neuesten Antwort genau der angegebene ist.

Feld	In der Datei	Was	Standard und Grenzen	Vorlagen
Erwarteter Status	status		200; 100–599	Nein

Ausgänge: Ausgang. Keine Einstellungen.

{ "id": "ok", "type": "assert_status", "x": 500, "y": 80, "status": 200 }

Antworttext

Besteht, wenn der Body der neuesten Antwort den Text exakt enthält (Schreibweise eingeschlossen). Nur die ersten 256 KiB eines Bodys werden behalten: Text, der in einem abgeschnittenen Body nicht gefunden wird, schlägt mit diesem Grund fehl.

Feld	In der Datei	Was	Standard und Grenzen	Vorlagen
Enthält Text	contains		ok; erforderlich	Ja

Ausgänge: Ausgang. Keine Einstellungen.

{ "id": "ready", "type": "assert_body", "x": 500, "y": 80, "contains": "ready" }

Antwort-Header

Besteht, wenn die neueste Antwort den Header hat und sein Wert den Text enthält. Der Name des Headers wird in beliebiger Schreibweise abgeglichen, der Wert exakt.

Feld	In der Datei	Was	Standard und Grenzen	Vorlagen
Header-Name	name		content-type; erforderlich	Ja
Enthält Text	contains	Was sein Wert enthalten muss; leer: Der Header muss nur da sein	application/json	Ja

Ausgänge: Ausgang. Keine Einstellungen.

{ "id": "json", "type": "assert_header", "x": 500, "y": 80, "name": "Content-Type", "contains": "json" }

Antwortzeit

Besteht, wenn die neueste Antwort höchstens so lange dauerte, vom Senden der Anfrage bis zum Ende ihres Bodys.

Feld	In der Datei	Was	Standard und Grenzen	Vorlagen
Höchstdauer, ms	max_ms		1 000; 1–120 000	Nein

Ausgänge: Ausgang. Keine Einstellungen.

{ "id": "fast", "type": "assert_latency", "x": 500, "y": 80, "max_ms": 250 }

Wert prüfen

Vergleicht einen Wert — meist eine Variable, als Vorlage geschrieben — mit einem erwarteten und besteht, wenn der Vergleich gilt.

Feld	In der Datei	Was	Standard	Vorlagen
Wert	value	Was verglichen wird: {{token}}, {{reply.args[0]}}	{{token}}	Ja
Bedingung	op	Siehe Vergleiche	ist nicht leer	Nein
Erwartet	expected	Nicht von ist leer und ist nicht leer verwendet	leer (auch falls nicht vorhanden)	Ja

Ausgänge: Ausgang. Keine Einstellungen.

{ "id": "state", "type": "assert_value", "x": 730, "y": 80, "value": "{{state}}", "op": "eq", "expected": "ready" }

Vergleiche

Wert prüfen, Nach Wert verzweigen, die Abbruchbedingung einer Schleife, OSC-Argumentregeln und HTTP-Bedingungen vergleichen gleich:

Option	In der Datei	Gilt, wenn der Wert
gleich	eq	dem erwarteten entspricht — als Zahlen, wenn beide Zahlen sind (200 = 200.0), sonst als exakter Text
ungleich	ne	ihm nicht entspricht, nach derselben Regel
kleiner als, höchstens, größer als, mindestens	lt, le, gt, ge	kleiner, höchstens, größer, mindestens ist — beide müssen Zahlen sein: andernfalls lässt eine Prüfung, ein Zweig oder eine Schleife den Schritt fehlschlagen, und eine Argumentregel oder eine HTTP-Bedingung gilt nicht
enthält	contains	den erwarteten Text enthält
passt auf Regex	matches	auf den erwarteten regulären Ausdruck passt
ist leer, ist nicht leer	empty, not_empty	leer ist (Leerzeichen zählen als leer) / nicht

Ablauf

Knoten, die entscheiden, wohin der Durchlauf geht. Mehr über Zweige, Joins und Schleifen in Ablauf.

Start

Wo der Durchlauf beginnt; jedes Experiment hat genau einen. Er hat keinen Eingang und keine Felder. Die erste Zeile der Zeitleiste gibt den Startwert des Durchlaufs.

Ausgänge: Ausgang, erforderlich. Mehrere Verbindungen von ihm starten auf einmal parallele Zweige.

{ "id": "start", "type": "start", "x": 40, "y": 80 }

Ende

Wo der Durchlauf vollständig wird; jedes Experiment hat genau ein Ende, und es hat keine Ausgänge. Mehrere Zweige können dorthin führen: Der Durchlauf geht einmal weiter, nachdem der letzte Zweig fertig ist, und nur, wenn keiner fehlschlug. Ein Durchlauf, der Ende nie erreicht, schlägt fehl.

{ "id": "end", "type": "end", "x": 960, "y": 80 }

Verzögerung

Wartet eine feste Zeit vor dem nächsten Schritt.

Feld	In der Datei	Was	Standard und Grenzen	Vorlagen
Verzögerung (ms)	ms		300; 0–60 000	Nein

Ausgänge: Ausgang. Keine Einstellungen. Für längere Wartezeiten setzen Sie mehrere hintereinander oder in eine Schleife.

{ "id": "pause", "type": "delay", "x": 500, "y": 80, "ms": 500 }

Statuszweig

Wählt Ja, wenn die neueste HTTP-Antwort diesen Status hat, sonst Nein. Eine HTTP-Anfrage muss auf jedem Pfad davor kommen.

Feld	In der Datei	Was	Standard und Grenzen	Vorlagen
Erwarteter Status	status		200; 100–599	Nein

Ausgänge: Ja und Nein, beide erforderlich. Keine Einstellungen.

{ "id": "branch", "type": "branch_status", "x": 500, "y": 80, "status": 200 }

Zweig auf einen Wert

Wählt Ja, wenn ein Vergleich gilt, sonst Nein. Seine Felder und Vergleiche sind die von Wert prüfen; ein Vergleich, der sich nicht anstellen lässt (lt auf Text), lässt den Schritt fehlschlagen.

Feld	In der Datei	Was	Standard	Vorlagen
Wert	value	Was verglichen wird	{{token}}	Ja
Bedingung	op		gleich	Nein
Erwartet	expected		leer (auch falls nicht vorhanden)	Ja

Ausgänge: Ja und Nein, beide erforderlich. Keine Einstellungen.

{ "id": "ok", "type": "branch_value", "x": 730, "y": 80, "value": "{{reply.args[0]}}", "op": "eq", "expected": "ok" }

Paralleler Zweig

Führt, was auf Zweig 1 und Zweig 2 folgt, zur selben Zeit aus, jeder Zweig mit seiner eigenen Kopie der Variablen. Jeder Ausgang darf mehr Verbindungen für mehr Zweige haben. Keine Felder.

Ausgänge: Zweig 1 und Zweig 2, beide erforderlich.

{ "id": "split", "type": "fork", "x": 270, "y": 80 }

Zweige zusammenführen

Wartet, bis jede in ihn führende Verbindung erreicht wurde, und fährt dann einmal fort, mit den zusammengeführten Variablen der Zweige — wo zwei Zweige dieselbe Variable setzen, gewinnt die, deren Verbindung später in der Datei steht — und der neuesten HTTP-Antwort des letzten von ihnen, der eine hatte. Keine Felder.

Nur Zweige, die alle laufen, treffen sich hier: Ein Zweige zusammenführen hinter einem Statusverzweigung, dessen Ja und Nein nie beide geschehen, fährt nie fort; wenn kein anderer Pfad Ende erreicht, schlägt der Durchlauf an diesem Knoten fehl und sagt, auf wie viele Zweige er noch wartete.

Ausgänge: Ausgang, erforderlich.

Jeder andere Knoten mit mehreren in ihn führenden Verbindungen läuft einmal für jedes Eintreffen.

{ "id": "joined", "type": "join", "x": 730, "y": 80 }

Schleife

Führt die Schritte an Rumpf — die zurück zu ihr führen — immer wieder aus: höchstens eine Anzahl von Malen und, wenn sie eine Abbruchbedingung hat, bis diese gilt.

Feld	In der Datei	Was	Standard und Grenzen	Vorlagen
Max. Iterationen	max	Höchstens so viele Iterationen	5; 1–1 000	Nein
vorzeitig beenden, wenn	until	Optionale Abbruchbedingung { "value", "op", "expected" }, wie bei Wert prüfen	aus	Wert und erwarteter Wert: ja

• Der Rumpf läuft immer mindestens einmal. Die Abbruchbedingung wird nach jeder Iteration gelesen, sodass der Rumpf setzen kann, was er prüft.
• Fertig folgt, wenn die Bedingung gilt — oder, ohne Bedingung, nach der letzten Iteration.
• Limit folgt, wenn die Iterationen vor der Bedingung ausgingen. Ohne eine Verbindung daran lässt das den Schritt fehlschlagen.
• Im Rumpf ist {{counter}} die Nummer der Iteration.
• Ein Rumpf läuft als ein Zweig: Jeder Ausgang in ihm hat eine Verbindung; er enthält kein Start, Ende, Paralleler Zweig, Zweige zusammenführen oder anderes Schleife; er wird nur durch Rumpf betreten; und jede Verbindung in ihm führt im Rumpf weiter oder zurück zur Schleife.

Ausgänge: Rumpf und Fertig (erforderlich), Limit (optional). Keine Einstellungen.

{ "id": "poll", "type": "loop", "x": 270, "y": 80, "max": 10,
  "until": { "value": "{{status.args[0]}}", "op": "eq", "expected": "ready" } }