Korrelation von A2P-SMS-Nachrichten: Nachverfolgbarkeit zwischen API, SMPP, Anbietern und DLR

Warum die Anbieter-ID nicht ausreicht

Eine von einem Anbieter vergebene Kennung ist erforderlich, reicht jedoch selten aus, um den gesamten Lebenszyklus einer A2P-SMS zu erklären. In der Regel identifiziert sie eine konkrete Annahme innerhalb der Domäne dieses Anbieters. Sie repräsentiert nicht eigenständig die ursprüngliche Kundenanfrage, die Routing-Entscheidung, einen späteren Wiederholungsversuch, die Segmente einer verketteten Nachricht oder Ereignisse, die danach eintreffen können.

Das Problem zeigt sich im realen Betrieb: Eine Anfrage kann in der Warteschlange verbleiben, mehr als einen Versuch erzeugen, gemäß einer internen Richtlinie die Route wechseln oder einen verspäteten Callback erhalten. Speichert das System nur die externe Kennung, lässt sich kaum präzise beantworten, was gesendet wurde, welcher Versuch einen DLR ausgelöst hat und welcher Teil der Nachweise aus welchem System stammt.

Die operative Regel lautet, eine stabile interne Kennung für die logische Nachricht beizubehalten und die an jeder technischen Grenze vergebenen Identifikatoren zu protokollieren, ohne sie zu ersetzen. Die Anbieter-ID sollte als Korrelationsschlüssel innerhalb einer umfassenderen Beziehung behandelt werden, nicht als globale Identität der Nachricht.

• Setzen Sie die Annahme durch den Anbieter nicht mit der Zustellung an das Endgerät gleich.
• Verwenden Sie eine Anbieter-ID nicht erneut als interne Geschäfts-ID.
• Gehen Sie nicht davon aus, dass zwei Anbieter dasselbe Format, denselben Geltungsbereich oder dieselbe Aufbewahrungsdauer für ihre Kennungen verwenden.
• Bewahren Sie die ursprünglichen Antworten und Ereignisse zusammen mit ihrer normalisierten Interpretation auf.

Karte der Nachverfolgbarkeitskette

Die Nachverfolgbarkeit sollte Zustände und Ereignisse modellieren, nicht nur eine abschließende Statustabelle. Eine minimale Kette beginnt mit der vom Kunden empfangenen Anfrage, setzt sich mit deren Validierung und Einreihung in die Warteschlange fort und erfasst jeden vom System erzeugten Sendeversuch. Für jeden von einem Anbieter angenommenen Versuch wird die von diesem Anbieter zurückgegebene Kennung ergänzt. DLRs und spätere Callbacks werden als getrennte Ereignisse gespeichert.

Dieser Ansatz verhindert einen häufigen Kontextverlust: das Überschreiben des vorherigen Status durch das zuletzt empfangene Ereignis. Ein DLR ist ein Nachweis für ein späteres Ereignis; er ersetzt nicht den Nachweis, dass eine Anfrage eingegangen ist, ein Versuch erstellt wurde oder ein Anbieter auf die Übermittlung geantwortet hat.

Eine praktische Karte kann dieser Abfolge folgen: Kundenanfrage, interne logische Nachricht, Routing-Entscheidung, Sendeversuch, HTTP- oder SMPP-Übermittlung, Annahme oder Fehler des Anbieters sowie spätere Statusereignisse. Bei Segmentierung sollte jedes Segment mit der logischen Nachricht und, sofern zutreffend, mit dem Versuch verknüpft werden, der es erzeugt hat.

• Kundenanfrage: Erfasst die Kundenreferenz, falls vorhanden, sowie den Empfangszeitpunkt.
• Logische Nachricht: Repräsentiert die Absicht, einen Inhalt an ein Ziel zu senden.
• Versuch: Repräsentiert eine konkrete Übermittlung über eine bestimmte Route oder einen bestimmten Anbieter.
• Annahme durch den Anbieter: Erfasst die externe ID und die erhaltene Antwort.
• DLR- oder Callback-Ereignis: Bewahrt das ursprüngliche Payload, den Empfangszeitpunkt und die resultierende Zuordnung auf.
• Abgeleiteter Status: Muss aus den Ereignissen rekonstruierbar sein und darf sie nicht ersetzen.

Empfohlenes Identifikatorenmodell

