A2P-SMS mit unklarem Status: Nachweise abgleichen, ohne vorschnell erneut zu senden

Was bedeutet ein unklarer Nachrichtenstatus?

„Unklar“ kann als interne Kategorie verwendet werden, wenn sich das Ergebnis anhand der für eine Integration festgelegten Kriterien mit den verfügbaren Nachweisen nicht bestimmen lässt. Die hier bereitgestellten Informationen begründen keine universelle technische Definition dieses Status.

Unterscheiden Sie zwischen bekannten Fakten, etwa einem Sendeversuch oder einer Antwort der Schnittstelle, und Schlussfolgerungen, die nicht belegt sind. Gehen Sie weder davon aus, dass eine Annahme eine Zustellung bedeutet, noch dass eine ausbleibende Antwort einen Fehler beweist.

Die Bedeutung jedes Status und die dafür maßgeblichen Nachweise hängen von der Schnittstelle und der geltenden Dokumentation ab. Ohne einschlägige Dokumentation lassen sich keine allgemeinen Regeln für API-Antworten, SMPP-Sitzungen oder Zustellberichte (DLR) festlegen.

• Halten Sie beobachtete Fakten und ihre interne Interpretation getrennt fest.
• Leiten Sie aus einer ausbleibenden Antwort keine Aussage darüber ab, was im entfernten System geschehen ist.
• Definieren Sie operative Kategorien anhand der verfügbaren Dokumentation und der jeweiligen Vereinbarung.

Nachweise zusammentragen und verfügbare Informationen bewahren

Die Prüfung kann damit beginnen, die bereits in der Anwendung, an der Schnittstelle und auf der Messaging-Plattform verfügbaren Protokolle zusammenzutragen. Halten Sie fest, welches System die jeweilige Information liefert und wann sie erfasst wurde. Dies sind Vorschläge zur internen Organisation, keine Beschreibung des Verhaltens einer bestimmten Technologie.

Gehen Sie nicht davon aus, dass Kennungen aus verschiedenen Systemen gleichbedeutend sind oder eine automatische Verknüpfung von Ereignissen ermöglichen. Informationen dazu, wie sie einander zugeordnet werden können, finden Sie in der Dokumentation der jeweiligen Integration.

Wenn Ihr Team interne Kategorien erstellt oder Statuswerte normalisiert, kann es zusätzlich den empfangenen Wert speichern und die angewandte interne Regel dokumentieren. Die bereitgestellten Informationen legen nicht fest, wie Ereignisse zugeordnet oder verarbeitet werden müssen.

• Erfassen Sie als vorgeschlagene interne Kontrolle verfügbare Referenzen, Zeitstempel und Quellsysteme.
• Dokumentieren Sie Einschränkungen bei der Zuordnung, statt einen Nachweis unbegründet einem Sendevorgang zuzuschreiben.
• Bewahren Sie die Unterscheidung zwischen dem empfangenen Wert und der internen Interpretation, sofern der Prozess Ihres Teams dies zulässt.

Schnittstellenabhängige interne Kriterien festlegen

Ein Team kann interne Kriterien festlegen, um Fälle einzuordnen und zu entscheiden, wann sie geprüft werden. Ohne ausreichende technische Dokumentation müssen solche Kriterien als teaminterne Kontrollen dargestellt werden, nicht als universelles Zustandsmodell oder als erwartetes Verhalten aller Anbieter.

Dokumentieren Sie, welche verfügbaren Informationen zu welcher internen Entscheidung führen und wie Fälle mit unvollständigen oder widersprüchlichen Daten geprüft werden. Die bereitgestellten Informationen erlauben keine Festlegung zum Verhalten doppelter oder verspäteter Ereignisse und begründen keine allgemeinen technischen Statusübergänge.

Wenn zwei Einträge unvereinbar erscheinen, halten Sie die Abweichung als solche fest und konsultieren Sie die geltende Dokumentation. Wählen Sie nicht automatisch einen Status, nur weil er neuer oder günstiger erscheint.

