Zurück zu Neuigkeiten

Zuverlässige ausgehende Webhooks: klarer Zustellstatus für jede Integration

Pavel NOVOTNÝ
Blog
Zuverlässige ausgehende Webhooks: klarer Zustellstatus für jede Integration

Die Integration von Lager-, ERP- oder Transportportalen soll nicht alle paar Sekunden überprüfen, ob sich etwas in der Zeitfenstersteuerung geändert hat. Outbound webhooket ein Ereignis sofort, wie es auftritt, und behält dabei ein klares Ergebnis für jeden Lieferversuch.

Von der Veranstaltung bis zur Durchführung ohne Umfrage

Wenn sich eine Reservierung oder Bestellung ändert, erstellt TSC ein Ereignis und wählt die aktiven Webhook-Abonnements aus, die diesen Typ verfolgen. Jedes Abonnement erhält ein versioniertes JSON über HTTP POST an seine Zieladresse.

  1. TSC erkennt die Änderung und erzeugt ein einzigartiges Ereignis.
  2. Aktive Abonnements werden mit ihrem Typ verglichen.
  3. Für jede entsprechende Bestellung wird eine separate Lieferung erstellt.
  4. Die Reaktion des Zielsystems bestimmt den resultierenden Zustand oder den nächsten Versuch.

Die Verarbeitung erfolgt ereignisgesteuert und erfolgt asynchron. Das verbundene System muss die API nicht mit häufigen Abfragen belasten und kann kurz nach der tatsächlichen Änderung antworten.

Ablauf einer Outbound-Webhook-Zustellung vom TSC-Ereignis über einen signierten HTTP POST bis zu Delivered, Failed oder DeadLetter und manuellem Resend

Das Lieferprotokoll ersetzt das Raten

Der Administrator kann die Lieferung an einem Ort sehen und sie sowohl nach Webhook-Abonnement als auch nach Status filtern. Für jeden Datensatz gibt es einen Ereignistyp, die Anzahl der Versuche, den letzten HTTP-Status, die letzte Versuchszeit und eine kurze Fehlerinformation.

StatusWas bedeutet das
PendingDie Lieferung wartet in der Warteschlange für den ersten oder nächsten Versuch.
DeliveredDas Zielsystem gab eine erfolgreiche HTTP-Antwort zurück.
FailedDer letzte Versuch endete mit einem vorübergehenden Fehler und wird wiederholt.
DeadLetterAutomatische Versuche sind beendet oder die Antwort sollte nicht automatisch wiederholt werden.

Was passiert, wenn das Zielsystem nicht verfügbar ist?

Netzwerkfehler, HTTP-429-Antworten und 5xx-Serverfehler wiederholen sich mit zunehmenden Abständen, maximal in fünf Versuchen. Häufige Client-Fehler von 4xx außer 429 gehen direkt in den DeadLetter-Zustand, da der nächste automatische Versuch normalerweise gleich endet.

Nachdem das empfangende System repariert wurde, kann der autorisierte Benutzer Resend verwenden. TSC setzt die Anzahl der Versuche zurück, entfernt den letzten Fehler und gibt die Lieferung an die Warteschlange zurück. Daher ist es nicht nötig, das ursprüngliche Geschäftsereignis abzurufen.

Ereignisse, die dem tatsächlichen Verkehr entsprechen

Der Katalog endet nicht mit generischer Erstellung, Änderung und Löschung. Eine Integration kann auch bestimmte Punkte im Buchungs- und Bestellzyklus entfernen, wie reservation.pendingBuch, Areservation.vehicle.platechangedreservation.markedasarrivalreservation.approval.approvedreservation.processingstartedreservation.markedasdeparted oder order.confirmedA.

Das Abonnement wählt nur die benötigten Ereignisse aus. Das Zielsystem muss nicht rückwirkend aus der allgemeinen Änderung ableiten, was tatsächlich im Betrieb passiert ist.

Signierte Nachrichten und sichere Verarbeitung

Die Webhook-Adresse verwendet HTTPS. TSC sendet einen JSON-Wrapper mit schemaVersionFelderneventeventIdoccurredAt tenantIdund data. Der Anforderungskörper wird mit HMAC-SHA256 signiert, und der Empfänger erhält eine Signatur im Header X-TSC-Signature zusammen mit einem Zeitstempel.X-TSC-Timestamp

Das empfangende System sollte die Signatur und den Zeitstempel validieren, idempotent verarbeiten eventId und erst nach sicherem Empfang der Nachricht einen erfolgreichen 2xx-Zustand zurückgeben. Das Geheimnis kann rotiert werden, wenn die Sicherheit geändert wird.

Was bringt es für den Integrationsbetrieb

  • Weniger Umfrageanfragen und weniger Belastung auf beiden Seiten der Integration.
  • lesbarer Status jeder Lieferung ohne Suche in mehreren Protokollierungstools,
  • Automatische Wiederherstellung von temporären Fehlern
  • Kontrollierter manueller Nachversuch, nachdem das Zielsystem repariert wurde.
  • Überprüfbare Herkunft und Integrität jeder Nachricht.

Das Ergebnis ist nicht nur eine schnellere Übertragung von Ereignissen, sondern auch eine operationell vorhersehbare Integration: Das Team kann sehen, was geliefert wurde, was auf den nächsten Versuch wartet und was ein Eingreifen erfordert.

Möchten Sie TSC mit einem ERP, WMS oder Ihrer eigenen Integrationsplattform verbinden? Durchstöbern Sie die Integrationsoptionen oder beschreiben Sie uns Ihr Szenario.