Doppelte und ungeordnet eintreffende A2P-SMS-Ereignisse: So gleichen Sie sie ab, ohne Belege zu verlieren

Warum Ereignisse doppelt, verspätet oder ungeordnet eintreffen können

Bei einer A2P-Integration kann ein Versand an mehreren Stellen Beobachtungen erzeugen: eine API-Anfrage, eine Annahme- oder Ablehnungsantwort, eine SMPP-Interaktion und, sofern verfügbar, einen Zustellbericht (DLR). Diese Signale treffen nicht unbedingt gleichzeitig oder in der Reihenfolge ein, in der die Ereignisse stattgefunden haben. Auch Benachrichtigungswiederholungen oder wiederholte Ereignisse sind möglich.

Die genaue Bedeutung hängt von der Schnittstelle und dem Anbieter ab. Es gibt keine allgemeingültige Priorität, anhand derer sich für alle Systeme ableiten ließe, dass ein API-Ereignis Vorrang vor einem SMPP-Ereignis hat oder jeder DLR dasselbe bedeutet. Dokumentieren Sie, wofür die einzelnen Ereignisse in Ihrer Integration stehen, bevor Sie damit einen Status aktualisieren.

• Unterscheiden Sie zwischen dem Zeitpunkt, zu dem das System angibt, dass ein Ereignis stattgefunden hat, und dem Zeitpunkt, zu dem Ihre Plattform es empfangen hat.
• Behandeln Sie wiederholte Nachrichten als mögliche betriebliche Erscheinung, nicht als Beweis dafür, dass das zugrunde liegende Ereignis mehrfach stattgefunden hat.
• Gehen Sie nicht davon aus, dass ein fehlendes Ereignis einen Fehler, eine Zustellung oder eine Stornierung bedeutet.

Trennen Sie das ursprüngliche Protokoll von der berechneten Statusansicht

Halten Sie zwei Konzepte auseinander. Das Ereignisprotokoll bewahrt die empfangenen Informationen auf; die operative Projektion fasst zusammen, was die Plattform zum jeweiligen Zeitpunkt aussagen kann. Ändert sich eine Abgleichregel, lässt sich die Projektion anhand des Protokolls neu berechnen, ohne die Belege, die zum Ergebnis geführt haben, zu löschen oder umzuschreiben.

Bewahren Sie für jedes Ereignis, soweit verfügbar, den empfangenen Inhalt, die Quelle oder Schnittstelle, die Korrelationskennung, die angegebenen und beobachteten Zeitpunkte sowie die Ergebnisse von Prüfungen auf. Ersetzen Sie ein früheres Ereignis nicht durch ein späteres, nur weil das spätere eindeutiger erscheint.

Aufbewahrungsfristen, Schutz vor Veränderungen und Audit-Anforderungen müssen den Verpflichtungen Ihrer Organisation und den geltenden Verträgen entsprechen. Hier wird keine allgemeingültige Garantie für unveränderliche Speicherung gegeben.

• Speichern Sie die ursprüngliche Beobachtung und erfassen Sie jede Normalisierung getrennt.
• Versionieren Sie die Regeln, nach denen Sie die Projektion berechnen.
• Ermöglichen Sie die Rekonstruktion, welche Ereignisse und Regeln den angezeigten Status ergeben haben.

Legen Sie Identität und Deduplizierung fest, ohne einen globalen Schlüssel vorauszusetzen

Gehen Sie nicht davon aus, dass es eine eindeutige Kennung gibt, die von API, SMPP, Aggregatoren und Mobilfunkbetreibern gemeinsam verwendet wird. Eine Kennung kann nur innerhalb eines Kontos, einer Verbindung, eines Anbieters oder eines Zeitraums gültig sein. Legen Sie den Geltungsbereich jeder Kennung anhand der Dokumentation der jeweiligen Schnittstelle fest.

Gibt es keinen verlässlichen Schlüssel, führen Sie Ereignisse nicht allein deshalb zusammen, weil Empfänger, Text und ungefähre Uhrzeit übereinstimmen: Zwei legitime Nachrichten können diese Merkmale teilen. Bewahren Sie in diesem Fall beide auf und kennzeichnen Sie sie als mögliche Duplikate oder als unsicher korreliert, statt Belege zu verwerfen.

