Ereignisverbrauch durch Webhooks

Der Inhalt dieser Seite gilt nur für SaaS. Um die Ereignis-Payloads per POST-Aufruf zu empfangen, muss der Webhook-Server einige Aktionen durchführen.

Die Aktionen sind wie folgt:
  • Validieren Sie das angegebene Oauth-Token.
    • Wenn das Token abgelaufen oder aus anderen Gründen ungültig ist, antworten Sie mit dem entsprechenden 40x Antwortcode.
    • Wenn das angegebene Token gültig ist, speichern Sie die Nachricht so, dass ein Datenverlust unwahrscheinlich ist. Es wird vorgeschlagen, die Nachricht zu speichern, indem sie in ein Kafka-Thema, eine JMS-Warteschlange, ein Dateisystem oder eine Datenbank geschrieben wird.
  • Reagieren Sie auf den POST-Aufruf mit einer 200-Nachricht, sobald die Daten auf irgendeine Weise persistiert wurden.
Wenn eine Datenvalidierung erforderlich ist, wird dringend empfohlen, die nächste Stufe die erforderliche Validierung durchführen zu lassen, anstatt eine prompte Antwort zu verzögern. Die Antwortverzögerungen können fälschlicherweise für Zeitüberschreitungsfehler gehalten werden, die zu einer erneuten Veröffentlichung der Daten führen. Dies kann zu einem Kaskadeneffekt führen, bei dem Nachrichten wiederholt veröffentlicht werden, weil der Server nicht sofort antwortet und die Reaktionszeit des Webhooks noch weiter verlangsamt.

Bei der Implementierung des Webhook-Servers müssen Sie genau auf die Reaktionszeit des Webhooks achten. Jede Anfrage, auf die innerhalb von 5 Sekunden keine Antwort eingeht, gilt als fehlgeschlagen und wird erneut versucht. Wenn die wiederholte Nachricht aus irgendeinem Grund weiterhin fehlschlägt, betrachtet das System dies als fehlgeschlagene Ereigniszustellung und die Nutzlast wird in die Warteschlange für fehlgeschlagene Ereignisverarbeitung verschoben.

Wenn Ihr Webhook mit einem Fehlercode antwortet, der angibt, dass das Token abgelaufen ist (401), versuchen wir, ein neues Token zu generieren und zu verwenden, es sei denn, dies ist bereits fehlgeschlagen, um ein gültiges Token zu generieren. In diesem Fall leiten wir das Ereignis an die Warteschlange für fehlgeschlagene Ereignisverarbeitung weiter.

Das System erkennt, dass der zur Verfügung gestellte Oauth Server wahrscheinlich nicht für das gleiche Volumen an Anfragen ausgelegt ist wie der Webhook-Server. Um die Anzahl der Anrufe beim Oauth-Server zu verringern, versucht das System, das Oauth-Token etwa 30 Minuten vor Ablauf der Gültigkeit zu aktualisieren.

Sie können die Token-Dauer auf die folgenden zwei Arten angeben:
  • Wenn die Webhooks aktiviert sind, können Sie die Gültigkeit des Tokens in Stunden angeben. Falls sich die Gültigkeitsdauer ändert, aktualisieren Sie den Server mit der neuen Dauer.
  • Sie können die Token-Dauer in Sekunden in das expires_in-Feld im Textkörper der Oauth-Antwort aufnehmen. Auf diese Weise kann das System berechnen, wann der Token bei jeder Generierung abläuft, und Sie können die Dauer des Tokens ändern.
    Hinweis: Es wird empfohlen, dass die erzeugten Token mindestens eine Stunde lang gültig sind.