DLR tardios em SMS A2P: como definir uma janela de observação e encerrar mensagens sem perder rastreabilidade

O que é um DLR tardio numa cadeia de SMS A2P

Um delivery receipt, ou DLR, é um evento de estado relativo a um SMS submetido anteriormente. Em SMPP, quando solicitado através de registered_delivery, o SMSC pode enviar esse recibo ao ESME através de deliver_sm. Não é a resposta síncrona a submit_sm nem deve ser tratado como tal.

Um DLR tardio é um recibo que chega depois do momento em que uma aplicação, uma operação ou uma equipa de suporte esperava tomar uma decisão. Pode surgir porque o ciclo da mensagem passa por vários sistemas e porque podem existir tentativas de entrega intermédias. O SMPP prevê, por exemplo, que uma tentativa falhe enquanto o SMS continua retido para novas tentativas; o suporte concreto destas notificações depende da implementação do SMSC e do fornecedor.

O atraso do evento não invalida, por si só, o evento. Indica que a decisão operacional da empresa e o ciclo de notificação da cadeia de entrega não estavam necessariamente sincronizados. Por isso, convém conceber um encerramento operacional reversível em termos de interpretação, mas não destrutivo em termos de dados.

• Não equipare a resposta de aceitação do envio a um DLR.
• Não trate a ausência de callback como prova automática de falha final.
• Conserve o evento bruto, mesmo que chegue após o encerramento operacional.
• Mantenha separadas a semântica recebida do fornecedor e a classificação interna.

Três relógios que não devem ser confundidos

A gestão de DLR tardios começa por separar três controlos que respondem a perguntas diferentes. Se forem usados como se fossem o mesmo, ocorrem encerramentos prematuros, expirações mal interpretadas e diagnósticos pouco fiáveis.

O timeout de API determina quanto tempo a aplicação aguarda uma resposta técnica ao seu pedido. Se expirar, a aplicação deve resolver a incerteza desse pedido com um identificador de correlação, uma consulta de estado ou uma estratégia segura de nova tentativa. Não determina durante quanto tempo o SMS pode ser entregue nem durante quanto tempo pode chegar um DLR.

O período de validade determina até quando um centro de serviço pode conservar uma mensagem para tentar entregá-la. Em SMPP, validity_period representa a hora de expiração após a qual o SMSC deve descartar a mensagem caso não tenha sido entregue. Em 3GPP, a validade pode ser expressa em formatos relativo, absoluto ou melhorado. A expiração da validade é um desfecho de rede; não deve ser deduzida simplesmente porque não chegou um callback.

A janela de observação do DLR é uma política operacional própria. Define durante quanto tempo se aguarda um desfecho para alimentar fluxos de negócio, alertas, suporte ou relatórios operacionais. Não é estabelecida pelo protocolo e não deve ser equiparada ao timeout nem copiada mecanicamente do período de validade.

• Timeout de API: limite de espera por uma resposta técnica.
• Validade da mensagem: limite de retenção e tentativas de entrega na cadeia aplicável.
• Janela de observação: limite interno para decidir um estado operacional, não para apagar evidências.
• Período de reconciliação: intervalo posterior para recuperar ou confrontar eventos em falta e alterações tardias.

Porque «aceite» ou «enviado» não confirma a entrega

Um estado de aceitação ou envio deve ser descrito com precisão. Numa semântica documentada por um fornecedor, sent significa que o operador a montante mais próximo aceitou a mensagem. Isto não equivale a confirmar a entrega no destino.

Mesmo quando um DLR indique entregue, a comunicação deve preservar o alcance real da evidência. A especificação 3GPP distingue entre uma mensagem recebida pelo SME e uma mensagem reencaminhada pelo centro de serviço sem que este consiga confirmar a sua entrega. Além disso, a evidência que um fornecedor pode expor depende da confirmação disponível junto do operador e, quando exista, do terminal.

Assim, um estado delivered deve ser registado como a confirmação de entrega reportada pela cadeia disponível, e não como prova universal, independente ou equivalente à leitura pela pessoa destinatária. A leitura, a compreensão e a realização de uma ação num fluxo de negócio são factos distintos do DLR.

