Mensagens SMS A2P em estado incerto: como reconciliar evidências sem reenviar prematuramente

O que significa uma mensagem estar em estado incerto

«Incerto» pode ser usado como uma categoria interna para indicar que as evidências disponíveis não permitem determinar o resultado segundo os critérios definidos para uma integração. As informações fornecidas aqui não sustentam uma definição técnica universal deste estado.

Convém distinguir os factos conhecidos, como uma tentativa de envio ou uma resposta de uma interface, das conclusões que não foram demonstradas. Não presuma que uma aceitação significa entrega, nem que a ausência de resposta comprova uma falha.

O significado de cada estado e as evidências que o sustentam dependem da interface e da documentação aplicável. Sem documentação pertinente, não é possível estabelecer regras gerais para respostas de API, sessões SMPP ou relatórios de entrega (DLR).

• Registe separadamente os factos observados e a interpretação interna que lhes é atribuída.
• Não transforme a ausência de resposta numa afirmação sobre o que aconteceu no sistema remoto.
• Defina qualquer categoria operacional de acordo com a documentação disponível e o acordo específico.

Reúna evidências e preserve as informações disponíveis

A análise pode começar pela recolha dos registos já disponíveis na aplicação, na interface e na plataforma de mensagens. Anote qual sistema forneceu cada dado e quando foi registado. Estas são sugestões de organização interna, não uma descrição do comportamento de uma tecnologia específica.

Não presuma que os identificadores de sistemas diferentes são equivalentes ou permitem correlacionar eventos automaticamente. Para estabelecer uma relação entre eles, consulte a documentação da integração correspondente.

Se a equipa criar uma classificação interna ou normalizar estados, também pode preservar o valor recebido e documentar a regra interna aplicada. As evidências fornecidas não determinam como devem ser implementadas a correlação ou o tratamento de eventos.

• Como controlo interno sugerido, registe as referências disponíveis, os carimbos temporais e o sistema de origem.
• Documente as limitações de correlação em vez de associar uma evidência a um envio sem fundamento.
• Preserve a distinção entre o dado recebido e a interpretação interna, se o processo da sua equipa o permitir.

Defina critérios internos dependentes da interface

Uma equipa pode estabelecer critérios internos para classificar os casos e decidir quando os analisar. Sem documentação técnica suficiente, esses critérios devem ser apresentados como controlos da própria equipa, não como uma máquina de estados universal nem como um comportamento esperado de todos os fornecedores.

Documente que informações disponíveis levam a cada decisão interna e como são analisados os casos com dados incompletos ou contraditórios. As evidências fornecidas não permitem especificar o comportamento de eventos duplicados ou tardios, nem estabelecer transições técnicas gerais.

Se dois registos parecerem incompatíveis, preserve a discrepância como tal e consulte a documentação aplicável. Não escolha automaticamente um estado por ser mais recente ou mais favorável.

• Identifique como internas as categorias e regras que não estejam definidas na documentação da interface.
• Adapte qualquer critério às informações efetivamente disponíveis para a integração.
• Registe as discrepâncias e evite resolvê-las com base em pressupostos.

Aplique regras prudentes para encerrar casos

O encerramento de um caso é uma decisão operacional que deve basear-se nos critérios definidos para a integração. As evidências disponíveis não estabelecem um prazo comum nem uma lista universal de estados finais.

Com estas fontes, não é possível confirmar diretamente o que significa um DLR com o estado «entregue» em cada plataforma. Por isso, não o apresente como prova universal de receção no dispositivo, nem atribua a todas as plataformas a mesma semântica.

Ao encerrar um caso, separe o estado comunicado pelo sistema de qualquer conclusão adicional sobre a receção. Afirme que a receção foi verificada apenas quando a integração fornecer evidências adequadas e os seus limites forem conhecidos.

• Defina os critérios de encerramento segundo a documentação e os acordos aplicáveis.
• Descreva um DLR como um estado comunicado; não generalize sobre aquilo que comprova.
• Registe as incertezas que persistam ao encerrar o caso.

Escolher entre aguardar, consultar, encerrar ou escalar

