Zurück zum Blog A2P-SMS-Betrieb

Validierung von A2P-SMS-Massenupload-Dateien: Betriebsleitfaden

Ein Leitfaden für mehrstufige Prüfungen von A2P-SMS-Dateien: korrigierbare Fehler erkennen und die Nachverfolgbarkeit sichern, ohne Validierung mit Einwilligung oder Zustellung gleichzusetzen.

Mehrstufiger Validierungsablauf für eine A2P-SMS-Massenupload-Datei

Welche Probleme eine Validierung vor dem Erstellen von Nachrichten verhindert

Ein Massenupload kann korrekte Daten, unvollständige Datensätze und Fehler enthalten, die das Interpretieren einer Zeile verhindern. Werden die Daten vor dem Erstellen von Nachrichten validiert, lassen sich solche Probleme in einem kontrollierten Schritt erkennen und die zu prüfenden Datensätze anzeigen, statt sie erst nach Beginn der Verarbeitung festzustellen.

Validierung ist als Prüfung von Daten anhand zuvor festgelegter Regeln zu verstehen. Sie belegt weder, dass eine Einwilligung zur Kontaktaufnahme vorliegt, noch, dass ein Absender im Zielland zugelassen ist oder eine Nachricht zugestellt wird. Diese Prüfungen gehören zu getrennten Prozessen und hängen vom jeweiligen Kontext, den geltenden Regeln und den verfügbaren Funktionen ab.

  • Legen Sie fest, welche Struktur das System akzeptiert und was die einzelnen Felder bedeuten.
  • Unterscheiden Sie Lesefehler von Verstößen gegen betriebliche Regeln.
  • Sichern Sie eine eindeutige Zuordnung zwischen jedem ursprünglichen Datensatz und seinem Ergebnis.
Welche Probleme eine Validierung vor dem Erstellen von Nachrichten verhindert

Den Datenvertrag festlegen

Dokumentieren Sie vor der Annahme von Dateien einen Datenvertrag: unterstützte Formate, erwartete Kodierung, erkannte Überschriften, Pflichtfelder und den Umgang mit leeren Werten. Wenn Varianten zulässig sind, legen Sie diese ausdrücklich fest. Verlassen Sie sich nicht auf Annahmen wie eine bestimmte Spaltenreihenfolge oder die automatische Interpretation von Datums- und Zahlenwerten.

Prüfen Sie beim Einlesen der Datei, ob sie sich im angegebenen Format interpretieren lässt und ob die erforderlichen Spalten vorhanden sind. Unterscheiden Sie zwischen einer Datei, die nicht geparst werden kann, und einer lesbaren Datei mit unvollständigen Zeilen. Der erste Fall betrifft die gesamte Datei; der zweite lässt sich üblicherweise pro Datensatz melden.

Die verfügbaren Informationen belegen keine einheitliche Konvention für Kodierung, Überschriften oder Pflichtfelder bei allen A2P-Massenuploads. Daher müssen diese Regeln für jede Integration festgelegt und den Personen, die die Dateien vorbereiten, mitgeteilt werden.

  • Stellen Sie eine Vorlage und eine Beschreibung jeder Spalte bereit, einschließlich Formaten und zulässigen Werten.
  • Geben Sie an, ob zusätzliche Spalten, leere Felder oder alternative Überschriften toleriert werden.
  • Verwenden Sie unterschiedliche Fehlermeldungen für eine nicht lesbare Datei, eine fehlende Überschrift und einen leeren Pflichtwert.
Den Datenvertrag festlegen

Prüfungen pro Datensatz: Nummer, Absender und Inhalt

Prüfen Sie für jede Zeile, ob die Empfängernummer vorhanden ist und gemäß den für die Integration vereinbarten Regeln interpretiert werden kann. Falls eine Normalisierung erfolgt, definieren und dokumentieren Sie deren Verhalten. Fügen Sie keine Präfixe hinzu, entfernen Sie keine Zeichen und ändern Sie die Interpretation nicht aufgrund einer Annahme. Die Empfehlung E.164 ist eine Referenz für die internationale Nummerierung. Die hier verfügbaren Informationen reichen jedoch nicht aus, um ihre Regeln näher zu erläutern oder daraus abzuleiten, dass eine entsprechende Zeichenfolge routbar ist.

Prüfen Sie, ob Absender und Inhalt vorhanden sind, sofern der Anwendungsfall dies erfordert, und ob sie sich im erwarteten Format darstellen lassen. Eine syntaktisch gültige Absenderangabe beweist nicht, dass sie für das Ziel zugelassen ist. Ebenso bestätigt die Lesbarkeit des Textes nicht, dass die Regeln zur Einwilligung, geltende Richtlinien oder Einschränkungen einer Route eingehalten werden.