Ein robustes Schema trennt Identifikatoren nach Funktion und Geltungsbereich. Die Correlation ID verbindet die ursprüngliche Anfrage mit der internen Verarbeitung. Der Idempotency Key schützt vor Duplikaten derselben Kundenanfrage. Die interne Message ID identifiziert die logische Nachricht. Die Attempt ID identifiziert jede konkrete Übermittlung. Die Provider Message ID erfasst die Kennung, die ein Anbieter für eine konkrete Annahme zurückgibt.

Diese Schlüssel sind nicht austauschbar. Insbesondere darf ein Wiederholungsversuch nicht dieselbe Attempt ID erhalten, auch wenn er dieselbe logische Nachricht repräsentiert. Ebenso sollten zwei wiederholte Anfragen keine unterschiedlichen logischen Nachrichten erzeugen, wenn derselbe gültige Idempotency Key innerhalb der von der Plattform definierten Richtlinie erkannt wird.

Erzeugen Sie interne IDs mit ausreichender Eindeutigkeit und behandeln Sie sie für externe Kunden als undurchsichtig, sofern Ihr Integrationsvertrag nichts anderes festlegt. Die ID-Struktur sollte weder Telefonnummern noch Inhalte, Anbieter, Routen oder sensible betriebliche Informationen offenlegen.

• Correlation ID: Wird beim Eingang der Operation oder des Geschäftskontexts erstellt; verbindet interne Systeme und zugehörige Protokolle.
• Idempotency Key: Wird vom Kunden bereitgestellt oder durch die Integration definiert; erkennt Wiederholungen derselben Operation.
• Interne Message ID: Wird bei Annahme der logischen Nachricht im eigenen System erstellt; bleibt während ihres Lebenszyklus stabil.
• Attempt ID: Wird für jeden Übermittlungsversuch erstellt; ändert sich bei jedem Wiederholungsversuch oder Routenwechsel.
• Provider Message ID: Wird nach Annahme eines Versuchs vom Anbieter empfangen; kann ein undurchsichtiges, anbieterspezifisches Format haben.
• Event ID: Wird bei der Verarbeitung jedes Callbacks, DLRs oder Abfrageergebnisses erstellt; ermöglicht die Deduplizierung und Prüfung von Ereignissen.

Was jede Partei erstellen sollte und was nicht wiederverwendet werden darf

Der Kunde kann einen Idempotency Key oder eine Geschäftsreferenz bereitstellen. Die Plattform sollte eigene Korrelations-, Nachrichten-, Versuchs- und Ereignis-IDs erstellen. Jeder Anbieter kann seine eigene Nachrichtenkennung zurückgeben. Diese Verteilung schafft klare Verantwortlichkeiten und verhindert, dass ein Schlüssel mit begrenztem Geltungsbereich fälschlich zu einem universellen Schlüssel wird.

Verwenden Sie einen Idempotency Key nicht als Message ID und eine interne Message ID nicht als Attempt ID. Machen Sie auch keine Provider Message ID zu einer Kundenreferenz. Diese Wiederverwendungen scheinen das Modell zunächst zu vereinfachen, verhindern jedoch die Darstellung von Wiederholungsversuchen, Routenmigrationen und Abweichungen zwischen Systemen.

Wenn eine HTTP-Integration das Hinzufügen eigener Parameter zur Callback-URL erlaubt, können diese als zusätzlicher Zuordnungshinweis dienen. Sie ersetzen jedoch weder die native Anbieter-ID noch rechtfertigen sie den Verzicht auf Herkunftsvalidierung, vollständige Ereignisprotokollierung und spätere Abstimmung.

• Eine wiederholte Anfrage kann denselben Idempotency Key verwenden, darf aber nicht zwei logische Nachrichten erzeugen, wenn die Richtlinie sie als Duplikat erkennt.
• Eine logische Nachricht kann viele Versuche haben.
• Jeder Versuch kann je nach Schnittstelle und verfügbaren Ereignissen null, eine oder mehrere externe Kennungen erhalten.
• Ein eingegangener Callback darf nicht automatisch eine neue Nachricht erzeugen, wenn seine Referenz unbekannt ist.
• Die Zuordnung sollte Methode und Vertrauensniveau erfassen: exakt, wahrscheinlich oder nicht aufgelöst.

Eins-zu-eins- und Eins-zu-viele-Beziehungen: Nachrichten, Segmente, Wiederholungen, Routen und DLRs

Die logische Nachricht ist die zentrale Entität, entspricht jedoch nicht immer einer einzigen Übermittlung oder einer einzelnen technischen SMS-Einheit. Ein verketteter Inhalt kann in mehrere Segmente aufgeteilt werden. Dieselbe Nachricht kann mehrere Versuche erzeugen. Jeder Versuch kann über eine andere Route laufen und getrennte spätere Ereignisse hervorbringen.

