Hoppa till innehåll

Hostade servrar

De här åtgärderna gör det omvända mot de andra: i stället för att anropa en tjänst hostar de en, så länge scenariot varar.

Det typiska användningsfallet: att testa en webhook. Scenariot öppnar en server, utlöser verksamhetsanropet, väntar på att det inkommande anropet ska komma, och kontrollerar dess innehåll — allt i en enda graf.

En lyssnande åtgärd har två utgångar:

UtgångSändning
connectedEn signal, en gång, när servern lyssnar
servedEn sändning per betjänat inkommande anrop, som bär { request, response }

Lägg märke till att det inte finns någon response-utgång: de här boxarna gör inga anrop, de tar emot dem.

Precis som för anslutningarna aktiverar du ”Spela om vid varje mottagen händelse” på de boxar som är kopplade till served, för att behandla alla anrop och inte bara det första.

HTTP-server ──connected──► HTTP-begäran ”utlös webhooken”
└────────served──────► Assert på request.body.event
sedan ──► Stäng HTTP-server
LyssnaStängProtokoll
HTTP-serverStäng HTTP-serverHTTP
gRPC-serverStäng gRPC-servergRPC
SOAP-serverStäng SOAP-serverSOAP — dirigering via SOAPAction eller operationsnamn
GraphQL-serverStäng GraphQL-serverGraphQL — betjänar SDL:en och de konfigurerade resolvrarna
OData-serverStäng OData-serverOData — tillämpar $filter, $select, $orderby, $top, $skip, $count, $expand, $batch

Två ytterligare stängningar rör servrarna i WebSocket-familjen: Stäng WebSocket-server och Stäng Socket.IO-server — se Anslutningar och strömmar.

Svaret är det som konfigurerats på den begäran som åtgärden styr: status, headers och kropp i HTTP, mockade metoder i gRPC, operationer i SOAP, resolvrar i GraphQL, data i OData.

{{variables}} löses upp i det ögonblick anropet betjänas: att ändra en variabel medan servern lyssnar ändrar nästa svar. Se Serverläget.

Restorm öppnar bara en socket per port och dirigerar utifrån anropets natur. En HTTP-mockserver och en WebSocket-server kan därför lyssna tillsammans på :8080.

Porten frigörs när dess sista rutt stängs.