Gehostete Server

Diese Aktionen tun das Gegenteil der anderen: Statt einen Dienst aufzurufen, hosten sie einen für die Dauer des Szenarios.

Der typische Anwendungsfall: einen Webhook testen. Das Szenario öffnet einen Server, löst den fachlichen Aufruf aus, wartet auf den eingehenden Aufruf und prüft dessen Inhalt — alles in einem einzigen Graphen.

Das gemeinsame Muster

Eine Lauschen-Aktion hat zwei Ausgänge:

Ausgang	Emission
connected	Ein Signal, einmalig, sobald der Server lauscht
served	Eine Emission pro bedientem eingehenden Aufruf, mit { request, response }

Beachten Sie: Es gibt keinen Ausgang response: Diese Bausteine machen keinen Aufruf, sie empfangen einen.

Wie bei Verbindungen aktivieren Sie „Bei jedem empfangenen Ereignis wiederholen“ auf den an served angeschlossenen Bausteinen, um alle Aufrufe zu verarbeiten und nicht nur den ersten.

HTTP-Server ──connected──► HTTP-Anfrage „Webhook auslösen“
     └────────served──────► Assert auf request.body.event
                            dann ──► HTTP-Server schließen

Die verfügbaren Paare

Lauschen	Schließen	Protokoll
HTTP-Server	HTTP-Server schließen	HTTP
gRPC-Server	gRPC-Server schließen	gRPC
SOAP-Server	SOAP-Server schließen	SOAP — Weiterleitung nach SOAPAction oder Operationsname
GraphQL-Server	GraphQL-Server schließen	GraphQL — bedient das konfigurierte SDL und die Resolver
OData-Server	OData-Server schließen	OData — wendet $filter, $select, $orderby, $top, $skip, $count, $expand, $batch an

Zwei weitere Schließ-Aktionen betreffen die Server der WebSocket-Familie: WebSocket-Server schließen und Socket.IO-Server schließen — siehe Verbindungen und Streams.

Was der Server antwortet

Die Antwort ist die, die auf der Anfrage konfiguriert ist, welche die Aktion steuert: Status, Header und Body bei HTTP, simulierte Methoden bei gRPC, Operationen bei SOAP, Resolver bei GraphQL, Daten bei OData.

Die {{variables}} werden zum Zeitpunkt der Bedienung aufgelöst: Eine Variable zu ändern, während der Server lauscht, ändert die nächste Antwort. Siehe Servermodus.

Port-Sharing

Restorm öffnet nur einen Socket pro Port und leitet je nach Art des Aufrufs weiter. Ein simulierter HTTP-Server und ein WebSocket-Server können also gemeinsam auf :8080 lauschen.

Der Port wird freigegeben, sobald seine letzte Route stoppt.