Connessione via SMPP e HTTP
Portare una rotta di test in produzione senza compromettere bind, finestre o ricevute: bind, throughput, keep-alive, codifica, callback e gestione degli errori.
Una connessione di messaggistica in produzione è un contratto operativo, non solo un endpoint. L’SMPP aggiunge alla sessione lo stato del bind, una finestra di throughput, il traffico di keep-alive e le ricevute. L’HTTP aggiunge l’autenticazione per singola richiesta e le callback. La guida trasforma entrambi in una sequenza dal test alla produzione.
In questa pagina
Lo stato del bind è la prima cosa da gestire
Un bind è una sessione con una direzione dichiarata. Un transmitter invia, un receiver accetta messaggi in ingresso e ricevute, e un transceiver fa entrambe le cose. Il fornitore rilascia le credenziali per il tipo di bind necessario, e il client deve trattare il bind come uno stato: in apertura, attivo, limitato, in riconnessione o chiuso. Un client che presume che il bind sia sempre attivo perderà messaggi alla prima interruzione.
Tracciare esplicitamente lo stato del bind. Registrare ogni richiesta e risposta di bind, la versione dell’interfaccia, il system ID e il codice di errore. In caso di interruzione, riconnettersi con backoff e non ripetere gli invii in corso finché non si sa se il centro messaggi li ha accettati. Il message ID di submit_sm_resp è l’unico modo affidabile per saperlo.
Il bind e il primo invio
- Applicazione (ESME)
- bind_transceiver Aprire la sessione
- SMSC
- submit_sm_resp Accettato per la consegna
- Ricevuta di consegna
Descrizione testuale
Il client invia una richiesta di bind e riceve una risposta di bind. Invia un messaggio con submit_sm e riceve submit_sm_resp con un message ID. In seguito il centro messaggi invia una PDU deliver_sm con la ricevuta, e il client risponde con deliver_sm_resp. Un unbind chiude la sessione.
Finestra, heartbeat e codifica
La finestra è il numero di richieste in sospeso che il centro messaggi accetta su un bind. Mantenere il numero di richieste in corso al di sotto della finestra e lasciare che la finestra si svuoti prima di un picco. Un invio limitato è un segnale per rallentare; riprovare alla stessa velocità riempie la coda e trasforma un messaggio lento in un arretrato. Dimensionare il numero di bind in base al tasso di picco, non alla media mensile.
Gli scambi di keep-alive segnalano a entrambe le estremità che la sessione è attiva. Inviare enquire_link a intervalli regolari e chiudere una sessione che smette di rispondere. Per la codifica, usare GSM-7 quando il contenuto lo consente e UCS-2 negli altri casi. Un solo carattere al di fuori del set GSM-7 porta l’intero messaggio in UCS-2 e può cambiare il numero di segmenti. Testare il template esatto, compresi i valori delle variabili.
Ricevute di consegna
Una ricevuta arriva in modo asincrono come PDU deliver_sm. Contiene il message ID originale, uno stato come consegnato, scaduto, non consegnato o sconosciuto, e spesso un codice di rete. Abbinarla tramite message ID e memorizzare lo stato con il record del messaggio. Non abbinare in base all’ordine di arrivo e non trattare una ricevuta mancante come un messaggio non riuscito.
I formati delle ricevute variano. I centri messaggi più recenti usano un campo tag-length-value message_state; quelli più vecchi inseriscono testo chiave-valore nel campo short message. Analizzare entrambi i formati. Normalizzare gli stati di cui l’applicazione ha bisogno e conservare il codice originale, in modo che un caso di assistenza possa essere ricondotto a ciò che ha indicato la rete.
Modalità di errore e prima risposta
| Sintomo | Causa probabile | Prima verifica |
|---|---|---|
| Bind rifiutato | Credenziali errate, tipo di bind o versione dell’interfaccia errati | Leggere il codice della risposta di bind e la versione dell’interfaccia |
| Timeout in aumento | Finestra superata o rotta lenta | Controllare il numero di richieste in corso e i codici di risposta prima di riprovare |
| Bind aperto, nessuna risposta | La sessione è inattiva o il client ha interrotto il keep-alive | Inviare enquire_link, quindi riconnettersi con backoff |
| Ricevuta mancante | La ricevuta non ha mai raggiunto il gestore | Controllare il log della sessione e il message ID prima di reinviare |
| Caratteri errati | Contenuto GSM-7 inviato come UCS-2, o viceversa | Controllare il data coding e il numero di segmenti |
| Timeout della callback | L’endpoint è lento o irraggiungibile | Rispondere rapidamente, elaborare in modo asincrono, verificare la firma |
L’ordine delle risposte conta: prima osservare, poi cambiare una sola variabile.
Dalla rotta di test alla produzione
-
Bind sulla rotta di test
Usare le credenziali di test e il tipo di bind che si utilizzerà in produzione. Confermare la risposta di bind e la versione dell’interfaccia.
-
Inviare i template reali
Testare il contenuto che verrà lanciato, inclusi link, variabili e il messaggio più lungo. Registrare la codifica e il numero di segmenti.
-
Leggere le ricevute
Abbinare ogni ricevuta tramite message ID. Confermare gli stati e i codici di errore che l’applicazione riceverà.
-
Testare il percorso di errore
Inviare a un numero non valido, a un terminale con memoria piena e a un servizio bloccato. Confermare gli stati delle ricevute e la gestione da parte dell’applicazione.
-
Dimensionare la finestra
Eseguire un test al tasso di picco e verificare che il numero di richieste in corso resti al di sotto della finestra. In caso contrario, aggiungere un bind.
-
Attivare la supervisione
Impostare avvisi su stato del bind, latenza di invio, latenza delle ricevute e distribuzione degli stati delle ricevute. Indicare la persona che interviene su ciascun avviso.
-
Spostare il traffico di produzione
Spostare prima una piccola quota, confrontare le ricevute con il test, quindi aumentare. Mantenere disponibile la rotta di test come fallback.
Autenticazione HTTP e callback
Un’integrazione HTTP autentica ogni richiesta con la chiave rilasciata all’onboarding. Ruotare la chiave prima della scadenza e mantenere valida la vecchia chiave durante il periodo di sovrapposizione. Un invio restituisce una risposta di accettazione con un message ID; la ricevuta e gli eventuali messaggi in ingresso arrivano al Suo URL di callback.
L’endpoint di callback deve verificare la firma, rispondere rapidamente ed elaborare l’evento dopo la risposta. Un endpoint lento provoca nuovi tentativi, e i nuovi tentativi generano duplicati se il gestore non è idempotente. Mantenere l’endpoint raggiungibile durante i cambi di certificato e di DNS, e impostare un avviso quando aumenta il tasso di errore delle callback. La guida all’SMPP tratta la sessione; il confronto tra i trasporti tratta la scelta.
Domande frequenti
Quale versione di SMPP conviene usare?
Quanti bind servono?
La callback deve rispondere prima dell’elaborazione?
E se una ricevuta non arriva mai?
Come si testa un errore?
Correlati
- Guida globale ai mittenti A2P
Come funzionano i mittenti nei diversi mercati: percorsi alfanumerici, numerici e con codice breve, requisiti di registrazione ed esempi per paese.
- A2P SMS
L’A2P SMS (application-to-person) è il traffico che un’applicazione invia a un telefono, come un codice di verifica o un avviso di transazione, tramite un mittente registrato.
- DLR
Una conferma di consegna riporta lo stato restituito dalla rete mobile per un SMS inviato, come consegnato, scaduto, rifiutato o sconosciuto.
Adiacente alla nostra offerta
Qui spieghiamo questo tema perché influisce su come utilizza il nostro servizio.