Expiração de mensagens na cadeia A2P SMS: alinhar validade, filas e tentativas

A validade solicitada não descreve necessariamente toda a cadeia

Numa operação A2P SMS, convém distinguir o que a aplicação solicita daquilo que cada componente da rota efetivamente aplica. Uma aplicação pode indicar um período de validade, enquanto uma plataforma ou um intermediário mantém a sua própria fila e as suas regras de novas tentativas. Sem documentação específica para cada etapa, não é possível concluir que o valor configurado pelo emissor determina quando cessam todas as tentativas de entrega.

Também não é prudente interpretar uma expiração registada como prova universal de que a mensagem não poderá aparecer mais tarde no telemóvel. A evidência técnica e contratual da rota deve esclarecer o significado desse estado e o comportamento esperado. Se essa evidência não existir, mantenha a incerteza e evite prometer um prazo-limite de entrega.

• Trate a validade solicitada como um parâmetro da interface que deve ser verificado, não como uma garantia de extremo a extremo.
• Identifique separadamente quem aceita, armazena, tenta entregar novamente e comunica o resultado da mensagem.
• Não confunda um estado recebido por uma plataforma com uma confirmação independente de receção no dispositivo.

Validade, fila, novas tentativas e expiração na rede são conceitos distintos

Para analisar um incidente, defina cada termo com base na documentação do componente correspondente. O período de validade solicitado é o valor que o sistema emissor pretende aplicar. O armazenamento em fila indica durante quanto tempo um componente conserva uma mensagem pendente. As novas tentativas são as tentativas posteriores que esse componente efetua segundo as suas regras. A expiração na rede, se estiver disponível e documentada para a interface utilizada, diz respeito ao comportamento dessa parte da rota.