• Aceite: o pedido ou a mensagem foi admitido num ponto da cadeia.
• Enviado: pode refletir transferência ou aceitação a montante, conforme a semântica documentada.
• Entregue: reflete uma confirmação reportada, cujo alcance depende da evidência disponível.
• Lido, utilizado ou convertido: requer sinais independentes da aplicação ou do utilizador.

Como modelar estados internos sem substituir a evidência

Os callbacks são assíncronos e o estado de uma mensagem pode mudar durante o seu ciclo de vida. Por isso, o estado bruto de um fornecedor não deve ser o único campo a governar a operação. Convém manter um histórico imutável de eventos e uma vista interna calculada para cada mensagem.

Um modelo prático pode usar pendente, provisório, final e atualizado tardiamente. Estes nomes descrevem a posição operacional da empresa, não substituem a semântica original do DLR. O registo deve conservar tanto o evento recebido como a regra pela qual foi interpretado.

Pendente pode representar que existe uma aceitação técnica ou que ainda não foi recebido um desfecho suficiente. Provisório indica que foi tomada uma ação de negócio ou de suporte perante uma incerteza explícita. Final identifica um desfecho recebido e classificado segundo as regras em vigor. Atualizado tardiamente indica que um evento posterior alterou a vista calculada ou forneceu informação relevante após o encerramento operacional.

Não convém substituir um estado anterior nem eliminar eventos por parecerem redundantes. Guarde a sequência e calcule a vista atual com regras versionadas. Assim, poderá explicar porque uma mensagem foi encerrada num dado momento e porque a sua interpretação foi mais tarde atualizada.

• Evento bruto: conteúdo recebido, identificador, origem e hora de receção.
• Estado normalizado: tradução controlada da semântica externa.
• Estado operacional: pendente, provisório, final ou atualizado tardiamente.
• Motivo de transição: regra aplicada, versão da regra e interveniente, caso tenha existido intervenção manual.
• Estado de reconciliação: confirmado por eventos recebidos, consultado, pendente de revisão ou com discrepância.

Definir janelas conforme o caso de utilização

Não existe uma duração universal para uma janela de observação. Deve resultar da finalidade da mensagem, do impacto de esperar, da validade configurada, dos sinais históricos disponíveis e da capacidade real de reconciliar e tratar exceções.

Em OTP, a vigência funcional do código deve ser decidida pela lógica de autenticação. O DLR fornece observabilidade e diagnóstico, mas não deve bloquear a expiração do código nem o fluxo de autenticação. Defina a janela para detetar incidentes, orientar novas tentativas seguras ou informar o suporte, sem a transformar na fonte de verdade sobre a vigência da credencial.

Em notificações transacionais, a janela pode alinhar-se com o momento em que o destinatário precisa de agir e com as obrigações internas de atendimento. Se, no encerramento, não existir um desfecho, o estado deve comunicar incerteza e ativar o processo previsto, sem assumir entrega nem falha definitiva.

Em mensagens não urgentes, uma janela mais ampla pode ser razoável se o objetivo tolerar entrega diferida. Ainda assim, a janela deve continuar independente da retenção em redes posteriores: uma plataforma pode aplicar a sua própria validade enquanto a mensagem nela permanece e, depois de transferida para o operador, este pode continuar a colocá-la em fila durante mais tempo.

• OTP: separe sempre a expiração do código, a validade do SMS e o acompanhamento do DLR.
• Transacional: defina ações de suporte ou canais alternativos quando a incerteza persistir.
• Não urgente: tolere uma observação mais extensa apenas se o caso de utilização e a política o justificarem.
• Todos os casos: mantenha a reconciliação após o encerramento operacional.

Critérios para escolher uma janela de observação

A decisão deve ser documentada e passível de revisão. Evite definir um único valor sem observar como os eventos se comportam nos seus próprios destinos, operadores, rotas, tipos de remetente e conteúdos legítimos. Os dados históricos ajudam a orientar uma política; não transformam um padrão passado numa garantia futura.

Analise a distribuição de tempo entre a aceitação inicial, os estados intermédios e os desfechos recebidos. Segmente a análise por atributos operacionais permitidos e necessários ao serviço, sem usar a segmentação para ocultar problemas nem para enviar tráfego não conforme.

A janela deve ser coerente com o requisito de serviço. Se uma operação precisar de decidir antes de normalmente poder existir evidência suficiente, deve conceber um fluxo que aceite incerteza: por exemplo, apresentar um estado pendente, aplicar uma verificação adicional ou utilizar um canal alternativo em conformidade com a política aplicável.