Eine Normalisierung der Rufnummer kann die Suche erleichtern, beweist aber nicht, dass zwei Datensätze zum selben Versand gehören. E.164 ist eine Nummerierungsempfehlung und liefert für sich genommen keine Regel zur Nachrichtenkorrelation.

• Verwenden Sie zuerst die von der Schnittstelle dokumentierte Kennung und ihren Geltungsbereich: Konto, Verbindung oder Anbieter.
• Dokumentieren Sie die Deduplizierungsregeln und den Grund für jede Zuordnung.
• Ist die Korrelation mehrdeutig, bewahren Sie das Ereignis auf und führen Sie Nachrichten nicht automatisch zusammen.

Ordnen Sie Ereignisse mit Vorsicht: angegebene Zeit, beobachtete Zeit und Sequenz

Bewahren Sie den vom Ereignissender mitgelieferten Zeitstempel getrennt von dem Zeitpunkt auf, zu dem Ihr System das Ereignis beobachtet hat. Die angegebene Zeit kann den Ursprungszeitpunkt beschreiben; die beobachtete Zeit dokumentiert, wann das Ereignis auf Ihrer Plattform eingetroffen ist. Keiner dieser Werte sollte den anderen stillschweigend ersetzen.

Stellt die Schnittstelle eine Sequenz oder Version mit dokumentierter Bedeutung bereit, prüfen Sie, ob sie innerhalb ihres Geltungsbereichs verwendet werden kann. Gibt es kein verlässliches Ordnungssignal, machen Sie die Empfangsreihenfolge nicht zur endgültigen Chronologie. Eine feste Regel für Gleichstände kann die Berechnung reproduzierbar machen, beweist aber nicht, was zuerst geschehen ist.

Dokumentieren Sie Zeitzone, Genauigkeit und mögliche Uhrzeitprobleme, sofern diese Angaben verfügbar sind. Fehlen sie, berücksichtigen Sie diese Einschränkung bei der Bewertung des Ereignisses.

• Speichern Sie mindestens die angegebene Zeit und die Empfangszeit als getrennte Felder.
• Verwenden Sie Sequenzen nur, wenn ihr Geltungsbereich und ihre Bedeutung bekannt sind.
• Kennzeichnen Sie die relative Reihenfolge als unsicher, wenn die Belege keine eindeutige Aussage zulassen.

Definieren Sie explizite Zustandsübergänge und leiten Sie keine Zustellung ab

Entwerfen Sie eine Zustandsmaschine für Ihr System auf Grundlage der dokumentierten Bedeutung jeder Schnittstelle. Es gibt keine allgemeingültige Priorität zwischen Annahme, Fehler, Zwischenstatus und DLR, die sich ohne Kenntnis des Anbieters und des technischen Vertrags anwenden ließe.

Eine Versandannahme sagt nur aus, was die Schnittstelle laut Dokumentation über die Anfrage bestätigt. Ein DLR ist entsprechend seiner Quelle und Bedeutung auszulegen; sein Eingang ist nicht automatisch eine unabhängige Bestätigung dafür, dass die Person die SMS gesehen hat oder die Nachricht in jedem Fall auf dem Gerät angekommen ist.

Reichen die Belege für eine Entscheidung nicht aus, zeigen Sie je nach Modell einen Status wie „ausstehend“, „unbekannt“ oder „widersprüchlich“ an. Die Bezeichnung sollte klarstellen, dass keine bestätigte Zustellung vorliegt.

• Dokumentieren Sie, welche Ereignisse in der jeweiligen Integration welche Übergänge ermöglichen und was sie bedeuten.
• Legen Sie fest, wann ein unsicherer Status beibehalten und wann ein Widerspruch hervorgehoben wird.
• Werten Sie das Fehlen eines DLR, eine Annahme oder einen nicht interpretierten Code nicht als bestätigte Zustellung.

Behandeln Sie Widersprüche und verspätete DLR, ohne den Verlauf zu verlieren

Trifft ein DLR ein, nachdem die Schnittstelle einen Fehler gemeldet hat, oder scheinen sich zwei Quellen zu widersprechen, bewahren Sie beide Ereignisse auf und bewerten Sie ihre Bedeutung gemäß der geltenden Dokumentation. Löschen Sie das frühere Ereignis nicht und wählen Sie nicht automatisch das jüngste aus: Die Empfangszeit allein bestimmt nicht, welches Ereignis maßgeblicher ist.

