DLR tardivi negli SMS A2P: come definire una finestra di osservazione e chiudere i messaggi senza perdere tracciabilità

Che cos'è un DLR tardivo in una catena SMS A2P

Un delivery receipt, o DLR, è un evento di stato relativo a un SMS precedentemente inviato. In SMPP, quando è stato richiesto tramite registered_delivery, l'SMSC può inviare tale ricevuta all'ESME attraverso deliver_sm. Non è la risposta sincrona a submit_sm e non deve essere trattato come tale.

Un DLR tardivo è una ricevuta che arriva dopo il momento entro cui un'applicazione, un'operazione o un team di assistenza si aspettava di prendere una decisione. Può verificarsi perché il ciclo del messaggio attraversa diversi sistemi e perché possono esistere tentativi di consegna intermedi. SMPP contempla, ad esempio, il caso in cui un tentativo fallisca mentre l'SMS resta trattenuto per ulteriori tentativi; il supporto concreto di tali notifiche dipende dall'implementazione dell'SMSC e dal fornitore.

Il ritardo dell'evento non invalida di per sé l'evento. Indica che la decisione operativa dell'azienda e il ciclo di notifica della catena di consegna non erano necessariamente sincronizzati. Per questo è opportuno progettare una chiusura operativa reversibile sul piano dell'interpretazione, ma non distruttiva sul piano dei dati.

• Non equiparare la risposta di accettazione dell'invio a un DLR.
• Non trattare l'assenza di callback come prova automatica di un errore finale.
• Conservare l'evento grezzo anche se arriva dopo la chiusura operativa.
• Mantenere separate la semantica ricevuta dal fornitore e la classificazione interna.

Tre orologi da non confondere

La gestione dei DLR tardivi inizia separando tre controlli che rispondono a domande diverse. Se vengono usati come se fossero lo stesso elemento, si verificano chiusure premature, scadenze interpretate male e diagnosi poco affidabili.

Il timeout API stabilisce quanto tempo l'applicazione attende una risposta tecnica alla propria richiesta. Se scade, l'applicazione deve risolvere l'incertezza relativa a quella richiesta con un identificatore di correlazione, una consultazione dello stato o una strategia di nuovo tentativo sicura. Non determina per quanto tempo l'SMS può essere consegnato né per quanto tempo può arrivare un DLR.

Il periodo di validità stabilisce fino a quando un centro di servizio può conservare un messaggio per tentare di consegnarlo. In SMPP, validity_period rappresenta l'ora di scadenza dopo la quale l'SMSC deve scartare il messaggio se non è stato consegnato. In 3GPP, la validità può essere espressa in formato relativo, assoluto o avanzato. La scadenza della validità è un esito di rete; non deve essere dedotta semplicemente perché non è arrivato un callback.

La finestra di osservazione del DLR è una politica operativa interna. Definisce per quanto tempo si attende un esito per alimentare flussi aziendali, avvisi, assistenza o report operativi. Non è stabilita dal protocollo e non deve essere resa equivalente al timeout né copiata meccanicamente dal periodo di validità.

• Timeout API: limite di attesa per una risposta tecnica.
• Validità del messaggio: limite di conservazione e tentativi di consegna nella catena applicabile.
• Finestra di osservazione: limite interno per decidere uno stato operativo, non per eliminare evidenze.
• Periodo di riconciliazione: intervallo successivo per recuperare o confrontare eventi mancanti e modifiche tardive.

Perché «accettato» o «inviato» non conferma la consegna

Uno stato di accettazione o invio deve essere descritto con precisione. In una semantica del fornitore documentata, sent significa che l'operatore a monte più vicino ha accettato il messaggio. Ciò non equivale a confermare la consegna alla destinazione.

Anche quando un DLR indica consegnato, la comunicazione deve mantenere l'effettiva portata dell'evidenza. La specifica 3GPP distingue tra un messaggio ricevuto dallo SME e un messaggio inoltrato dal centro di servizio senza che quest'ultimo possa confermarne la consegna. Inoltre, l'evidenza che un fornitore può esporre dipende dalla conferma disponibile dall'operatore e, quando presente, dal terminale.

Di conseguenza, uno stato delivered deve essere registrato come conferma di consegna riportata dalla catena disponibile, non come prova universale, indipendente o equivalente alla lettura da parte della persona destinataria. La lettura, la comprensione e l'esecuzione di un'azione in un flusso aziendale sono fatti distinti dal DLR.

• Accettato: la richiesta o il messaggio è stato ammesso in un punto della catena.
• Inviato: può riflettere un trasferimento o un'accettazione a monte, secondo la semantica documentata.
• Consegnato: riflette una conferma riportata, la cui portata dipende dall'evidenza disponibile.
• Letto, utilizzato o convertito: richiedono segnali indipendenti dall'applicazione o dall'utente.