• Kennzeichnen Sie Kategorien und Regeln als intern, sofern sie nicht in der Schnittstellendokumentation definiert sind.
• Richten Sie Kriterien an den Informationen aus, die für die jeweilige Integration tatsächlich verfügbar sind.
• Dokumentieren Sie Abweichungen und versuchen Sie nicht, sie durch Annahmen aufzulösen.

Vorsichtige Regeln für den Fallabschluss anwenden

Der Abschluss eines Falls ist eine operative Entscheidung und sollte auf den für die Integration festgelegten Kriterien beruhen. Die verfügbaren Informationen legen weder eine allgemeingültige Frist noch eine universelle Liste abschließender Statuswerte fest.

Anhand dieser Quellen lässt sich nicht direkt bestätigen, was ein DLR mit dem Status „zugestellt“ auf jeder Plattform bedeutet. Stellen Sie ihn daher nicht als universellen Nachweis für den Empfang auf dem Endgerät dar und unterstellen Sie nicht, dass alle Plattformen dieselbe Semantik verwenden.

Trennen Sie beim Abschluss eines Falls den vom System gemeldeten Status von jeder zusätzlichen Schlussfolgerung zum Empfang. Geben Sie den Empfang nur dann als verifiziert an, wenn die Integration geeignete Nachweise liefert und deren Grenzen bekannt sind.

• Legen Sie Abschlusskriterien anhand der geltenden Dokumentation und Vereinbarungen fest.
• Beschreiben Sie einen DLR als gemeldeten Status; verallgemeinern Sie nicht, was er belegt.
• Halten Sie beim Abschluss des Falls verbleibende Unsicherheiten fest.

Entscheiden, ob abgewartet, abgefragt, abgeschlossen oder eskaliert wird

Die geeignete Maßnahme hängt von den für die Integration dokumentierten Funktionen und den vereinbarten Kriterien des Teams ab. Die bereitgestellten Informationen bestätigen nicht, dass für alle Anbieter oder Schnittstellen eine Abfragefunktion verfügbar ist.

Als vorgeschlagene interne Kontrolle kann das Team festlegen, wann ein Fall offen bleibt, wann eine dokumentierte Funktion abgefragt wird und wann eine Abweichung eskaliert werden soll. Lässt sich das Ergebnis nicht bestimmen, kann der Fall nach dem eigenen Verfahren als unbestimmt gekennzeichnet werden.

Wenn Sie einen Fall mit einem Anbieter besprechen, verwenden Sie die Informationen, die zur Beschreibung der Abweichung erforderlich sind, und beachten Sie die geltenden Datenschutzregeln. Diese Empfehlungen sind organisatorische Leitlinien, keine bestätigten technischen Funktionen.

• Abwarten: interne Prozessoption, wenn der Fall noch innerhalb des vereinbarten Kriteriums liegt.
• Abfragen: nur, wenn die Schnittstellendokumentation eine passende Abfrage beschreibt.
• Eskalieren: interne Option bei einer Abweichung oder unzureichenden Informationen, die eine Prüfung erfordert.
• Als unbestimmt abschließen: interne Entscheidung, wenn sich nach dem vereinbarten Verfahren kein anderes Ergebnis feststellen lässt.

Automatische erneute Sendungen vermeiden – insbesondere bei OTP-Prozessen

Die verfügbaren Informationen lassen nicht erkennen, welche Deduplizierungs-, Abfrage- oder Wiederholungsmechanismen die einzelnen Plattformen anbieten. Ein Timeout, ein fehlender DLR oder ein ausstehender Status sollte daher hier weder als ausreichender Beleg für einen Fehler noch als universelles technisches Signal für eine erneute Sendung behandelt werden.

Als vorgeschlagene interne Kontrolle sollten Sie die Untersuchung des ursprünglichen Sendevorgangs von der Entscheidung trennen, einen weiteren Versand zu starten. Wenden Sie vor einem neuen Versuch die für Anwendung und Integration dokumentierte Wiederholungsrichtlinie an. Gehen Sie nicht davon aus, dass das System eine wiederholte Anfrage als denselben Vorgang erkennt.

