Begäranden och komposition

De här boxarna utför ett begäran/svar-anrop och lämnar tillbaka kontrollen. För anslutningar som förblir öppna, se Anslutningar och strömmar.

Var och en är bunden till en begäran i projektet: du pekar ut den när du skapar åtgärden.

HTTP-begäran

Kör en HTTP-begäran, GraphQL, unärt gRPC eller WebSocket i ett svep.


Ingångar	`env` (körningsmiljön), `override` (överskrivningar, objekt)
Utgångar	`response` — det fullständiga svaret
Konfiguration	`requestId`, `label`

Utgången response bär svarsobjektet: status, headers, kropp, tid. Sätt en väljare på kopplingen för att direkt plocka ut det du är intresserad av — status, body.data.id.

SOAP-begäran

Kör en SOAP-begäran.


Ingångar	`env`
Utgångar	`response`
Konfiguration	`requestId`, `label`

Ett <soap:Fault>-svar syns på svarsobjektet: testa det med en Assert i stället för att förlita dig på bara HTTP-statusen.

Redis command

Kör ett enskilt Redis-kommando, på en ny anslutning.


Ingångar	`env`
Utgångar	`response`

Kafka produce

Publicerar en Kafka-post.


Ingångar	`env`
Utgångar	`response` — postens metadata: topic, partition, offset

Kör scenario

Anropar ett annat scenario i projektet — det är kompositionsmekanismen.


Ingångar	en port `param:<namn>` per fri parameter i underscenariot
Utgångar	en port `output:<namn>` per utgång i underscenariot, plus `result`
Konfiguration	`scenarioId`, `label`

Portarna härleds direkt från underscenariot: lägg till en parameter där, och porten dyker upp på den anropande noden.

Det är så du bryter ut gemensam logik: ett scenario ”hämta en token”, anropat av de fem andra.

Kör scenario ”Logga in”
  ├─ param:user   ◄── Ingång
  └─ output:token ──► Ange variabel ”token”

Skriva över begäran

Fyra lager, tillämpade i den här ordningen:

begäran så som den sparats i projektet;
den snabbinställning som pekas ut på åtgärden;
de överskrivningar som skrivits in på åtgärden;
värdet som tas emot på överskrivningsporten.

Samma anrop kan alltså spelas om med tre datauppsättningar, utan att begäran dupliceras.