Anbindung über SMPP und HTTP
Bringen Sie eine Testroute in die Produktion, ohne Binds, Fenster oder Zustellberichte zu stören: Bind, Durchsatz, Keep-Alive, Kodierung, Callbacks und Fehlerbehandlung.
Eine produktive Messaging-Anbindung ist ein Betriebsvertrag, nicht nur ein Endpunkt. SMPP bringt Bind-Status, ein Durchsatzfenster, Keep-Alive-Verkehr und Zustellberichte über die Sitzung mit. HTTP bringt Authentifizierung pro Anfrage und Callbacks mit. Der Leitfaden macht aus beidem eine Abfolge vom Test bis zur Produktion.
Auf dieser Seite
Den Bind-Status zuerst in den Griff bekommen
Ein Bind ist eine Sitzung mit einer festgelegten Richtung. Ein Transmitter sendet, ein Receiver nimmt eingehende Nachrichten und Zustellberichte an, und ein Transceiver tut beides. Der Anbieter stellt Zugangsdaten für den benötigten Bind-Typ aus, und der Client muss den Bind als Zustand behandeln: im Aufbau, gebunden, gedrosselt, im Wiederaufbau oder geschlossen. Ein Client, der annimmt, dass der Bind immer steht, verliert beim ersten Abbruch Nachrichten.
Verfolgen Sie den Bind-Status explizit. Protokollieren Sie jede Bind-Anfrage und -Antwort, die Interface-Version, die System-ID und den Fehlercode. Verbinden Sie nach einem Abbruch mit Backoff neu und wiederholen Sie laufende Übermittlungen erst, wenn Sie wissen, ob das Message Center sie angenommen hat. Die Nachrichten-ID aus submit_sm_resp ist der einzige verlässliche Weg, das festzustellen.
Der Bind und die erste Übermittlung
- Anwendung (ESME)
- bind_transceiver Sitzung öffnen
- SMSC
- submit_sm_resp Zur Zustellung angenommen
- Zustellbestätigung
Textbeschreibung
Der Client sendet eine Bind-Anfrage und erhält eine Bind-Antwort. Er übermittelt eine Nachricht mit submit_sm und erhält submit_sm_resp mit einer Nachrichten-ID. Später sendet das Message Center eine deliver_sm-PDU mit dem Zustellbericht, und der Client antwortet mit deliver_sm_resp. Ein unbind schließt die Sitzung.
Fenster, Heartbeat und Kodierung
Das Fenster ist die Anzahl ausstehender Anfragen, die das Message Center auf einem Bind annimmt. Halten Sie die Zahl laufender Anfragen darunter und lassen Sie das Fenster vor einer Lastspitze leerlaufen. Eine gedrosselte Übermittlung ist ein Signal zum Verlangsamen; Wiederholungen mit gleicher Rate füllen die Warteschlange und machen aus einer langsamen Nachricht einen Rückstau. Bemessen Sie die Zahl der Binds nach der Spitzenrate, nicht nach dem Monatsdurchschnitt.
Keep-Alive-Nachrichten zeigen beiden Seiten, dass die Sitzung aktiv ist. Senden Sie enquire_link nach Zeitplan und schließen Sie eine Sitzung, die nicht mehr antwortet. Für die Kodierung senden Sie GSM-7, wo der Inhalt es erlaubt, und sonst UCS-2. Ein einziges Zeichen außerhalb des GSM-7-Zeichensatzes stellt die ganze Nachricht auf UCS-2 um und kann die Zahl der Segmente ändern. Testen Sie genau die Vorlage, einschließlich der Variablenwerte.
Zustellberichte
Ein Zustellbericht trifft asynchron als deliver_sm-PDU ein. Er enthält die ursprüngliche Nachrichten-ID, einen Status wie zugestellt, abgelaufen, nicht zustellbar oder unbekannt und oft einen Netzcode. Ordnen Sie ihn über die Nachrichten-ID zu und speichern Sie den Status mit dem Nachrichtendatensatz. Ordnen Sie nicht nach Eingangsreihenfolge zu, und werten Sie einen fehlenden Zustellbericht nicht als fehlgeschlagene Nachricht.
Die Formate der Zustellberichte unterscheiden sich. Neuere Message Center nutzen ein message_state-Feld im Tag-Length-Value-Format; ältere schreiben Schlüssel-Wert-Text in das Feld short_message. Parsen Sie beides. Normalisieren Sie die Status, die Ihre Anwendung braucht, und behalten Sie den Rohcode, damit sich ein Supportfall auf die Angabe des Netzes zurückführen lässt.
Fehlerbilder und die erste Reaktion
| Symptom | Wahrscheinliche Ursache | Erste Prüfung |
|---|---|---|
| Bind abgelehnt | Falsche Zugangsdaten, falscher Bind-Typ oder falsche Interface-Version | Den Antwortcode des Binds und die Interface-Version lesen |
| Zunehmende Zeitüberschreitungen | Fenster überschritten oder eine langsame Route | Vor einer Wiederholung die Zahl laufender Anfragen und die Antwortcodes prüfen |
| Bind offen, keine Antworten | Die Sitzung ist tot, oder der Client hat das Keep-Alive eingestellt | enquire_link senden, dann mit Backoff neu verbinden |
| Zustellbericht fehlt | Der Zustellbericht hat den Handler nie erreicht | Vor einem erneuten Senden das Sitzungsprotokoll und die Nachrichten-ID prüfen |
| Falsche Zeichen | GSM-7-Inhalt als UCS-2 gesendet oder umgekehrt | Die Datenkodierung und die Zahl der Segmente prüfen |
| Callback-Zeitüberschreitung | Der Endpunkt ist langsam oder nicht erreichbar | Schnell antworten, asynchron verarbeiten, die Signatur prüfen |
Die Reihenfolge der Reaktion zählt: zuerst beobachten, dann eine einzige Variable ändern.
Von der Testroute in die Produktion
-
An die Testroute binden
Verwenden Sie die Test-Zugangsdaten und den Bind-Typ, den Sie in der Produktion betreiben werden. Prüfen Sie die Bind-Antwort und die Interface-Version.
-
Die echten Vorlagen senden
Testen Sie den Inhalt, mit dem Sie starten, einschließlich Links, Variablen und der längsten Nachricht. Halten Sie die Kodierung und die Zahl der Segmente fest.
-
Die Zustellberichte lesen
Ordnen Sie jeden Zustellbericht über die Nachrichten-ID zu. Prüfen Sie die Status und Fehlercodes, die Ihre Anwendung erhalten wird.
-
Den Fehlerpfad testen
Senden Sie an eine ungültige Nummer, ein Endgerät mit vollem Speicher und einen gesperrten Dienst. Prüfen Sie die Status der Zustellberichte und die Behandlung durch die Anwendung.
-
Das Fenster bemessen
Führen Sie einen Test mit Spitzenrate durch und prüfen Sie, dass die Zahl laufender Anfragen unter dem Fenster bleibt. Fügen Sie einen Bind hinzu, wenn nicht.
-
Monitoring einschalten
Alarmieren Sie bei Bind-Status, Übermittlungslatenz, Latenz der Zustellberichte und der Verteilung der Berichtsstatus. Benennen Sie die Person, die auf jeden Alarm reagiert.
-
Den Produktionsverkehr umstellen
Verlagern Sie zuerst einen kleinen Anteil, vergleichen Sie die Zustellberichte mit dem Test und erhöhen Sie dann. Halten Sie die Testroute als Ausweichweg verfügbar.
HTTP-Authentifizierung und Callbacks
Eine HTTP-Integration authentifiziert jede Anfrage mit dem beim Onboarding ausgegebenen Schlüssel. Rotieren Sie den Schlüssel, bevor er abläuft, und lassen Sie den alten Schlüssel während der Überlappung gültig. Ein Sendeaufruf liefert eine Annahmeantwort mit einer Nachrichten-ID; der Zustellbericht und jede eingehende Nachricht treffen an Ihrer Callback-URL ein.
Der Callback-Endpunkt muss die Signatur prüfen, schnell antworten und das Ereignis nach der Antwort verarbeiten. Ein langsamer Endpunkt löst Wiederholungen aus, und Wiederholungen erzeugen Duplikate, sofern der Handler nicht idempotent ist. Halten Sie den Endpunkt auch bei Zertifikats- und DNS-Änderungen erreichbar und alarmieren Sie, wenn die Fehlerrate der Callbacks steigt. Die Erklärung zu SMPP behandelt die Sitzung; der Vergleich der Transportwege behandelt die Wahl.
FAQ
Welche SMPP-Version sollten wir verwenden?
Wie viele Binds brauchen wir?
Sollte der Callback vor der Verarbeitung antworten?
Was, wenn ein Zustellbericht nie eintrifft?
Wie testen wir einen Fehlerfall?
Verwandte Inhalte
- Globales A2P-Playbook für Absender-IDs
Wie Absender-IDs in verschiedenen Märkten funktionieren: alphanumerische Absender, numerische Absender und Kurzwahlnummern, Erwartungen an die Registrierung und Länderbeispiele.
- A2P SMS
Application-to-Person-SMS ist Verkehr, den eine Anwendung über einen registrierten Absender an ein Mobiltelefon sendet, etwa einen Bestätigungscode oder eine Transaktionsmeldung.
- DLR
Ein Zustellbericht meldet den Status des Mobilfunknetzes für eine gesendete SMS, etwa zugestellt, abgelaufen, abgelehnt oder unbekannt.
Angrenzend an unser Angebot
Wir erklären dies hier, weil es beeinflusst, wie Sie unsere Leistung nutzen.