Die Projektion kann aktualisiert werden, wenn eine neue Beobachtung relevante Belege liefert. Es sollte jedoch nachvollziehbar bleiben, was sich geändert hat, wann neu berechnet wurde und welche Regel dabei galt. Lässt sich der Konflikt nicht auflösen, ist es genauer, ihn sichtbar zu halten, statt ihn hinter einem einzigen endgültigen Status zu verbergen.

• Erfassen Sie Widersprüche ausdrücklich, statt sie stillschweigend zu überschreiben.
• Legen Sie fest, wann eine Regel einen Konflikt auflösen darf und wann eine Prüfung erforderlich ist.
• Bewahren Sie verspätete Ereignisse für Audits und eine erneute Verarbeitung auf.

Machen Sie den Abgleich reproduzierbar und auditierbar

Eine erneute Verarbeitung sollte dasselbe Ergebnis liefern, wenn sie mit derselben Ereignismenge, denselben Regeln und derselben Konfigurationsversion ausgeführt wird. Um diese Eigenschaft zu erreichen, trennen Sie die Erfassung von der Projektion und vermeiden Sie, dass das Ergebnis von nicht protokollierten Nebenwirkungen abhängt.

Idempotenz kann bei der Verarbeitung einer Benachrichtigung eingesetzt werden, wenn eine verlässliche Identität und ein definierter Geltungsbereich vorliegen. Fehlen diese, kann eine aggressive Deduplizierung gültige Belege verwerfen. Dokumentieren Sie lieber das verwendete Kriterium, bewahren Sie die empfangene Beobachtung auf und kennzeichnen Sie unsichere Zuordnungen.

Überwachen Sie auffällige Muster, etwa einen Anstieg wiederholter Ereignisse, ungewöhnlich lange Verzögerungen zwischen Ereignistypen oder wiederkehrende Widersprüche. Warnmeldungen sollten beschreiben, was beobachtet wurde; schreiben Sie eine Ursache nicht ohne Belege zu.

• Versionieren Sie die Projektionsregeln und protokollieren Sie die angewendete Version.
• Ermöglichen Sie die Neuberechnung von Status anhand des aufbewahrten Verlaufs.
• Messen Sie Duplikate, Verzögerungen und Konflikte je Schnittstelle und Geltungsbereich, ohne daraus Qualitätsgarantien abzuleiten.

Beispiel: Annahme, vorübergehender Fehler und verspäteter DLR

Angenommen, die API bestätigt die Annahme der Anfrage. Später trifft ein Signal ein, das Ihre Integration als vorübergehenden Fehler interpretiert, und danach erscheint ein DLR. Die genauen Bezeichnungen und Bedeutungen müssen aus der Dokumentation des jeweiligen Anbieters hervorgehen; dieses Beispiel legt keine verbindliche Reihenfolge fest.

Bewahren Sie zunächst alle drei Ereignisse mit ihren angegebenen und empfangenen Zeitpunkten, Kennungen und dem bekannten Geltungsbereich auf. Prüfen Sie, ob sie zuverlässig miteinander korreliert werden können. Wenden Sie dann die dokumentierten Regeln an: Die Annahme beweist keine Zustellung, der vorübergehende Fehler darf nicht durch ein später eintreffendes Ereignis gelöscht werden und der DLR darf die Schlussfolgerung nur so weit stützen, wie es seine Bedeutung zulässt.

Legt die Dokumentation fest, dass dieser DLR ein Zustellergebnis für die zugeordnete Nachricht darstellt, kann die Projektion dieses Ergebnis mit klar angegebenem Geltungsbereich wiedergeben. Sind Bedeutung, Identität oder Bezug zum Versand nicht bestätigt, behalten Sie den Status als unsicher oder widersprüchlich bei. In keinem Fall erlaubt das Beispiel die Aussage, dass der Nutzer die SMS gesehen hat oder ein unabhängiger Empfang auf dem Mobilgerät bestätigt wurde.

• Schlussfolgerung: Eine Annahme, ein Fehlersignal und ein DLR sind eingegangen; ihre Zuordnung und Bedeutung müssen überprüft werden.
• Ohne Dokumentation nicht schlussfolgern: dass die Annahme die Zustellung bestätigt oder der DLR den tatsächlichen Empfang durch den Nutzer beweist.
• Offenlassen: Konflikte bei Identität, Reihenfolge oder Bedeutung, die sich anhand der verfügbaren Belege nicht auflösen lassen.