Come modellare gli stati interni senza sovrascrivere l'evidenza

I callback sono asincroni e lo stato di un messaggio può cambiare durante il suo ciclo di vita. Per questo, lo stato grezzo di un fornitore non dovrebbe essere l'unico campo a governare l'operatività. È opportuno mantenere una cronologia immutabile degli eventi e una vista interna calcolata per ogni messaggio.

Un modello pratico può usare in attesa, provvisorio, finale e aggiornato tardivamente. Questi nomi descrivono la posizione operativa dell'azienda, senza sostituire la semantica originale del DLR. Il registro deve conservare sia l'evento ricevuto sia la regola con cui è stato interpretato.

In attesa può indicare che esiste un'accettazione tecnica o che non è ancora stato ricevuto un esito sufficiente. Provvisorio indica che è stata adottata un'azione aziendale o di assistenza in presenza di un'incertezza esplicita. Finale identifica un esito ricevuto e classificato secondo le regole vigenti. Aggiornato tardivamente indica che un evento successivo ha modificato la vista calcolata o ha apportato informazioni rilevanti dopo la chiusura operativa.

Non è opportuno sostituire uno stato precedente né eliminare eventi perché sembrano ridondanti. Conservare la sequenza e calcolare la vista corrente con regole versionate. In questo modo sarà possibile spiegare perché un messaggio è stato chiuso in un determinato momento e perché la sua interpretazione è stata aggiornata successivamente.

• Evento grezzo: contenuto ricevuto, identificatore, fonte e ora di ricezione.
• Stato normalizzato: traduzione controllata della semantica esterna.
• Stato operativo: in attesa, provvisorio, finale o aggiornato tardivamente.
• Motivo della transizione: regola applicata, versione della regola e attore in caso di intervento manuale.
• Stato di riconciliazione: confermato da eventi ricevuti, consultato, in attesa di revisione o con discrepanza.

Definire le finestre in base al caso d'uso

Non esiste una durata universale per una finestra di osservazione. Deve derivare dalla finalità del messaggio, dall'impatto dell'attesa, dalla validità configurata, dai segnali storici disponibili e dalla reale capacità di riconciliare e gestire le eccezioni.

Per gli OTP, la validità funzionale del codice deve essere determinata dalla logica di autenticazione. Il DLR fornisce osservabilità e supporto diagnostico, ma non deve bloccare la scadenza del codice né il flusso di autenticazione. Definire la finestra per rilevare anomalie, guidare tentativi sicuri o informare l'assistenza, senza trasformarla nella fonte di verità sulla validità della credenziale.

Nelle notifiche transazionali, la finestra può essere allineata al momento in cui il destinatario deve agire e agli obblighi interni di assistenza. Se alla chiusura non esiste un esito, lo stato deve comunicare l'incertezza e attivare il processo previsto, senza presumere né consegna né errore definitivo.

Nella messaggistica non urgente, una finestra più ampia può essere ragionevole se l'obiettivo tollera una consegna differita. Tuttavia, la finestra deve restare indipendente dalla conservazione nelle reti successive: una piattaforma può applicare la propria validità mentre il messaggio vi rimane e, una volta trasferito all'operatore, quest'ultimo può continuare a metterlo in coda più a lungo.

• OTP: separare sempre la scadenza del codice, la validità dell'SMS e il monitoraggio del DLR.
• Transazionale: definire azioni di assistenza o canali alternativi quando l'incertezza persiste.
• Non urgente: tollerare un'osservazione più estesa solo se il caso d'uso e la politica lo giustificano.
• Tutti i casi: mantenere la riconciliazione successiva alla chiusura operativa.

Criteri per scegliere una finestra di osservazione

La decisione deve essere documentata e rivedibile. Evitare di fissare un unico valore senza osservare il comportamento degli eventi sulle proprie destinazioni, operatori, rotte, tipi di mittente e contenuti legittimi. I dati storici aiutano a orientare una politica, ma non trasformano un andamento passato in una garanzia futura.

Analizzare la distribuzione del tempo tra l'accettazione iniziale, gli stati intermedi e gli esiti ricevuti. Segmentare l'analisi in base ad attributi operativi consentiti e necessari per il servizio, senza usare la segmentazione per nascondere problemi o inviare traffico non conforme.

La finestra deve essere coerente con il requisito di servizio. Se un'operazione deve decidere prima che possa normalmente esistere un'evidenza sufficiente, occorre progettare un flusso che ammetta l'incertezza: ad esempio, mostrare uno stato in attesa, applicare una verifica aggiuntiva o utilizzare un canale alternativo conforme alla politica applicabile.