Modellieren Sie diese Beziehungen ausdrücklich. Eine logische Nachricht kann ein oder mehrere Segmente haben; jedes Segment kann ein eigenes technisches Ergebnis erfordern. Eine logische Nachricht kann einen oder mehrere Versuche haben, während ein Versuch genau einer logischen Nachricht zugeordnet sein muss. Ein Versuch kann eine dokumentierte Routing-Entscheidung sowie ein oder mehrere zugehörige Anbieter- oder DLR-Ereignisse haben.

In SMPP können verkettete Nachrichten über sar_msg_ref_num, sar_total_segments und sar_segment_seqnum verknüpft werden. Die SAR-Referenz wird vom Originator erzeugt, um die Wiederzusammensetzung zu ermöglichen. Es ist sinnvoll, sie als technisches Segmentierungsattribut zu speichern, sie darf jedoch nicht die interne Message ID der Plattform ersetzen.

• Logische Nachricht zu Segmenten: eins zu viele.
• Logische Nachricht zu Versuchen: eins zu viele.
• Versuch zu Anbieter oder Route: normalerweise eins zu eins pro Übermittlung, wobei der Verlauf der Entscheidungen erhalten bleiben sollte.
• Versuch zu Ereignissen: eins zu viele.
• Segment zu DLR: kann eins zu viele sein, wenn wiederholte Ereignisse, Statusänderungen oder über mehr als einen Kanal empfangene Nachweise vorliegen.

HTTP und SMPP: praktische Unterschiede bei der Korrelation

Bei einer HTTP-API antwortet der Anbieter in der Regel mit einer Ressourcen- oder Nachrichtenkennung. Diese sollte zusammen mit der ursprünglichen Antwort, dem Timestamp und dem Anfangsstatus gespeichert werden. Spätere Callbacks sollten zunächst über diese native Kennung zugeordnet werden, sofern sie vorhanden ist. Stellt der Anbieter eine Ressourcenabfrage bereit, kann diese zum Abgleich fehlender Callbacks oder nicht finaler Statuswerte dienen.

In SMPP korreliert die sequence_number eine Anfrage-PDU mit ihrer zugehörigen Antwort innerhalb einer asynchronen Sitzung. Sie wird vom Originator der PDU vergeben, monoton erhöht und von der zugehörigen Antwort übernommen. Sie ist daher eine kurzlebige Transportreferenz und keine dauerhafte Nachrichtenkennung zwischen Systemen oder Anbietern.

Die Antwort submit_sm_resp kann eine vom SMSC vergebene message_id zurückgeben. Diese ID ist undurchsichtig und befindet sich in der Domäne des SMSC. In einem DLR identifiziert das TLV receipted_message_id die Nachricht, auf die sich der Bericht bezieht, anhand derselben undurchsichtigen ID, die bei Annahme der ursprünglichen Übermittlung zurückgegeben wurde. Speichern Sie sowohl den Originalwert als auch den vollständigen DLR, um nachvollziehbar zu machen, wie die Zuordnung erfolgte.

Um DLRs in SMPP anzufordern, wird registered_delivery in submit_sm oder data_sm verwendet. Der Standard sieht vor, ein finales Erfolgs- oder Fehlerergebnis oder nur einen finalen Fehler anzufordern. Die Anforderung eines Berichts garantiert weder, dass ein Ereignis eintrifft, noch dass es ein einheitliches Format hat oder den unabhängigen Empfang auf dem Endgerät nachweist.

• HTTP: Verknüpfen Sie die Erstellungsantwort, die native ID und jeden Callback mit dem entsprechenden Versuch.
• SMPP sequence_number: Verwenden Sie sie für Anfrage und Antwort innerhalb der Sitzung, niemals als dauerhafte Geschäftskennung.
• SMPP message_id: Speichern Sie sie als externe ID, die einer akzeptierten Übermittlung zugewiesen wurde.
• SMPP receipted_message_id: Verwenden Sie sie als primären DLR-Zuordnungsschlüssel, wenn sie vorhanden ist und übereinstimmt.
• SMPP user_message_reference: Kann helfen, wenn sie weitergegeben wird, ist jedoch ein optionales TLV; entwerfen Sie keine Garantie auf Grundlage ihrer Präsenz.
• DLR in short_message: Setzen Sie kein universelles Format voraus; die SMPP-Spezifikation weist darauf hin, dass es anbieterspezifisch sein kann.

Operative Felder, die erfasst werden sollten

