Checklist di messa in produzione per connessioni SMS A2P HTTP e SMPP

Che cosa significa essere pronti per la produzione

Una connessione HTTP o SMPP operativa conferma soltanto che esiste un qualche livello di comunicazione con il sistema remoto. Non dimostra che il provider abbia accettato ogni messaggio, che sia stato ricevuto un rapporto di consegna o che l’SMS sia arrivato sul dispositivo.

È opportuno distinguere l’accettazione della connessione, l’accettazione di ogni invio e le prove di consegna. Definite quale risultato vi aspettate di osservare in ogni fase e quale fonte lo fornisce. Un DLR è un rapporto ricevuto; da solo non equivale a una verifica indipendente sul telefono.

Prima di abilitare il traffico, concordate l’ambito: destinazioni, mittenti, tipi di messaggio, volumi previsti, orari, responsabili e condizioni di autorizzazione e conformità applicabili. L’accettazione tecnica non sostituisce la verifica di permessi, consenso o norme locali.

• Documentate che cosa considerate un test di connettività riuscito e che cosa costituisce un test di consegna.
• Concordate con la controparte i parametri d’integrazione e i risultati attesi; non date per scontati valori non documentati.
• Escludete dai criteri di accettazione qualsiasi garanzia di consegna che non sia supportata da prove e condizioni concordate.

Preparare l’ambiente e separare i test dal traffico reale

Mantenete distinti gli ambienti, le credenziali, le destinazioni e i mittenti di test e di produzione, nella misura consentita dall’architettura e dal provider. Se non è possibile ottenere una separazione tecnica completa, documentate le misure di sicurezza per evitare che un test raggiunga destinatari reali.

Conservate le credenziali con meccanismi di accesso limitato ed evitate di includerle nei log, nei ticket o negli esempi condivisi. Assegnate le autorizzazioni solo a chi ne ha bisogno e definite come intervenire se una credenziale viene esposta.

Usate per i test esclusivamente destinazioni e contenuti autorizzati. Prima dell’invio, verificate l’ambito e l’approvazione del traffico, soprattutto per messaggi di marketing, OTP o comunicazioni transazionali.

• Inventariate credenziali, host, porte, mittenti, destinazioni e responsabili di ogni ambiente.
• Verificate che i messaggi di test siano identificabili e non si mescolino ai rapporti sul traffico di produzione.
• Stabilite chi può abilitare il traffico e chi può interromperlo.

Convalidare l’integrazione HTTP

Verificate l’autenticazione e il trasporto secondo la documentazione concordata con il provider. Assicuratevi che l’applicazione distingua una risposta HTTP dall’esito operativo del messaggio: ricevere una risposta non basta per concludere che il messaggio sia stato consegnato.

Definite i timeout di connessione e risposta in base all’implementazione e al contratto tecnico. Se scade un timeout, l’esito può essere incerto: il sistema remoto potrebbe aver elaborato la richiesta anche se l’applicazione non ha ricevuto la risposta. Non effettuate reinvii automatici senza una policy che tenga conto dei duplicati e dell’idempotenza.

Classificate gli errori in base alle risposte documentate dalla controparte. Distinguete i problemi risolvibili correggendo la richiesta o la configurazione da quelli che potrebbero essere temporanei. Le informazioni disponibili non definiscono codici, tentativi di nuovo invio o una semantica universale per le API SMS: concordate questi comportamenti prima di inviare traffico di produzione.

Se sono previsti tentativi di nuovo invio, definite limiti, intervalli e condizioni di arresto. Assicuratevi che un nuovo tentativo non moltiplichi gli invii in caso di risposta ambigua e che il meccanismo di deduplicazione, se presente, sia descritto e testato.

• Testate credenziali valide e non valide senza esporre segreti nei log.
• Verificate le risposte di successo e di errore usando esempi documentati dal provider.
• Simulate i timeout e confermate come identificare una richiesta con esito incerto.
• Testate la policy dei nuovi tentativi e la gestione dei duplicati prima di abilitare i reinvii automatici.

Convalidare la sessione SMPP

SMPP v3.4 è una specifica pertinente per questo tipo di connessione, ma i valori operativi concreti devono essere concordati con la controparte. Prima di abilitare il traffico, confermate i parametri di connessione e la configurazione della sessione effettivamente applicabili al vostro collegamento.

Verificate che il tipo di bind e i parametri della sessione corrispondano all’uso concordato. Definite come rilevare le sessioni inattive, come monitorarne lo stato e come gestire una disconnessione o una chiusura controllata. Non date per scontati intervalli, valori della finestra o risposte: devono derivare dalla specifica applicabile e dall’accordo tecnico.

Assicuratevi che l’applicazione sappia distinguere una sessione connessa da una sessione in grado di trasmettere entro i limiti concordati. Testate il ripristino dopo una perdita di connessione senza presumere che i messaggi in sospeso siano stati elaborati o scartati.

