Problembehandlung und Debuggen des Azure Web PubSub-Ereignishandlers
Wenn eine WebSocket-Verbindung mit dem Web PubSub-Dienst hergestellt wird, formuliert der Dienst eine POST-Anforderung an den registrierten Upstream und erwartet eine HTTP-Antwort. Wir rufen den Upstream als Ereignishandler auf. Der Ereignishandler ist für die Behandlung der eingehenden Ereignisse gemäß der Web PubSub CloudEvents-Spezifikation zuständig.
Lokales Ausführen des Ereignishandlerendpunkts
Wenn der Ereignishandler lokal ausgeführt wird, kann der lokale Server nicht öffentlich zugänglich sein.
Es gibt zwei Möglichkeiten, den Datenverkehr an Ihren localhost weiterzuleiten: Eine besteht darin, localhost verfügbar zu machen, um über Tools wie ngrok, localtunnel oder TunnelRelay auf das Internet zugreifen zu können. Eine weitere und auch die empfohlene Möglichkeit besteht darin, AWPS-Tunnel zum Tunneln des Datenverkehrs vom Web PubSub-Dienst über das Tool zu Ihrem lokalen Server zu verwenden.
Das lokale Tunnel-Tool von Web PubSub baut im Hintergrund mehrere dauerhafte Tunnelverbindungen (wir betrachten sie als eine Art von Serververbindungen) zum Web PubSub-Dienst auf. Immer wenn ein Ereignis eintrifft, leitet der Web PubSub-Dienst die Ereignismeldung über die Tunnelverbindung an das lokale Tunnel-Tool weiter. Das lokale Tunnel-Tool formatiert die HTTP-Anforderung neu und sendet sie an Ihren Upstream-Server.
Das lokale Tunnel-Tool bietet eine anschauliche Darstellung des Workflows über eine Webansicht-Seite. Die Webansicht lauscht standardmäßig auf dem lokalen Port upstream port + 1000. Sie können den Port der Webansicht mit dem Befehlsparameter --webviewPort <your-custom-port> anpassen.
Die Webansicht hat vier Registerkarten:
- Auf der Registerkarte Client wird ein WebSocket-Testclient bereitgestellt, um eine Verbindung zu Web PubSub herzustellen und Daten zu senden.
- Die Registerkarte Web PubSub enthält die grundlegenden Informationen zu Ihrem Web PubSub-Dienst und bettet die Live-Ablaufverfolgungsseite ein, wenn diese aktiviert ist.
- Auf der Registerkarte Lokaler Tunnel werden alle Anforderungen aufgelistet, die das lokale Tunnel-Tool auf Ihrem lokalen Server durchlaufen.
- Auf der Registerkarte Server werden die grundlegenden Informationen zu Ihrem lokalen Server angezeigt. Außerdem wird ein integrierter Echoserver mit Code bereitgestellt, der dem unten gezeigten Beispielcode ähnelt.
Folgen Sie den Anweisungen unter Entwickeln mit dem lokalem Tunnel-Tool, um das Tunnel-Tool lokal zu installieren und auszuführen, um Ihren Ereignishandlerserver lokal zu entwickeln.
Online-Debuggen des Ereignishandlerendpunkts
Manchmal können beim Senden von Ereignissen an einen konfigurierten Ereignishandler Probleme auftreten. Ein typischer Fehlertyp bezieht sich auf Missbrauchsschutzfehler, z. B. AbuseProtectionResponseInvalidStatusCode, AbuseProtectionResponseMissingAllowedOrigin oder AbuseProtectionResponseFailed. Ein solcher Fehler hängt wahrscheinlich mit den Einstellungen Ihres vorgelagerten App-Servers zusammen. Beispielsweise könnte der Statuscode 403 mit der Authentifizierungskonfiguration Ihres App-Servers zusammenhängen, der Statuscode 404 könnte durch eine inkonsistente Konfiguration des Ereignishandler-Pfads verursacht werden. Eine Möglichkeit zur Problembehandlung besteht darin, eine Anforderung zum Schutz vor Missbrauch an Ihre konfigurierte Ereignishandler-URL zu senden, um zu sehen, ob sie funktioniert. Der Befehl curl zum Senden einer Anforderung zum Schutz vor Missbrauch an Ihre konfigurierte Ereignishandler-URL https://abc.web.com/eventhandler lautet zum Beispiel wie folgt:
curl https://abc.web.com/eventhandler -X OPTIONS -H "WebHook-Request-Origin: *" -H "ce-awpsversion: 1.0" --ssl-no-revoke -i
Der Befehl sollte 204 zurückgeben.
Nächste Schritte
Erstellen Sie mithilfe dieser Ressourcen Ihre eigene Anwendung: