SCHNELLER ÜBERBLICK
Was Sie aus dem Artikel mitnehmen können
- Jedes wichtige Ereignis braucht eine Identität und ein nachvollziehbares Ergebnis.
- Der erneute Versuch darf den geschäftlichen Effekt nicht wiederholen.
- Fehler sollten einen Eigentümer, eine Lösungsfrist und die Möglichkeit einer sicheren Wiederherstellung haben.
Bestimmen Sie, welches System die Quelle der Wahrheit ist
Der E-Shop nimmt die Bestellung an, das Lager reserviert die Ware und das Buchhaltungssystem verwaltet den Beleg. Wenn jedes System ohne Regeln alles verändern kann, entstehen Konflikte. Bestimmen Sie für jedes Feld den Eigentümer: Er entscheidet über Preis, Zahlungsstatus, Verfügbarkeit und Versandstatus. Andere Systeme erhalten eine verifizierte Änderung oder senden eine Anfrage zur Ausführung.
Bei mehreren Firmen muss die Identifikation auch die Firma enthalten. Die gleiche Bestellnummer kann in zwei separaten Tagesordnungen vorhanden sein. Daher sollte die Verknüpfung zwischen Datensätzen nicht nur auf der dem Kunden angezeigten Nummer basieren. Sie benötigen interne Identifikatoren und Zuordnungen zwischen Systemen. Das Geschäftsframework wird im Artikel über mit Lager und ERP verbundener E-Shop beschrieben.
Ein Webhook ist eine Benachrichtigung und keine Garantie für den Abschluss
Der Webhook benachrichtigt die andere Anwendung über ein Ereignis, beispielsweise eine erfolgreiche Zahlung. Der Empfänger muss den Absender und die Daten verifizieren. In der Dokumentation von Stripe wird vor der Signaturüberprüfung, der Möglichkeit doppelter Ereignisse und der Tatsache gewarnt, dass die Lieferreihenfolge möglicherweise nicht garantiert werden kann. Diese Merkmale müssen bei der Gestaltung jeder spezifischen Integration gemäß ihrer Dokumentation berücksichtigt werden.
Wir empfehlen, das Ereignis zunächst sicher in die Warteschlange einzureihen, bevor Sie den Empfang bestätigen. Die Geschäftsabwicklung selbst kann separat weitergeführt werden. Das System unterscheidet somit zwischen empfangenen, verarbeiteten und Fehlerereignissen. Es reicht nicht aus, eine erfolgreiche Antwort zurückzugeben und zu hoffen, dass der nächste Schritt erfolgreich ist. Wenn der Commit abgebrochen wird, bevor er beibehalten wird, kann es sein, dass der Ausfall das Ereignis verliert.
Idempotenz: gleiche Anweisung, gleiche Wirkung
Idempotenz bedeutet, dass die sichere Wiederholung derselben Anweisung nicht zu einer zweiten Bestellung, Reservierung oder Rechnung führt. In der Praxis merkt sich der Empfänger die eindeutige Kennung des Ereignisses und das Verarbeitungsergebnis. Gleichzeitig muss es auch den Geschäftsbetrieb schützen, da zwei verschiedene technische Ereignisse dieselbe Änderung beschreiben können.
Stellen Sie sich einen Ausfall vor, nachdem Sie eine Bestellung im ERP erstellt haben, aber bevor die Bestätigung an den E-Shop zurückgesendet wird. Der E-Shop wird die Anfrage erneut versuchen. Das richtige Ergebnis besteht darin, die vorhandene Bindung zu finden und dieselbe Bestellung zurückzugeben, nicht eine neue zu erstellen. Die Prüfung muss außerdem zwei gleichzeitigen Versuchen standhalten; Ein einfaches „Erst finden, dann erstellen“ ohne Parallelitätsschutz reicht möglicherweise nicht aus.
Verzögerte Ereignisse dürfen den Auftrag nicht zurückwerfen
Die Nachricht „Bestellung erhalten“ kann erst nach der Nachricht „bezahlt“ eintreffen. Wenn jeder den Status ohne Überprüfung überschreibt, wird das neuere Ergebnis durch die alten Informationen gelöscht. Use the state transitions allowed and the available version or time of the event. Im Konfliktfall laden Sie den aktuellen Stand aus dem Quellsystem.
Stornierung und Rückerstattung sind getrennte Ereignisse. Löschen Sie nicht die Historie erfolgreicher Verkäufe; Beachten Sie die nachfolgende Änderung. Das gleiche Prinzip gilt für Teillieferungen und Teilbestellungen. Ein universeller Zustand „erledigt“ reicht für Lagerung, Transport und Dokumente oft nicht aus.
| Bereich | Postup | Was zu überprüfen ist |
|---|---|---|
| Wiederholter Webhook | Das bestehende Ergebnis, ohne zweite Operation. | Anzahl der Reservierungen und Dokumente. |
| Ausstieg nach Anmeldung | Durch Wiederholen wird eine bereits erstellte Bestellung gefunden. | Bindung von Identifikatoren zwischen Systemen. |
| Falsche Reihenfolge | Ein älterer Status überschreibt keinen bestätigten neueren. | Zulässige Übergänge und Verlauf. |
| Falsche Daten | Die Aufnahme stoppt aus einem bestimmten Grund. | Verantwortliche Person und sicheres Reparaturverfahren. |
Automatische Wiederholung und Arbeitsliste von Ausnahmen
Ein vorübergehender Ausfall kann durch Wiederholen mit zunehmender Entfernung behoben werden. Eine fehlende Rate, ein unbekanntes Produkt oder das falsche Unternehmen wird jedoch durch Wiederholung allein nicht korrigiert. Unterteilen Sie technische Fehler in vorübergehende und wesentliche. Nach Ablauf des festgelegten Grenzwerts muss das Ereignis zur Lösung in die Liste aufgenommen werden und darf nicht auf unbestimmte Zeit ausgeführt werden.
Der Manager muss die Anzahl der feststeckenden Bestellungen, deren Alter, Wert und Grund sehen. Der Arbeitnehmer benötigt einen konkreten nächsten Schritt und Zugriff auf relevante Dokumente. Nach der Reparatur sollte nur der notwendige Teil des Prozesses wiederhergestellt werden. Das Design des Morgenberichts besprechen wir im Artikel Multi-Business-Dashboard.
Überprüfen Sie auch, was nicht angekommen ist
Die Ereignisüberwachung erkennt eine Fehlermeldung, erfasst jedoch möglicherweise kein vollständig fehlendes Ereignis. Fügen Sie daher einen regelmäßigen Abgleich hinzu: Web-Bestellungen vs. ERP, bestätigte Zahlungen vs. bezahlte Bestellungen und Versand vs. Lagerbewegungen. Ausnahmen müssen erklärbar und auf eine Person oder einen Reparaturvorgang zurückzuführen sein.
Führen Sie das Pilotprojekt auf einem einzelnen Stream mit begrenztem Umfang aus. Messen Sie die Bearbeitungszeit, die manuelle Eingriffsrate, die Anzahl der Duplikate und die Anzahl der ausstehenden Differenzen. Erweitern Sie die Automatisierung nur, wenn der Ausfall sicher behoben werden kann. Eine zuverlässige Verbindung bringt gerade deshalb Einsparungen, weil das Unternehmen nicht jeden Tag manuell prüfen muss, ob etwas verloren gegangen ist.
