Skip to content

Hosted servers

These actions do the opposite of the others: instead of calling a service, they host one for the duration of the scenario.

The typical use case: testing a webhook. The scenario opens a server, triggers the business call, waits for the inbound call to arrive, and checks its content — all in a single graph.

A listen action has two outputs:

OutputEmission
connectedA signal, once, when the server is listening
servedOne emission per inbound call served, carrying { request, response }

Note that there is no response output: these boxes do not make a call, they receive one.

As with connections, enable “Play on each event received” on the boxes wired onto served in order to handle every call and not only the first.

Serveur HTTP ──connected──► Requête HTTP « déclencher le webhook »
└────────served──────► Assert sur request.body.event
puis ──► Fermeture serveur HTTP
ListenCloseProtocol
HTTP serverHTTP server closeHTTP
gRPC servergRPC server closegRPC
SOAP serverSOAP server closeSOAP — dispatch by SOAPAction or operation name
GraphQL serverGraphQL server closeGraphQL — serves the SDL and the configured resolvers
OData serverOData server closeOData — applies $filter, $select, $orderby, $top, $skip, $count, $expand, $batch

Two further close actions concern the WebSocket-family servers: WebSocket server close and Socket.IO server close — see Connections and streams.

The reply is the one configured on the request the action drives: status, headers and body in HTTP, mocked methods in gRPC, operations in SOAP, resolvers in GraphQL, data in OData.

{{variables}} are resolved at serving time: changing a variable while the server is listening changes the next reply. See Server mode.

Restorm opens only one socket per port and dispatches according to the nature of the call. A mock HTTP server and a WebSocket server can therefore listen together on :8080.

The port is released when its last route is stopped.