Webhooks statt Abfrage: wann sich der Wechsel lohnt

Beim regelmäßigen Abfragen läuft im eigenen System ein Zeitplan. In festen Abständen stellt es der Gegenstelle dieselbe Frage: Gibt es seit meinem letzten Besuch neue Aufträge, geänderte Bestände, bezahlte Rechnungen? Die Gegenstelle antwortet mit einer Liste, die häufig leer ist. Das Verfahren ist alt, unspektakulär und aus einem guten Grund weit verbreitet: Es braucht auf der eigenen Seite nichts weiter als einen Zeitplan und eine ausgehende Verbindung ins Internet. Es funktioniert damit auch dort, wo das eigene System tief im Firmennetz steht und von außen niemand hereinkommt.

Bei der ereignisgesteuerten Benachrichtigung ist die Richtung umgekehrt. Das eigene System hinterlegt bei der Gegenstelle einmalig eine Adresse und eine Liste der Ereignisse, für die es sich interessiert. Tritt eines dieser Ereignisse ein, ruft die Gegenstelle diese Adresse auf und übergibt die Meldung. Genau dieser Rückruf ist der Webhook. Zwischen zwei Ereignissen passiert nichts: kein Aufruf, keine Last, keine leeren Antworten. Die Information wandert in dem Moment, in dem sie entsteht, statt im nächsten freien Zeitfenster.

Der Unterschied lässt sich am Briefkasten erklären. Wer regelmäßig abfragt, geht alle paar Minuten hinunter und schaut nach, meistens vergeblich. Wer eine Benachrichtigung eingerichtet hat, bleibt am Schreibtisch sitzen, bis es klingelt. Das zweite Verfahren ist offensichtlich sparsamer — solange jemand zu Hause ist, wenn geklingelt wird. An genau dieser Bedingung entscheidet sich, ob ein Webhook im eigenen Betrieb Ruhe bringt oder Ärger macht.

Technisch ist ein Webhook unspektakulär: Die Gegenstelle schickt eine ganz normale Anfrage an eine Adresse, die Sie ihr genannt haben, und legt die Daten des Ereignisses bei. Ihr System antwortet mit einer kurzen Bestätigung. Das war die ganze Übertragung. Interessant wird es erst an den Rändern — bei der Anmeldung, bei der Quittung und bei der Frage, was aus einer Meldung wird, nachdem sie angenommen wurde.

Der wichtigste Konstruktionsfehler passiert in Schritt vier: Viele Empfänger verarbeiten die Meldung sofort, buchen den Auftrag, schreiben ins Warenwirtschaftssystem, verschicken vielleicht noch eine Bestätigungsmail — und antworten der Gegenstelle erst danach. Dauert das zu lange, bricht der Absender ab und wiederholt den Aufruf. Der Vorgang wird ein zweites Mal verarbeitet, obwohl er längst gebucht ist. Annahme und Verarbeitung gehören deshalb getrennt.

Das ist die Frage, die in Angeboten am häufigsten fehlt. Der Ablauf ist zunächst harmlos: Der Absender ruft Ihre Adresse auf, bekommt keine Antwort oder eine Fehlermeldung und versucht es später erneut. Seriöse Anbieter wiederholen gestaffelt, also mit wachsenden Abständen, damit ein überlastetes System nicht zusätzlich unter Druck gerät. Ein Ausfall von einigen Minuten — ein Neustart, ein Update, ein kurzer Netzfehler — bleibt dadurch folgenlos.

Kritisch wird es bei längeren Störungen. Jeder Absender gibt irgendwann auf. Manche Systeme schalten eine Adresse nach einer Reihe erfolgloser Versuche sogar dauerhaft ab, damit sie nicht dauerhaft ins Leere senden. Ab diesem Moment fehlen Meldungen, ohne dass jemand eine Fehlermeldung sieht: Es kommt einfach nichts mehr an, und ein leerer Posteingang sieht aus wie ein ruhiger Tag. Der gefährlichste Zustand einer Ereignisschnittstelle ist nicht der Fehler, sondern die Stille.

Deshalb gehören drei Dinge zur Planung: Erstens ein Ereignisprotokoll auf der Gegenseite, aus dem sich verpasste Meldungen nachträglich abrufen lassen. Zweitens eine Überwachung, die Alarm schlägt, wenn über einen ungewöhnlich langen Zeitraum keine Meldung eintrifft. Drittens ein regelmäßiger Abgleich, der beide Bestände vergleicht und Abweichungen benennt. Ein Wiederholungsfenster von mindestens 24 Stunden (Projekterfahrung) auf Absenderseite verschafft dabei die Zeit, die ein Betrieb braucht, um eine Störung überhaupt zu bemerken.

Ereignisgesteuerte Systeme sichern in aller Regel zu, dass eine Meldung mindestens einmal ankommt — nicht, dass sie genau einmal ankommt. Geht eine Quittung auf dem Rückweg verloren, hält der Absender die Zustellung für gescheitert und wiederholt sie. Ihr System sieht denselben Vorgang zweimal. Ohne Vorkehrung entstehen daraus doppelte Aufträge, doppelte Buchungen oder doppelte Benachrichtigungen an Kunden. Der Schutz ist einfach: Jede Meldung trägt eine eindeutige Kennung, und die Verarbeitung merkt sich, welche Kennungen bereits erledigt sind. Eine bekannte Kennung wird quittiert und verworfen.

Ebenso wenig ist die Reihenfolge zugesichert. Bei Wiederholungen und parallelen Zustellungen kann die Meldung über den Statuswechsel vor der Meldung über die Anlage eintreffen. Wer Zustände aus der Abfolge der Meldungen ableitet, bekommt in seltenen Fällen falsche Ergebnisse — und diese Fälle treten ausgerechnet dann auf, wenn es hektisch ist. Robuster ist es, den aktuellen Stand des Datensatzes nachzuladen und den Zeitstempel der Meldung nur zu nutzen, um veraltete Informationen zu erkennen.

In den meisten mittelständischen Anbindungen ist die Antwort nicht entweder oder, sondern beides. Der Webhook übernimmt die Geschwindigkeit: Ein neuer Auftrag ist innerhalb von Sekunden im System, die Versandvorbereitung sieht ihn ohne Wartezeit. Ein Abgleichlauf übernimmt die Verlässlichkeit: Einmal je Nacht, bei kritischen Daten auch stündlich, vergleicht ein geplanter Vorgang beide Bestände für einen begrenzten Zeitraum und trägt nach, was fehlt. Dieser Lauf ist gleichzeitig die Kontrolle, die eine stille Störung überhaupt sichtbar macht.

Der Zusatzaufwand für den Abgleich ist gering, weil er auf denselben Zugriffen aufsetzt, die eine reine Abfragelösung ohnehin verwenden würde. Der Gewinn ist erheblich: Die Schnittstelle verliert ihre einzige gefährliche Eigenschaft, nämlich unbemerkt zu schweigen. Für Vorhaben zur Prozessautomatisierung empfiehlt es sich, diesen Abgleich von Anfang an einzuplanen statt ihn nach dem ersten Vorfall nachzurüsten.