Befolgen Sie bei OTP-Prozessen die geltenden Geschäfts-, Sicherheits-, Datenschutz- und Einwilligungsregeln. Informieren Sie klar über den bekannten Status, ohne einen erneuten Versuch als Zustellgarantie darzustellen.

• Schreiben Sie einer Schnittstelle keine Deduplizierung oder Idempotenz zu, solange dies nicht durch Dokumentation bestätigt ist.
• Wenden Sie die für Anwendung und Integration festgelegten Kontrollen für erneute Versuche an.
• Stellen Sie bei OTP-Kommunikation einen weiteren Versuch nicht als Garantie für ein bestimmtes Ergebnis dar.

Praktischer Entscheidungsrahmen

Dieser Rahmen ist eine interne Arbeitshilfe, keine API-Spezifikation und keine universelle Beschreibung der von Anbietern verwendeten Statuswerte. Passen Sie ihn an die geltende Dokumentation und die jeweiligen Vereinbarungen an.

Prüfen Sie vor der Anwendung, welche Informationen die Schnittstelle liefert und welche Schlussfolgerungen sich daraus ziehen lassen. Wenn sich die Quelle oder die Beziehung zwischen den Einträgen nicht feststellen lässt, halten Sie diese Einschränkung fest.

• Annahmebestätigung ohne nachfolgende Informationen: Interpretieren Sie die Antwort nur gemäß der geltenden Dokumentation. Abwarten oder Abfragen ist eine interne Prozessentscheidung.
• Keine Antwort auf die Anfrage: Halten Sie die beobachtete Tatsache fest. Leiten Sie nicht automatisch ab, ob die Anfrage angenommen wurde oder was danach geschah.
• DLR empfangen: Bewahren Sie den gemeldeten Status und prüfen Sie dessen Definition. Machen Sie daraus keine universelle Aussage über den Empfang auf dem Endgerät.
• DLR ohne verlässliche Zuordnung: Ordnen Sie ihn keinem Sendevorgang zu, wenn dafür keine dokumentierte Grundlage besteht.
• Unvereinbare Informationen: Bewahren Sie die verfügbaren Daten auf und befolgen Sie das interne Prüf- oder Eskalationsverfahren.
• Keine ausreichenden Nachweise: Ordnen Sie den Fall gemäß dem internen Verfahren ein, ohne ein unbelegtes Ergebnis zu behaupten.

Unsicherheiten und Entscheidungen überprüfen

Eine Kennzahl für Fälle mit unklarem Status lässt sich nur dann interpretieren, wenn das Team festlegt, welche Fälle sie umfasst, welcher Zeitraum betrachtet wird und wie spätere Änderungen erfasst werden. Die verfügbaren Informationen enthalten weder Leistungsreferenzwerte noch Zahlen, die verwendet werden sollten.

Ein internes Verfahren kann offene Fälle, Abweichungen, Einschränkungen bei der Zuordnung und Entscheidungen über erneute Sendungen prüfen. Halten Sie Kategorien, die auf gemeldeten Statuswerten beruhen, getrennt von Aussagen über verifizierten Empfang.

Eine solche Prüfung kann helfen, Lücken in der Dokumentation oder im Prozess zu erkennen. Leiten Sie aus einer Kennzahl keine Schlussfolgerungen ab, die von den Daten nicht getragen werden.

• Legen Sie den Zeitraum und die Kriterien fest, anhand derer Fälle mit unklarem Status ermittelt werden.
• Erfassen Sie Abweichungen und Einschränkungen der verfügbaren Informationen.
• Überprüfen Sie Entscheidungen über erneute Sendungen anhand der geltenden internen Richtlinie.
• Unterscheiden Sie gemeldete Statuswerte von einem verifizierten Empfang.