A capacidade de suporte também é importante. Uma janela curta pode reduzir a fila visível, mas aumenta o risco de classificar demasiado cedo. Uma janela ampla reduz determinados encerramentos prematuros, mas pode atrasar alertas e aumentar as mensagens em acompanhamento. A política deve declarar este compromisso.

• Comportamento histórico dos DLR por destino, operador, rota e tipo de tráfego.
• Criticidade e prazo real do caso de utilização.
• Período de validade configurado e semântica documentada de cada ligação.
• Taxas de eventos tardios, duplicados, ausentes ou fora de ordem.
• Capacidade de consulta, reconciliação, tratamento de incidentes e comunicação ao cliente.
• Requisitos contratuais, regulamentares e de conservação de registos aplicáveis.

Conceção de uma política de encerramento e conservação de dados

Uma política de encerramento define o que acontece quando termina a janela de observação sem um desfecho conclusivo, que eventos podem alterar a vista posteriormente e quem pode aprovar exceções. O encerramento deve ser uma decisão operacional auditável, não a eliminação da mensagem do sistema.

Estabeleça uma taxonomia clara para os casos sem desfecho. Por exemplo, «encerrado provisoriamente sem DLR final recebido» comunica mais do que «falhou» quando não existe um erro final reportado. Reserve os estados definitivos para evidências que realmente sustentem essa classificação.

A política deve indicar quem é responsável pelas regras: operações, produto, engenharia, entrega ou um comité conjunto, consoante o modelo organizacional. Deve também definir um processo de alteração: motivo, avaliação de impacto, versão, data de entrada em vigor, aprovação e plano de reversão.

Documente exceções previsíveis, como incidentes de conectividade de callback, alterações de integração, discrepâncias identificadas na reconciliação ou rotas com semânticas distintas. Uma exceção não deve alterar retroativamente o histórico bruto; deve modificar de forma rastreável a interpretação ou o tratamento operacional.

• Identificador interno único da mensagem.
• Identificador devolvido pelo fornecedor ou pela ligação, quando existente.
• Identificadores de conta, serviço ou rota disponíveis e relevantes.
• Origem, destino e atributos necessários à correlação, protegidos segundo a política de dados aplicável.
• Estado inicial, eventos posteriores, payload bruto conservado de forma segura e estado normalizado.
• Hora do pedido, da aceitação, da receção do callback e, quando disponível, hora de conclusão indicada pelo DLR.
• Regra, versão e motivo de cada transição interna.
• Resultado de consultas de reconciliação e referência do incidente, se aplicável.

DLR duplicados, fora de ordem ou contraditórios

A receção de mais de um evento para a mesma mensagem não deve obrigar a escolher um e descartar os restantes. Deduplicar para evitar ações repetidas é útil; apagar duplicados aparentes elimina evidência que pode ser necessária para diagnóstico.

Use uma chave de idempotência baseada nos identificadores disponíveis e numa impressão digital do evento. Se receber dois eventos equivalentes, pode marcá-los como repetidos na vista operacional, mas conserve ambos ou mantenha uma referência verificável ao evento original, conforme a política de retenção. A idempotência deve ser aplicada sobretudo a ações laterais, como notificações, faturação interna ou abertura de tickets.

Para eventos fora de ordem, diferencie a hora de receção do callback da hora que o DLR, quando disponível, atribui ao desfecho. O SMPP define done date como a data e hora em que a mensagem atingiu o estado final. Essa marca pode ajudar a ordenar a evidência, mas não substitui a hora em que o seu sistema a recebeu.

Perante contradições, não force uma conclusão sem uma regra explícita. Assinale a discrepância, conserve todos os eventos, aplique uma precedência documentada apenas à vista materializada e, se necessário, consulte os registos disponíveis ou encaminhe o caso ao responsável pela ligação. As regras devem poder evoluir porque os campos de callback e as suas propriedades podem variar ao longo do tempo.

• Não substitua o último estado sem conservar a sequência anterior.
• Use processamento idempotente para impedir efeitos secundários duplicados.
• Armazene separadamente o timestamp de receção e o timestamp declarado pelo DLR.
• Classifique conflitos para revisão, em vez de os ocultar.
• Versione as regras de precedência e teste alterações antes de as aplicar.