Trennen Sie Datenprüfungen von Versandentscheidungen. Eine Zeile kann syntaktisch gültig sein und dennoch vor der Verarbeitung eine Prüfung der Zulassung, Richtlinien oder Berechtigung erfordern.

  • Legen Sie die zulässigen Nummernformate fest und bestimmen Sie, welche Fälle abgelehnt oder geprüft werden müssen.
  • Validieren Sie den Absender anhand der für den jeweiligen Kontext konfigurierten Regeln, ohne die syntaktische Prüfung als Zulassung zu behandeln.
  • Prüfen Sie, ob der Inhalt interpretierbar ist und die erforderlichen Personalisierungsfelder verfügbar sind.

Duplikate erkennen, ohne die Absicht zu verändern

Zwei ähnliche Zeilen sind nicht zwangsläufig Duplikate: Sie können legitime Nachrichten an dieselbe Person darstellen, etwa zu unterschiedlichen Zeitpunkten oder für verschiedene Zwecke. Bevor Sie Duplikate markieren, legen Sie fest, welche Kombination von Feldern und gegebenenfalls welcher Zeitraum zum Erkennen von Übereinstimmungen verwendet wird. Löschen oder kombinieren Sie Datensätze nicht automatisch, wenn dafür keine mit der Prozessverantwortung abgestimmte Regel besteht.

Es ist sinnvoll, zwischen einer exakten Dateiduplikation, einer Übereinstimmung nach einer Geschäftsregel und einer legitimen Wiederholung zu unterscheiden. Die Entscheidung kann darin bestehen, zu warnen, zu blockieren oder den Datensatz zuzulassen. Sie muss ausdrücklich festgelegt, nachvollziehbar und mit dem Versandzweck vereinbar sein.

  • Legen Sie den Vergleichsschlüssel und den Erkennungsumfang fest, bevor Sie die Prüfung implementieren.
  • Bewahren Sie die ursprünglichen Datensätze auf und geben Sie an, welche Zeilen übereinstimmen.
  • Stellen Sie eine Übereinstimmung nicht als Beweis für einen Fehler oder Betrug dar.

Fehler nach Verarbeitungsstufe klassifizieren

Eine sinnvolle Klassifizierung unterscheidet mindestens drei Ebenen. Formatfehler verhindern, dass die Datei gelesen oder ein Feld interpretiert werden kann. Fehler bei Geschäftsregeln zeigen an, dass ein Wert eine vereinbarte Bedingung nicht erfüllt. Versandbeschränkungen umfassen spätere Entscheidungen zu Zulassung, Richtlinien oder der Möglichkeit, den Datenverkehr zu verarbeiten. Fassen Sie diese Kategorien nicht in einem allgemeinen Status wie „ungültig“ zusammen.

Ein korrigierbarer Fehler lässt sich durch eine Änderung der Datei oder des Datums beheben, woraufhin die Validierung erneut ausgeführt wird. Eine endgültige Ablehnung gemäß den konfigurierten Regeln bedeutet, dass der Datensatz diesen Prozess nicht durchlaufen soll. Bezeichnen Sie einen Fehler nicht als endgültig, wenn lediglich Informationen oder eine Prüfung fehlen. Die Klassifizierung sollte die bekannte Ursache wiedergeben und keine Schlussfolgerung enthalten, die sich mit der Prüfung nicht belegen lässt.

  • Verwenden Sie getrennte Status für eine nicht lesbare Datei, einen korrigierbaren Datenfehler, einen Regelverstoß und eine ausstehende Prüfung.
  • Erklären Sie, welche Maßnahme die Person ergreifen kann, die den Upload vorbereitet.
  • Leiten Sie aus einem Validierungsfehler keine Aussage über Einwilligung, Identität oder Zustellung ab.

Umsetzbare Ergebnisse und Zuordnung zur Zeile

Jedes Validierungsergebnis sollte angeben, welcher Datensatz geprüft wurde und warum ein Hinweis oder eine Ablehnung ausgegeben wurde. Bewahren Sie dafür eine stabile Referenz zum Quelldatensatz auf, beispielsweise die Zeilennummer in der empfangenen Datei und, falls vorhanden, eine eigene Upload-ID. Die Referenz muss erhalten bleiben, auch wenn das System Werte zur Verarbeitung transformiert oder normalisiert.

Beschreiben Sie das betroffene Feld, die angewandte Regel und eine mögliche Maßnahme. Vermeiden Sie vage Meldungen wie „Nummernfehler“, wenn Sie stattdessen angeben können, dass der Empfänger fehlt oder der Wert das erwartete Format nicht erfüllt. Die zurückgegebenen Informationen sollten für eine Korrektur ausreichen, aber keine unnötigen personenbezogenen Daten offenlegen.

  • Geben Sie Upload-ID, Zeilenreferenz, Feld, Ergebnis und einen verständlichen Grund an.
  • Unterscheiden Sie Hinweise von Ablehnungen und erläutern Sie den nächsten Schritt.
  • Schützen Sie personenbezogene Daten in Berichten, Protokollen und Supportkanälen.