A ação depende das ferramentas documentadas para a integração e dos critérios acordados pela equipa. As evidências fornecidas não confirmam a existência de uma função de consulta para todos os fornecedores ou interfaces.

Como controlo interno sugerido, a equipa pode definir quando manter um caso aberto, quando consultar uma função documentada e quando encaminhar uma discrepância para análise. Se não for possível determinar o resultado, pode marcá-lo como indeterminado segundo o seu próprio processo.

Ao partilhar um caso com um fornecedor, utilize as informações necessárias para descrever a discrepância e siga as regras de proteção de dados aplicáveis. Estas recomendações são orientações organizacionais, não capacidades técnicas confirmadas.

• Aguardar: opção de processo interno se o caso ainda estiver dentro do critério acordado.
• Consultar: apenas se a documentação da interface descrever uma consulta aplicável.
• Escalar: opção interna perante uma discrepância ou informações insuficientes que exijam análise.
• Encerrar como indeterminado: decisão interna quando o processo acordado não permitir concluir outro resultado.

Evite reenvios automáticos, sobretudo em fluxos OTP

As evidências disponíveis não permitem determinar que mecanismos de deduplicação, consulta ou repetição são oferecidos pelas várias plataformas. Por isso, um timeout, a ausência de um DLR ou um estado pendente não devem ser tratados aqui como prova suficiente de falha nem como sinal técnico universal para reenviar.

Como controlo interno sugerido, separe a investigação do envio original da decisão de iniciar outro envio. Antes de uma nova tentativa, aplique a política de repetição documentada para a aplicação e a integração; não presuma que o sistema reconhecerá um pedido repetido como a mesma operação.

Em fluxos OTP, siga as regras de negócio, segurança, privacidade e consentimento aplicáveis. Comunique claramente o estado conhecido, sem apresentar uma nova tentativa como garantia de entrega.

• Não atribua deduplicação ou idempotência a uma interface sem documentação que o confirme.
• Aplique os controlos de repetição definidos pela aplicação e pela integração.
• Em comunicações OTP, evite apresentar uma nova tentativa como garantia de resultado.

Quadro prático de decisão

Este quadro é um apoio interno, não uma especificação de API nem uma descrição universal dos estados disponibilizados pelos fornecedores. Adapte-o à documentação e aos acordos aplicáveis.

Antes de o utilizar, confirme que informações a interface disponibiliza e que conclusões permitem tirar. Se não for possível identificar a origem ou a relação entre os registos, anote essa limitação.

• Resposta de aceitação sem informações posteriores: interprete a resposta apenas segundo a documentação aplicável; qualquer espera ou consulta é uma decisão de processo interno.
• Sem resposta ao pedido: registe o facto observado; não conclua automaticamente se foi aceite ou o que aconteceu depois.
• DLR recebido: preserve o estado comunicado e consulte a respetiva definição; não o transforme numa afirmação universal de receção no dispositivo.
• DLR sem correlação fiável: não o associe a um envio sem fundamento documentado.
• Informações incompatíveis: preserve os dados disponíveis e siga o processo interno de análise ou escalamento.
• Sem evidências suficientes: classifique o caso de acordo com o processo interno, sem afirmar um resultado que não tenha sido demonstrado.

Analise a incerteza e as decisões

Um indicador de casos incertos só pode ser interpretado se a equipa definir que casos inclui, o período observado e como regista as alterações posteriores. As evidências disponíveis não fornecem referências de desempenho nem números a utilizar.

Um processo interno pode analisar os casos em aberto, as discrepâncias, as limitações de correlação e as decisões de reenvio. Mantenha separadas as categorias baseadas em estados comunicados e as afirmações de receção verificada.

A análise pode ajudar a identificar lacunas na documentação ou no processo. Não atribua a um indicador conclusões que os dados não permitam sustentar.

• Defina o período e os critérios utilizados para identificar casos incertos.
• Registe as discrepâncias e as limitações das informações disponíveis.
• Analise as decisões de reenvio segundo a política interna aplicável.
• Distinga os estados comunicados de qualquer receção verificada.