Operativer A2P-SMS-Datenvertrag: Felder und Semantik

Was ein Vertrag über operative Daten regelt

Beim A2P-SMS-Verkehr – Nachrichten, die von einer Anwendung oder einem System an eine Person gesendet werden – können mehrere Organisationen dieselbe Nachricht zu unterschiedlichen Zeitpunkten und mit unterschiedlichen Begriffen erfassen. Ein Vertrag über operative Daten verringert Unklarheiten, indem er festlegt, was die einzelnen Felder bedeuten, wer sie meldet und wie die Ereignisse miteinander verknüpft werden.

Er ist weder eine universelle Norm noch eine Zustellgarantie. Vielmehr handelt es sich um eine Vereinbarung zwischen den Parteien über den Austausch und Abgleich von Informationen. Dabei sollte zwischen den Regelungen der Vereinbarung und den Anforderungen einer gegebenenfalls geltenden Schnittstelle oder technischen Spezifikation unterschieden werden. Normative Referenzen wie SMPP oder HTTP sollten direkt geprüft werden, bevor ihnen konkrete Anforderungen zugeschrieben werden.

• Das Schema vor der Integration oder Änderung des Datenaustauschs vereinbaren.
• Definitionen, Formate, Wertebereiche und Zuständigkeiten zusammen mit den Feldern dokumentieren.
• Die Interpretation von Statusmeldungen ausdrücklich vereinbaren und nicht von vermeintlichen Entsprechungen zwischen Systemen ausgehen.

Beteiligte und Grenzen der Zuständigkeit

Eine Übermittlungskette kann das Unternehmen, von dem der Verkehr ausgeht, eine Messaging-Plattform, einen oder mehrere Anbieter sowie einen Mobilfunkbetreiber umfassen. Die konkrete Route und die Beteiligung der einzelnen Stellen hängen von der Vereinbarung und der Dienstkonfiguration ab; eine überall identische Kette sollte nicht vorausgesetzt werden.

Legen Sie für jede Angabe fest, wer sie erzeugt und übermittelt, wer sie ändern darf und wer für ihre Interpretation verantwortlich ist. Beispielsweise kann der Absender die Verkehrskategorie angeben, eine Plattform eine interne Kennung zuweisen und ein Anbieter einen von einem anderen System erhaltenen Status weitergeben. Dies sind mögliche Gestaltungsentscheidungen, keine allgemeingültigen Zuständigkeiten.

Eine klare Trennung der Zuständigkeiten hilft bei der Untersuchung von Abweichungen: Eine Partei kann bestätigen, dass sie eine Anfrage angenommen hat, ohne damit zu behaupten, das Netz habe sie zugestellt. Eine andere Partei kann später ein Ergebnis melden, dessen Aussagekraft von der jeweiligen Quelle abhängt.

• Für jedes Feld und jeden Statusübergang eine zuständige Stelle benennen.
• Festlegen, wo die Informationsverantwortung jeder Partei endet.
• Eine Ansprechperson und ein Verfahren für den Abgleich von Abweichungen vorsehen, ohne anzunehmen, dass alle Parteien dieselben Ereignisse sehen.

Mindestfelder und ihre Bedeutung

Welche Daten mindestens erforderlich sind, hängt vom Zweck ab: Betrieb, Support, Abgleich oder Analyse. Beginnen Sie mit den Angaben, die nötig sind, um eine Anfrage mit späteren Ereignissen zu verknüpfen, und ergänzen Sie nur Felder, die die Parteien eindeutig definiert bereitstellen und nutzen können.

Dokumentieren Sie mindestens eine Nachrichtenkennung je System und, sofern vorhanden, systemübergreifende Korrelationskennungen. Geben Sie das Ziel im vereinbarten Format, den Absender, die angegebene Verkehrskategorie – zum Beispiel OTP, Transaktion oder Marketing – und, sofern bekannt, die angegebene Route an. Eine angegebene Route ist kein unabhängiger Beleg für den tatsächlich genommenen Weg.