Große Uploads, Stapel und erneute Übermittlungen

Die maximale Dateigröße, die Zahl der Datensätze pro Stapel und die Verarbeitungsstrategie hängen vom empfangenden System ab. Hier liegen keine Belege vor, auf deren Grundlage allgemeingültige Zahlenwerte empfohlen werden könnten. Legen Sie die Grenzen anhand der überprüften Funktionen der konkreten Implementierung fest und veröffentlichen Sie sie, bevor Teams ihre Dateien vorbereiten.

Bewahren Sie bei einer Stapelverarbeitung die Upload-ID und die Position jeder Zeile in allen Verarbeitungsstufen auf. Gestalten Sie erneute Übermittlungen so, dass ein Teilausfall nicht stillschweigend dazu führt, dass eine Wiederholung als neue Nachricht behandelt wird. Die Semantik von Wiederholungsversuchen und Deduplizierung muss in der Integration festgelegt sein; sie lässt sich nicht allein daraus ableiten, dass die Datei erneut gesendet wurde.

  • Dokumentieren Sie die in der konkreten Integration überprüften Grenzen und Verhaltensweisen.
  • Protokollieren Sie, welche Teile validiert und verarbeitet wurden, ohne Teilergebnisse zu verbergen.
  • Legen Sie fest, wie eine wiederholte Übermittlung erkannt wird, bevor erneute Übermittlungen zugelassen werden.

Nachverfolgbarkeit und angemessene Aufbewahrung

Stellen Sie eine überprüfbare Verbindung zwischen der empfangenen Datei, jeder Zeile, dem Validierungsergebnis und jeder daraus erstellten Nachricht her. Diese Nachverfolgbarkeit erleichtert die Untersuchung von Fehlern und die Beantwortung betrieblicher Fragen, sollte sich jedoch auf die Daten beschränken, die für den festgelegten Zweck erforderlich sind.

Legen Sie eine Aufbewahrungsrichtlinie für Dateien und Ergebnisse fest, aus der hervorgeht, wer Zugriff hat, welche Daten gespeichert und wann sie gelöscht werden. Die verfügbaren Informationen bestimmen keine geeignete Aufbewahrungsfrist und ersetzen nicht die jeweils geltenden rechtlichen Pflichten. Legen Sie diese Grenzen gemeinsam mit den Verantwortlichen für Datenschutz, Sicherheit und Compliance fest. Bewahren Sie keine vollständigen Kopien auf, wenn eine minimale Referenz genügt.

  • Bewahren Sie Upload- und Zeilenkennungen auf, mit denen sich Ergebnisse nachvollziehen lassen, ohne unnötig Daten zu vervielfältigen.
  • Beschränken Sie Zugriffe und nehmen Sie vollständige Nummern oder Nachrichten nur dann in Protokolle auf, wenn dies erforderlich ist.
  • Legen Sie die Aufbewahrungsfristen anhand des Zwecks und der geltenden Pflichten fest.
FAQ

Häufige Fragen

Beweist eine validierte Datei, dass die Empfänger ihre Einwilligung gegeben haben?

Nein. Die Validierung von Struktur und Daten belegt lediglich, dass die für den Upload konfigurierten Prüfungen erfüllt sind. Einwilligung und weitere Anforderungen an den Nachrichtenversand erfordern unabhängige Prüfungen.

Garantiert eine Nummer, die die Validierung besteht, dass die SMS zugestellt wird?

Nein. Eine Formatprüfung belegt weder, dass die Nummer aktiv ist, noch, dass die Route verfügbar ist oder die Nachricht zugestellt wird. Sie darf nicht als Zustellgarantie dargestellt werden.

Sollten doppelte Zeilen automatisch gelöscht werden?

Nicht ohne eine abgestimmte Regel. Ähnliche Einträge können legitimen Nachrichten entsprechen. Legen Sie fest, wie Duplikate erkannt und ob sie gemeldet, blockiert oder zugelassen werden.

Welche Angaben sollte ein Validierungsfehler enthalten?

Mindestens eine Referenz auf Upload und Zeile, das betroffene Feld, den Grund und eine mögliche Maßnahme. Begrenzen Sie die im Bericht offengelegten personenbezogenen Daten.

Wie groß darf eine Datei höchstens sein?

Das hängt von den überprüften Funktionen des Systems und der Integration ab. Legen Sie den konkreten Grenzwert fest und teilen Sie ihn mit; hier lässt sich kein allgemeingültiger Wert empfehlen.

Verwendete Quellen

  1. Especificación SMPP v3.4SMPP Developers Forum
  2. Recomendación E.164Unión Internacional de Telecomunicaciones (ITU-T)
  3. Especificaciones 3GPP3GPP
  4. Semántica HTTP (RFC 9110)IETF