Não deduza que os quatro conceitos partilham o início da contagem, a unidade, o limite ou a semântica. As fontes disponíveis não permitem afirmar regras universais para a interação entre eles em A2P SMS. Como contraste metodológico, a documentação do Microsoft Exchange descreve a expiração após um período especificado de falhas de entrega nesse sistema; essa regra não se transfere automaticamente para SMS (Microsoft Learn, «Intervalos de repetição, reenvio e expiração de mensagens no Exchange Server 2013»: https://learn.microsoft.com/es-es/exchange/message-retry-resubmit-and-expiration-intervals-exchange-2013-help).

As especificações 3GPP são uma referência oficial, mas o índice geral por séries não basta para estabelecer as regras concretas aplicáveis a uma interface ou rota (https://www.3gpp.org/specifications-technologies/specifications-by-series). Para tomar decisões, solicite a documentação técnica pertinente e as condições operacionais do fornecedor e do operador.

• Registe separadamente o valor enviado pela aplicação e o valor que cada interface confirma ter aceitado.
• Solicite definições por escrito de fila, novas tentativas e expiração para cada etapa envolvida.
• Não extrapole regras de outros sistemas de mensagens nem transforme um valor configurado numa garantia de entrega ou de não entrega.

O que documentar em cada etapa

Mantenha uma ficha por interface e fornecedor. O objetivo não é presumir que todos disponibilizam os mesmos parâmetros, mas identificar o que está disponível, o que é aceite e o que está fora do controlo de cada parte. Se um campo não existir ou não puder ser confirmado, registe-o como desconhecido em vez de inferir o seu comportamento.

Garanta que os termos operacionais são comparáveis: um valor expresso em segundos não é diretamente permutável com outro expresso numa unidade diferente sem conhecer os arredondamentos e os limites; uma hora registada sem fuso horário pode dificultar a reconstrução da sequência. Confirme também qual é o evento que inicia a contagem do prazo e que sistema é a fonte de cada marca temporal.

Peça esclarecimentos sobre se um intermediário conserva ou substitui os parâmetros recebidos, se aplica limites próprios, como trata as mensagens pendentes e que estados devolve. A evidência disponível não permite especificar uma regra comum para estas funções.

• Interface e etapa: emissor, destinatário da mensagem e componente que comunica o estado.
• Parâmetro: nome, unidade, valor solicitado, valor aceite ou limite documentado.
• Tempo: evento que inicia a contagem, formato, fuso horário e fonte da marca temporal.
• Regras: limites máximos, substituições, armazenamento, condições e limites para novas tentativas, apenas quando estiverem documentados.
• Estados: definição contratual de aceitação, pendente, rejeição, expiração e resultado inconclusivo.
• Evidência: identificador correlacionável, registos disponíveis e responsável por investigar discrepâncias.

Conceber testes controlados sem os transformar em garantias

Um teste pode revelar como uma rota se comportou em determinadas condições, mas não demonstra que todas as rotas, destinos ou situações terão o mesmo comportamento. Antes de testar, acorde o âmbito com os participantes e utilize tráfego legítimo, consentido e de teste, para destinos controlados e autorizados. Evite enviar mensagens a terceiros ou utilizar testes para contornar controlos.

Planeie casos separados para uma mensagem aceite e pendente, um destino temporariamente inacessível quando exista um ambiente de teste autorizado e a chegada de um DLR depois de a aplicação ter deixado de aguardar. Registe os valores enviados, o que cada interface aceitou, as marcas temporais, os identificadores e os estados observados. Não presuma que a rede permite simular uma condição específica nem que um teste isolado representa o seu comportamento geral.

Compare os resultados com a documentação acordada. Se não for possível correlacionar um estado tardio com a mensagem original ou se a sua semântica não estiver definida, classifique-o como uma discrepância por esclarecer, não como prova conclusiva de entrega ou não entrega.

• Acordar previamente o destino controlado, o tráfego permitido e o critério de paragem.
• Conservar o pedido original, as respostas por etapa e as marcas temporais.
• Repetir apenas dentro do âmbito autorizado e documentar as condições de cada execução.
• Separar os resultados observados das expectativas contratuais e de qualquer conclusão geral.

Interpretar expiração, rejeição e resultado incerto

O nome de um estado não basta para conhecer o seu significado. Verifique quem o gerou, que evento representa, se é final nos termos do acordo e se pode chegar depois de outro estado. Não presuma que «expirado» tem a mesma semântica numa aplicação, num agregador e numa rede móvel.

Uma rejeição pode ter origem num componente específico e, por si só, não explicar o que aconteceu antes ou depois nas restantes etapas. Um resultado incerto significa que a evidência disponível não permite confirmar um resultado final; não o transforme em sucesso ou falha para fazer coincidir os relatórios. Se chegar um DLR tardio, conserve o estado original e a atualização, associando-os ao mesmo identificador sempre que possível.

Um DLR comunicado por uma plataforma é um sinal do sistema que o reporta. Sem verificação independente, não o descreva como prova de receção física pelo terminal. Documente a origem e a semântica declarada do estado.

• Conservar o estado bruto recebido, o emissor do estado e a hora de receção.
• Não substituir um resultado incerto por uma interpretação sem fundamento.
• Encaminhar estados contraditórios, sem definição ou sem correlação suficiente para o responsável pela etapa.
• Esclarecer se o encerramento operacional significa fim do acompanhamento, expiração reportada ou confirmação de entrega.

Procedimento operacional para configurar e rever limites

Comece pelo requisito de negócio: durante quanto tempo a mensagem continua a ser útil e que risco representa se chegar mais tarde. Um OTP, um alerta transacional e uma campanha podem ter necessidades diferentes; a política deve refletir o caso de utilização e as obrigações aplicáveis, sem presumir que uma configuração técnica resolve, por si só, o risco.

Em seguida, acorde com cada fornecedor que parâmetro pode aplicar, que limites tem e que evidência devolve. Configure valores coerentes com a informação confirmada para as etapas relevantes. Se uma parte não confirmar como trata a validade ou as novas tentativas, registe essa limitação e decida se a rota é adequada ao caso de utilização; não preencha a lacuna com uma suposição.

Na operação, conserve as marcas temporais e os estados de cada interface e reveja as diferenças entre o que foi solicitado e o que foi comunicado. Investigue primeiro as etapas em que falte uma confirmação ou tenha ocorrido uma substituição não documentada. Não presuma que uma configuração garante expiração uniforme de extremo a extremo.

• Definir a utilidade temporal da mensagem e o impacto de uma entrega obsoleta.
• Acordar responsabilidades e semântica dos estados com cada participante da rota.
• Configurar apenas parâmetros cujo significado e limites estejam confirmados.
• Registar os valores solicitados e aceites, as marcas temporais e as alterações de estado.
• Rever discrepâncias e atualizar a ficha operacional quando uma interface ou acordo mudar.

Lista de verificação antes de encerrar uma mensagem

Encerre o caso segundo uma regra acordada e verificável, não apenas porque decorreu o prazo configurado na aplicação. Defina que estado permite interromper a investigação, que evidência deve ser conservada e quando uma resposta tardia reabre ou atualiza o registo. Se o acordo não definir estes pontos, registe a limitação.

O objetivo é reduzir entregas obsoletas e encurtar os diagnósticos, não prometer que uma configuração impedirá todas as entregas tardias. Se as consequências de uma entrega fora de prazo forem graves, valide o comportamento com os responsáveis pela rota e estabeleça controlos de negócio adequados ao tipo de mensagem.

• Está identificado o início da contagem e a unidade de cada parâmetro relevante?
• Está documentado que componente conserva a mensagem e quais são as suas regras para novas tentativas?
• Sabe-se se os parâmetros podem ser substituídos ou limitados numa etapa posterior?
• Os estados recebidos têm uma definição, uma origem e uma marca temporal identificáveis?
• A equipa distingue um DLR comunicado de uma receção verificada de forma independente?
• Existe um procedimento para estados incertos, tardios ou contraditórios?
• O critério de encerramento evita apresentar como definitiva uma conclusão sem evidência suficiente?