Identifikatoren erklären, welche Objekte miteinander verbunden sind; Metadaten erklären, was unter welchen Bedingungen geschehen ist. Erfassen Sie getrennte Timestamps für den Eingang der Anfrage, die Erstellung der Nachricht, die Erstellung des Versuchs, den Versand an den Anbieter, die Antwort des Anbieters, den Empfang des Callbacks und die abgeleitete Aktualisierung. Vermeiden Sie ein einziges Datumsfeld für all diese Phasen.

Bewahren Sie das Ziel in einer normalisierten Darstellung auf und getrennt von operativen Referenzen. Für SMS ist E.164 eine hilfreiche Referenz für die internationale Normalisierung von Nummern. Eine normalisierte Nummer darf jedoch nicht als ausschließlicher Korrelationsschlüssel verwendet werden: Mehrere Nachrichten können an dasselbe Ziel gerichtet sein, und Zielinformationen sind potenziell personenbezogen.

Erfassen Sie Absender, Kodierung, Länge und Anzahl der Segmente, angeforderte DLR-Konfiguration, verwendete Schnittstelle, Validierungsergebnis und eine Versionskennung der angewendeten Routing-Richtlinie. Die Richtlinienversion ermöglicht es, eine historische Entscheidung zu erklären, ohne sie aus der aktuellen Konfiguration abzuleiten.

• Timestamps mit klar definierter Zeitzone und Zeitquelle.
• Normalisiertes Ziel, das als potenziell personenbezogenes Datum geschützt wird.
• Bei der Übermittlung verwendeter Absender, ohne anzunehmen, dass er den tatsächlichen Absender identifiziert.
• Kodierung, Größe und tatsächliche Segmentierung.
• Kanal und Schnittstelle: HTTP, SMPP oder ein anderer interner Adapter.
• Ausgewählte Route oder ausgewählter Anbieter sowie Version der Routing-Richtlinie.
• DLR-Anforderung, Annahmeantwort, Fehlercode und ursprüngliches Ereignis-Payload.
• Zuordnungsmethode und Grad der Sicherheit.

Doppelte, nicht geordnete oder nicht zuordenbare Callbacks

Callbacks sind asynchrone Ereignisse. Sie können doppelt, in falscher Reihenfolge, mit zusätzlichen Feldern oder ohne die erwartete Referenz eintreffen. Das richtige Design besteht nicht darin, auf die Reihenfolge des Eintreffens zu vertrauen, sondern jedes Ereignis zu bewahren und anhand expliziter Regeln einen abgeleiteten Status zu berechnen.

Zur Deduplizierung berechnen Sie einen Fingerabdruck des ursprünglichen Payloads und kombinieren Sie, soweit möglich, Anbieter, externe Kennung, Ereignistyp, gemeldeten Status und Empfangszeitpunkt. Die Deduplizierung sollte gleichwertige Ereignisse markieren, ohne die empfangenen Nachweise zu löschen. Haben zwei Ereignisse dieselbe Referenz, aber unterschiedliche Daten, bewahren Sie sie als getrennte Datensätze auf und dokumentieren Sie die Abweichung.

Wenn eine Referenz nicht erkannt wird, speichern Sie das Ereignis in einem Quarantänebereich oder Bereich für nicht zugeordnete Ereignisse. Erstellen Sie keine Beziehung, die nur auf Übereinstimmungen bei Ziel, Zeitpunkt oder Inhalt basiert: Diese Attribute können falsch positive Ergebnisse erzeugen. Wenden Sie probabilistische Zuordnungen nur an, wenn die operative Richtlinie dies erlaubt, kennzeichnen Sie sie entsprechend und bewahren Sie das ursprüngliche Ereignis unverändert auf.

Callback-Parameter können je nach Kanal und Ereignistyp variieren und erweitert werden. Empfänger sollten neue Felder tolerieren und das Payload bewahren, ohne zu verlangen, dass alle Anbieter dasselbe Schema verwenden.

• Speichern Sie zuerst das ursprüngliche Payload und die relevanten Header.
• Validieren Sie Authentizität und Herkunft entsprechend dem von jedem Anbieter dokumentierten Mechanismus.
• Deduplizieren Sie, ohne die ursprünglichen Nachweise zu löschen.
• Nehmen Sie keine chronologische Reihenfolge aufgrund der Empfangsreihenfolge an.
• Bewahren Sie nicht zugeordnete Ereignisse für Untersuchung und Abgleich auf.
• Stufen Sie eine wahrscheinliche Zuordnung nicht ohne überprüfbare Referenz zu einer sicheren Zuordnung hoch.