Sinnvoll sind außerdem der Status, seine Quelle, der Zeitstempel des Ereignisses und gegebenenfalls der Fehlercode. Wird der Zielnetzbetreiber mitgeteilt, sollte angegeben werden, wie und wann er ermittelt wurde. Ein unbekannter Betreiber darf nicht durch Schlussfolgerungen ergänzt werden. Definieren Sie außerdem die Versionskennung und das Datum beziehungsweise den vereinbarten Gültigkeitszeitraum der anwendbaren Bedingungen oder Betriebsvereinbarung.

• Kennungen: Nachrichtenkennung im Absendersystem und verfügbare Korrelationsreferenzen.
• Kontext: Ziel, Absender, Verkehrskategorie, angegebene Route und gegebenenfalls der bekannte Betreiber.
• Ereignis: Status, Statusquelle, Datum und Uhrzeit, Fehlercode und Version der Bedingungen.
• Für jedes Feld Typ, Format, Pflichtstatus, Wertebereich und Bedeutung festlegen.

Status: Annahme, Versand, DLR und unbekanntes Ergebnis

Fassen Sie nicht den gesamten Ablauf in einem einzigen allgemeinen Feld „Status“ zusammen. Legen Sie die Phasen fest, die laut Vereinbarung unterschieden werden müssen: zum Beispiel die Annahme einer Anfrage durch eine Schnittstelle, einen von einer Partei gemeldeten Sendeversuch, den Eingang eines Zustellberichts oder ein weiterhin unbekanntes Ergebnis. Die genauen Bezeichnungen und Übergänge sind für jede Integration zu vereinbaren.

Ein DLR ist ein Statusbericht, der von einer bestimmten Quelle empfangen wurde. Halten Sie fest, wer ihn erstellt oder übermittelt hat und was er in diesem Kontext bedeutet. Für sich genommen ist er kein unabhängiger Nachweis dafür, dass die Nachricht auf dem Endgerät angezeigt oder von der Person gelesen wurde.

Behalten Sie den Status „unbekannt“ bei, wenn die Informationen für eine Schlussfolgerung nicht ausreichen. Das Ausbleiben eines DLR darf nicht automatisch als Fehler gewertet werden; ebenso wenig ist ein gemeldeter positiver Status eine Garantie für den Empfang. Weichen zwei Quellen voneinander ab, bewahren Sie beide Ereignisse auf und dokumentieren Sie, welcher Prozess welches Ereignis aus welchem Grund verwendet.

• Jeden Status anhand einer Beschreibung, der meldenden Stelle und der zulässigen Übergänge definieren.
• Gemeldeten Status von der internen Bewertung eines Falls durch eine Partei trennen.
• Ursprüngliche Ereignisse aufbewahren, damit sich der Ablauf rekonstruieren und Abweichungen klären lassen.

Zeitstempel und Ereignisreihenfolge

Ein Zeitstempel sollte erkennen lassen, wann ein Ereignis auftrat oder erfasst wurde und welche Zeitzone gilt. Vereinbaren Sie das Format, die verfügbare Genauigkeit und ob der Zeitwert den Ereigniszeitpunkt, den Eingang des Berichts oder die Erfassung im System bezeichnet.

Leiten Sie die Reihenfolge nicht allein aus dem Eingang bei einer Plattform ab: Ereignisse können in einer anderen Reihenfolge eintreffen, als die jeweiligen Parteien ihnen zuordnen. Bewahren Sie verfügbare Ereigniskennungen oder Sequenznummern auf und erfassen Sie Ursprungs- und Eingangszeit getrennt, wenn dies für den Abgleich erforderlich ist.

Wenn eine Quelle keine Zeitzone oder keine ausreichende Genauigkeit angibt, halten Sie das fest. Ergänzen Sie solche Angaben nicht so, als wären sie beobachtet worden.

• Format für Datum und Uhrzeit, Zeitzone und Genauigkeit vereinbaren.
• Ereigniszeit, Eingangszeit und Verarbeitungszeit unterscheiden.
• Festlegen, wie Ereignisse geordnet werden, wenn Zeitstempel übereinstimmen oder unvollständig sind.

Datenquelle und Belegstärke

Derselbe Wert kann je nach Angabequelle und Ermittlungsmethode unterschiedlich aussagekräftig sein. Ergänzen Sie Metadaten zur Herkunft, wenn sie die Interpretation des Datensatzes erleichtern: Ursprungssystem, übermittelnde Partei, Beobachtungszeitpunkt und Kennzeichnung als deklarierte Angabe, empfangenes Ereignis oder unabhängige Beobachtung.

