Gå til indhold

Servere

Disse handlinger gør det modsatte af de andre: i stedet for at kalde en tjeneste hoster de selv en, så længe scenariet kører.

Det typiske brugstilfælde: at teste et webhook. Scenariet åbner en server, udløser forretningskaldet, venter på, at det indgående kald ankommer, og kontrollerer dets indhold — alt sammen i én og samme graf.

En lyttehandling har to udgange:

UdgangUdsendelse
connectedEt signal, én gang, når serveren lytter
servedÉn udsendelse per betjent indgående kald, som bærer { request, response }

Bemærk, at der ikke er nogen response-udgang: disse bokse foretager ikke et kald, de modtager et.

Ligesom ved forbindelserne skal du slå »Gentag ved hver modtaget hændelse« til på de bokse, der er forbundet til served, hvis alle kald og ikke kun det første skal behandles.

HTTP-server ──connected──► HTTP-anmodning »udløs webhooket«
└───────served──────► Assert på request.body.event
derefter ──► Luk HTTP-server
LytLukProtokol
HTTP-serverLuk HTTP-serverHTTP
gRPC-serverLuk gRPC-servergRPC
SOAP-serverLuk SOAP-serverSOAP — dirigering efter SOAPAction eller operationsnavn
GraphQL-serverLuk GraphQL-serverGraphQL — serverer SDL’en og de konfigurerede resolvere
OData-serverLuk OData-serverOData — anvender $filter, $select, $orderby, $top, $skip, $count, $expand, $batch

To yderligere luk-handlinger hører til serverne i WebSocket-familien: Luk WebSocket-server og Luk Socket.IO-server — se Streaming-forbindelser.

Svaret er det, der er konfigureret på den anmodning, som handlingen styrer: status, headere og body i HTTP, mockede metoder i gRPC, operationer i SOAP, resolvere i GraphQL, data i OData.

{{variables}} bliver løst i det øjeblik, der bliver serveret: ændrer du en variabel, mens serveren lytter, ændrer det det næste svar. Se Servertilstand.

Restorm åbner kun én socket per port og dirigerer efter kaldets art. En HTTP-mockserver og en WebSocket-server kan derfor lytte sammen på :8080.

Porten bliver frigivet, når dens sidste rute stopper.