Anche la capacità di assistenza conta. Una finestra breve può ridurre la coda visibile, ma aumenta il rischio di classificare troppo presto. Una finestra ampia riduce alcune chiusure premature, ma può ritardare gli avvisi e aumentare i messaggi in monitoraggio. La politica deve dichiarare questo compromesso.

• Comportamento storico dei DLR per destinazione, operatore, rotta e tipo di traffico.
• Criticità e tempistica reale del caso d'uso.
• Periodo di validità configurato e semantica documentata di ciascuna connessione.
• Tassi di eventi tardivi, duplicati, mancanti o fuori ordine.
• Capacità di consultazione, riconciliazione, gestione degli incidenti e comunicazione con il cliente.
• Requisiti contrattuali, normativi e di conservazione dei registri applicabili.

Progettare una politica di chiusura e conservazione dei dati

Una politica di chiusura definisce cosa accade quando termina la finestra di osservazione senza un esito conclusivo, quali eventi possono modificare successivamente la vista e chi può approvare le eccezioni. La chiusura deve essere una decisione operativa verificabile, non l'eliminazione del messaggio dal sistema.

Stabilire una tassonomia chiara per i casi senza esito. Per esempio, «chiuso provvisoriamente senza DLR finale ricevuto» comunica più di «non riuscito» quando non è stato riportato alcun errore finale. Riservare gli stati definitivi alle evidenze che supportano realmente tale classificazione.

La politica deve indicare chi possiede le regole: operazioni, prodotto, ingegneria, delivery o un comitato congiunto, secondo il modello organizzativo. Deve inoltre definire un processo di modifica: motivazione, valutazione dell'impatto, versione, data di efficacia, approvazione e piano di ripristino.

Documentare le eccezioni prevedibili, quali incidenti di connettività del callback, modifiche dell'integrazione, discrepanze identificate nella riconciliazione o rotte con semantiche differenti. Un'eccezione non deve modificare retroattivamente la cronologia grezza; deve cambiare in modo tracciabile l'interpretazione o il trattamento operativo.

• Identificatore interno univoco del messaggio.
• Identificatore restituito dal fornitore o dalla connessione, quando disponibile.
• Identificatori di account, servizio o rotta disponibili e pertinenti.
• Origine, destinazione e attributi necessari per la correlazione, protetti secondo la politica sui dati applicabile.
• Stato iniziale, eventi successivi, payload grezzo conservato in modo sicuro e stato normalizzato.
• Ora della richiesta, dell'accettazione, della ricezione del callback e, quando disponibile, ora di completamento indicata dal DLR.
• Regola, versione e motivo di ogni transizione interna.
• Risultato delle consultazioni di riconciliazione e riferimento dell'incidente, se presente.

DLR duplicati, fuori ordine o contraddittori

La ricezione di più eventi per lo stesso messaggio non deve obbligare a sceglierne uno e scartare gli altri. La deduplicazione per evitare azioni ripetute è utile; eliminare duplicati apparenti rimuove evidenze che possono essere necessarie per la diagnosi.

Usare una chiave di idempotenza basata sugli identificatori disponibili e su un'impronta dell'evento. Se si ricevono due eventi equivalenti, è possibile contrassegnarli come ripetuti nella vista operativa, ma occorre conservare entrambi o mantenere un riferimento verificabile all'evento originale secondo la politica di conservazione. L'idempotenza deve essere applicata in particolare alle azioni collaterali, come notifiche, fatturazione interna o apertura di ticket.

Per gli eventi fuori ordine, distinguere tra l'ora di ricezione del callback e l'ora che il DLR, quando disponibile, attribuisce all'esito. SMPP definisce done date come la data e l'ora in cui il messaggio ha raggiunto lo stato finale. Questo timestamp può aiutare a ordinare le evidenze, ma non sostituisce l'ora in cui il sistema le ha ricevute.

In presenza di contraddizioni, non forzare una conclusione senza una regola esplicita. Segnalare la discrepanza, conservare tutti gli eventi, applicare una precedenza documentata solo alla vista materializzata e, se necessario, consultare i registri disponibili o inoltrare il caso al responsabile della connessione. Le regole devono poter evolvere perché i campi dei callback e le loro proprietà possono variare nel tempo.

• Non sovrascrivere l'ultimo stato senza conservare la sequenza precedente.
• Usare elaborazione idempotente per impedire effetti collaterali duplicati.
• Memorizzare separatamente il timestamp di ricezione e quello dichiarato dal DLR.
• Classificare i conflitti per la revisione, anziché nasconderli.
• Versionare le regole di precedenza e testare le modifiche prima di applicarle.