Gå til innholdet

Hostede servere

Disse handlingene gjør det motsatte av de andre: i stedet for å kalle en tjeneste hoster de en, så lenge scenarioet varer.

Det typiske bruksområdet: å teste et webhook. Scenarioet åpner en server, utløser forretningskallet, venter på at det innkommende kallet skal komme, og kontrollerer innholdet — alt sammen i én enkelt graf.

En lyttehandling har to utganger:

UtgangSending
connectedEtt signal, én gang, når serveren lytter
servedÉn sending per innkommende kall som betjenes, med { request, response }

Legg merke til at det ikke finnes noen response-utgang: disse boksene foretar ingen kall, de mottar dem.

Som for tilkoblingene slår du på «Kjør ved hver mottatt hendelse» på boksene som er koblet til served, for å behandle alle kallene og ikke bare det første.

HTTP-server ──connected──► HTTP-forespørsel «utløs webhooket»
└────────served──────► Assert på request.body.event
deretter ──► Lukk HTTP-server
LytteLukkeProtokoll
HTTP-serverLukk HTTP-serverHTTP
gRPC-serverLukk gRPC-servergRPC
SOAP-serverLukk SOAP-serverSOAP — ruting via SOAPAction eller operasjonsnavn
GraphQL-serverLukk GraphQL-serverGraphQL — betjener SDL-en og de konfigurerte resolverne
OData-serverLukk OData-serverOData — anvender $filter, $select, $orderby, $top, $skip, $count, $expand, $batch

To ekstra lukkinger gjelder serverne i WebSocket-familien: Lukk WebSocket-server og Lukk Socket.IO-server — se Tilkoblinger og strømmer.

Svaret er det som er konfigurert på forespørselen som handlingen styrer: status, headere og kropp i HTTP, mockede metoder i gRPC, operasjoner i SOAP, resolvere i GraphQL, data i OData.

{{variabler}} løses i det øyeblikket de serveres: endrer du en variabel mens serveren lytter, endres det neste svaret. Se Servermodus.

Restorm åpner bare én socket per port og ruter etter hva slags kall det er. En HTTP-mockserver og en WebSocket-server kan derfor lytte sammen på :8080.

Porten frigjøres når den siste ruten stopper.