• Convalidate i parametri di connessione e le credenziali con la controparte.
• Concordate il comportamento del bind, i controlli di attività e la chiusura della sessione.
• Confermate come riconciliare gli invii in sospeso dopo una disconnessione.
• Registrate gli errori di protocollo e la loro correlazione con la sessione interessata.

Concordare limiti, code e controllo della pressione

Non deducete la capacità di una connessione dal fatto che accetti messaggi di test. Prima di attivare il traffico, ottenete dalla controparte e dalla configurazione contrattuale i limiti applicabili, per esempio la velocità di invio o la concorrenza consentita. Senza questi dati non è possibile consigliare un TPS universale.

Definite come si comportano le code quando l’applicazione genera messaggi più velocemente di quanto l’integrazione riesca a elaborarli. Stabilite quando rallentare il mittente, quando smettere di accettare nuove attività e come evitare che un picco trasformi un problema temporaneo in un arretrato difficile da recuperare.

Procedete per gradi e rispettate i limiti concordati. Se non avete l’autorizzazione a eseguire un test di carico, non fatelo: chiedete prima un piano e condizioni esplicite.

• Registrate i limiti concordati e indicate dove si applicano: nell’applicazione, nella connessione o presso il provider.
• Definite le soglie per rallentare o fermare la produzione di messaggi.
• Verificate il comportamento della coda e il ripristino dopo un’interruzione.
• Evitate test di carico non autorizzati o basati su limiti presunti.

Tracciabilità, stati e DLR

Ogni messaggio dovrebbe poter essere seguito dalla richiesta originale fino alle risposte e agli aggiornamenti ricevuti. Definite quale identificativo conserva ciascun sistema e come collegare l’identificativo interno, il riferimento restituito dalla piattaforma e gli eventi successivi.

Registrate timestamp e stati con un contesto sufficiente per indagare sui problemi. Limitate i dati personali e i contenuti archiviati a quanto necessario, proteggete i log e stabilite chi può consultarli e per quanto tempo, in conformità agli obblighi applicabili.

Se ricevete callback o DLR, testate come vengono autenticati, correlati ed elaborati, compresi gli eventuali eventi ripetuti o tardivi previsti dall’interfaccia. Un DLR ricevuto va presentato come lo stato comunicato dalla relativa fonte, non come prova indipendente che una persona abbia visto il messaggio o che questo sia arrivato a un dispositivo specifico.

• Correlate la richiesta, la risposta iniziale e gli eventi successivi usando identificativi documentati.
• Registrate ora, stato, destinazione e contesto tecnico necessario alla diagnosi.
• Testate callback e DLR secondo il comportamento documentato, senza attribuire loro un grado di certezza superiore a quello che offrono.
• Definite i controlli di accesso e i tempi di conservazione dei log.

Eseguire test controllati e valutare le prove

Eseguite innanzitutto test di trasporto e configurazione con casi approvati. In seguito, se disponete dell’autorizzazione e di una destinazione di test adeguata, valutate il ciclo di invio e i rapporti disponibili. Tenete distinti i risultati di connettività da quelli di consegna.

Classificate ogni osservazione: richiesta inviata, accettazione comunicata dall’interfaccia, DLR ricevuto e, quando possibile, ricezione verificata in modo indipendente su una destinazione controllata. Queste categorie non sono intercambiabili. Un test con pochi messaggi, da solo, non consente di dedurre il comportamento per tutte le destinazioni o tutti i volumi.

Documentate i risultati, l’ora, l’ambiente, i parametri utilizzati e i limiti. Se manca una risposta o gli stati non concordano, considerate il caso non conclusivo finché non è stato indagato.

• Approvate in anticipo destinazioni, mittenti e contenuti di test.
• Verificate prima la connettività e poi il flusso degli stati del messaggio.
• Conservate prove sufficienti per riprodurre la diagnosi, senza archiviare segreti.
• Non trasformate un campione limitato in una garanzia generale di consegna.

Avvisi, responsabili e ripristino

Prima del lancio, assegnate i responsabili dell’integrazione, delle operazioni e dei contatti con la controparte. Definite come rilevare la perdita di connettività, l’aumento degli errori, l’accumulo delle code e le discrepanze di stato, usando i segnali disponibili nel vostro sistema.

Concordate criteri espliciti di arresto, per esempio problemi che impediscano di determinare l’esito degli invii, credenziali esposte o uno scostamento dai limiti stabiliti. Le soglie concrete devono basarsi sui dati e sugli accordi del servizio, non su valori inventati.

Preparate una procedura di ripristino prima di abilitare il traffico: definite chi può fermare i nuovi invii, come gestire la coda in sospeso, come informare i team interessati e quali condizioni devono essere soddisfatte per riprendere. Interrompere la produzione di nuovi messaggi non risolve automaticamente lo stato di quelli già inviati: questi casi devono essere riconciliati.

• Assegnate un responsabile reperibile e un canale di escalation.
• Definite segnali osservabili e soglie concordate per l’invio di avvisi e l’arresto.
• Testate la procedura per fermare i nuovi invii e gestire il lavoro in sospeso.
• Documentate le condizioni per riprendere e la revisione successiva all’incidente.