Beispielsweise kann eine Plattform eine Route angeben, während ein Statusbericht über einen Anbieter eingeht. Der Vertrag sollte verhindern, dass diese Unterscheidung bei der Umwandlung oder Zusammenführung der Daten verloren geht. Liegt keine unabhängige Überprüfung vor, ist dies ausdrücklich anzugeben, statt eine solche anzudeuten.

Legen Sie außerdem fest, welche Belege für welchen Zweck akzeptiert werden: Support, Abgleich oder Analyse. Ein Wert, der bei einer Untersuchung hilfreich ist, reicht nicht zwangsläufig aus, um eine geschäftliche Streitigkeit zu klären.

• Herkunft der Daten und übermittelnde Partei kennzeichnen.
• Direkte Beobachtung, Angabe und empfangenes Ereignis voneinander unterscheiden.
• Einen weitergeleiteten Status nicht stärker darstellen, als es die verfügbare Quelle erlaubt.

Nullwerte, Wertebereiche und Fehlercodes

Ein leeres Feld kann bedeuten, dass der Wert unbekannt ist, nicht erhoben wurde, nicht zutrifft oder nicht eingegangen ist. Der Vertrag sollte diese Fälle unterscheiden, statt die Interpretation jedem System selbst zu überlassen. Lassen sich die Unterschiede im Austauschformat nicht abbilden, dokumentieren Sie eine gemeinsame Konvention und deren Grenzen.

Legen Sie kontrollierte Wertebereiche für Kategorien und Status fest und vereinbaren Sie den Umgang mit anbieterspezifischen Werten. Wenn Daten zwischen Parteien verglichen werden müssen, bewahren Sie den Originalcode zusammen mit einer normalisierten Kategorie auf. Durch die Normalisierung sollte nicht der Wert verloren gehen, der die Untersuchung des Ereignisses an seiner Quelle ermöglicht.

Legen Sie fest, wer Werte, Statusmeldungen oder Absender zu einer vereinbarten Liste hinzufügen darf, wie diese dokumentiert werden und ab wann sie gelten. Verwenden Sie einen älteren Wert nicht mit einer neuen Bedeutung weiter.

• Unbekannt, nicht vorhanden, nicht zutreffend und nicht eingegangen ausdrücklich unterscheiden.
• Den Originalwert beibehalten und, sofern vereinbart, um einen normalisierten Wert ergänzen.
• Definitionen und Beispiele für anbieterspezifische Codes bereitstellen, ohne sie als universell darzustellen.

Versionierung und Schemaänderungen

Bei jedem Austausch sollte erkennbar sein, welche Schemaversion und welche Version der Betriebsbedingungen angewendet wurden. Vereinbaren Sie, wie diese Version angegeben wird und welchem Zeitraum des Nachrichtenverkehrs sie zugeordnet ist, statt anzunehmen, der Schnittstellenname allein identifiziere die geltenden Regeln.

Legen Sie im Voraus ein Änderungsverfahren fest: Wer schlägt Änderungen vor, wer genehmigt sie, wie werden sie getestet und wann treten sie in Kraft? Ein optionales zusätzliches Feld ist möglicherweise leichter einzuführen als eine Änderung der Bedeutung eines Status oder eine neue Pflichtangabe. Bewerten Sie die Auswirkungen anhand der tatsächlichen Produzenten und Verbraucher.

Geben Sie für Übergangsphasen an, welche Versionen gleichzeitig verwendet werden dürfen, wie die Datensätze gekennzeichnet werden und wie lange die Kompatibilität erhalten bleibt, sofern die Parteien eine Frist vereinbaren. Ändern Sie die Semantik nicht ohne Versionswechsel oder eine unmissverständliche Mitteilung.

• Schema versionieren und die Version der geltenden Bedingungen erfassen.
• Änderungen nach ihren Auswirkungen auf Datenproduzenten, -verbraucher und Abgleichprozesse einordnen.
• Genehmigung, Tests, Inkrafttreten und Umgang mit früheren Versionen vereinbaren.