Gestão de filas de saída A2P SMS: admissão, escoamento e recuperação
Um guia operacional para definir quais mensagens a fila admite, como classificá-las em caso de falha, quando expiram e como recuperar o fluxo sem confundir aceitação pelo sistema seguinte com entrega ao destinatário.
A fila começa onde um sistema retém a mensagem
Numa cadeia A2P podem existir várias filas: na aplicação emissora, na plataforma de mensagens, numa ligação ou num intermediário e em sistemas posteriores. Para operar com clareza, identifique qual é a fila que está a medir e quem é responsável por cada transição.
Uma mensagem «em fila» ainda não equivale a uma mensagem aceite pelo sistema seguinte, e a aceitação desse sistema também não prova que a mensagem tenha chegado ao telefone. Defina explicitamente a fronteira de responsabilidade: por exemplo, mensagem recebida pela plataforma, tentativa de envio, resposta de aceitação do sistema seguinte e resultado posterior da entrega, se estiver disponível.
- Atribua a cada mensagem um identificador que possa ser correlacionado entre os sistemas que controla.
- Registe quando a mensagem entra na fila, quando o processamento é tentado e que resultado o sistema seguinte devolve.
- Mantenha separados os estados internos e os estados comunicados por interfaces ou relatórios externos.
Defina estados que expliquem o que aconteceu
Um modelo interno útil permite distinguir o trabalho pendente daquele que está a ser processado e daquele que já obteve uma resposta do sistema seguinte. Deve também representar as mensagens adiadas, expiradas ou colocadas em revisão. Estas são categorias operacionais: não devem ser apresentadas como uma lista normativa de estados SMPP nem confundidas automaticamente com códigos de uma interface.
Documente as transições permitidas, o evento que as desencadeia e o sistema que fornece a evidência. Por exemplo, uma resposta de aceitação do sistema seguinte pode encerrar a responsabilidade da fila local, mas não deve ser identificada como entrega final ao destinatário, a menos que exista evidência adequada para o sustentar.
- Pendente: admitida pela plataforma, ainda sem tentativa ativa.
- Em processamento: um trabalhador está a gerir o envio.
- Aceite pelo sistema seguinte: o sistema seguinte confirmou que aceita a mensagem; isso não implica receção no terminal.
- Adiada: o processamento é postergado segundo uma política definida.
- Expirada: o período de utilidade temporal da mensagem terminou e ela não deve ser enviada como se ainda estivesse válida.
- Em revisão: requer uma decisão operacional antes de ser retomada ou encerrada.
Admita tráfego de forma a proteger a capacidade
Uma fila não deve crescer sem um limite operacional. Defina limites de admissão e de capacidade em função dos recursos que realmente controla: armazenamento, trabalhadores disponíveis, ligações e capacidade configurada para os destinos ou classes de tráfego. Não existe um limiar universal que possa ser definido sem conhecer a arquitetura, os acordos e o comportamento observado.
Segmentar por destino ou classe pode ajudar a evitar que um fluxo problemático ocupe todos os recursos de outros fluxos. A segmentação também acrescenta complexidade: defina o que acontece quando um limite é atingido, como o resultado é comunicado ao emissor e quem pode ajustar a política. Evite aceitar uma mensagem se o sistema não puder conservá-la de forma fiável até a processar ou rejeitá-la claramente.
- Estabeleça limites por fila e pelos segmentos com comportamentos ou requisitos distintos.
- Defina uma ação explícita quando a capacidade for atingida: rejeitar, adiar ou aplicar outra política documentada.
- Garanta que a aplicação emissora consegue distinguir uma admissão de uma rejeição e gerir as suas próprias novas tentativas sem duplicar envios.
- Reveja os limites com base em dados de entrada, saída, antiguidade e recursos, e não em valores genéricos.
Classifique a falha antes de voltar a tentar
Nem todas as falhas justificam o mesmo tratamento. Uma saturação temporária, uma indisponibilidade, uma rejeição potencialmente transitória e um erro que exige a correção da mensagem ou da configuração têm implicações diferentes. Use a resposta concreta da interface ou do sistema ligado e a documentação aplicável para a classificar; não invente equivalências entre códigos.
Para cada classe de falha, documente se a mensagem deve ser novamente tentada, adiada, rejeitada ou encaminhada para revisão. As novas tentativas devem ser limitadas e coordenadas entre o emissor e a plataforma: se ambos repetirem o envio sem coordenação, podem aumentar a carga e criar duplicados. Conserve o resultado original para facilitar o diagnóstico.
- Saturação: proteja os recursos e aplique a política definida de admissão ou adiamento.
- Indisponibilidade: determine se é adequado aguardar e voltar a tentar, com limites e registo do motivo.
- Rejeição potencialmente recuperável: confirme que condição deve mudar antes de uma nova tentativa.
- Erro permanente ou que não pode ser corrigido automaticamente: evite ciclos de novas tentativas e encaminhe o caso para encerramento ou revisão.
- Em todos os casos, registe a resposta observada e a decisão aplicada.
Ordenação e prioridade sem inanição
FIFO — primeiro a entrar, primeiro a sair — é uma opção simples quando as mensagens de uma fila têm requisitos de urgência semelhantes e não há motivo operacional para alterar a ordem. Se houver classes com diferentes prazos de validade ou prioridades, uma política explícita pode ser mais adequada, mas deve preservar a rastreabilidade e evitar que o tráfego de prioridade mais baixa fique bloqueado indefinidamente.
Antes de introduzir prioridades, defina que mensagens podem pertencer a cada classe, quem determina essa classificação e como verificar se a política funciona. Não baseie a prioridade em conteúdo sensível nem a utilize para contornar controlos de consentimento ou conformidade.
- Use FIFO se a ordem for um requisito e a classe for homogénea.
- Separe classes apenas se existir uma necessidade operacional justificada e verificável.
- Meça o tempo de espera por classe e verifique se alguma prioridade causa inanição noutras classes.
- Documente o comportamento para mensagens com a mesma prioridade e para mudanças de classe.
Alinhe o prazo de validade com a utilidade da mensagem
O prazo de validade expressa durante quanto tempo continua a ser útil enviar uma mensagem. Um código de utilização única, uma notificação transacional e uma campanha autorizada podem ter necessidades temporais distintas; não pressuponha que partilham um prazo adequado. O responsável pela mensagem deve definir essa utilidade, e a plataforma deve aplicar uma política coerente com ela.
Quando uma mensagem expira, não a envie silenciosamente como se ainda fosse válida. Registe a expiração e comunique o resultado de forma que o sistema emissor possa decidir o que fazer. Se for considerado um novo envio, este deve ser tratado como uma nova decisão de negócio, e não como uma repetição automática de conteúdo obsoleto.
- Defina o prazo de validade para cada caso de utilização com o responsável pela mensagem.
- Verifique a antiguidade antes de cada nova tentativa, quando a política o exigir.
- Distinga a expiração da rejeição ou da falha de entrega.
- Evite reativar automaticamente mensagens expiradas sem uma decisão explícita.
Recupere o serviço com um escoamento controlado
Após uma interrupção, recuperar não consiste apenas em retomar todos os envios pendentes. Primeiro, confirme que a causa da acumulação foi resolvida e que o sistema seguinte pode aceitar tráfego. Depois, liberte o trabalho gradualmente, de acordo com a capacidade disponível e com limites de simultaneidade definidos pela configuração e pelos acordos aplicáveis.
Durante o escoamento, verifique se a antiguidade ou a profundidade da fila voltam a aumentar, se as rejeições se tornam mais frequentes e se os resultados esperados se mantêm. Uma fila que diminui não é prova suficiente de recuperação se as mensagens estiverem a expirar, a ser rejeitadas ou encaminhadas para revisão sem que a equipa se aperceba.
- Identifique e corrija a causa da interrupção antes de acelerar os envios.
- Retome o processamento com limites controlados, em vez de escoar sem restrições todas as mensagens acumuladas.
- Verifique separadamente a aceitação pelo sistema seguinte e os resultados posteriores.
- Mantenha um procedimento para voltar a pausar se a acumulação reaparecer ou os resultados piorarem.
Monitorize a saúde da fila, não apenas o seu tamanho
A profundidade indica quantas mensagens estão à espera, mas, por si só, não explica se a situação está a melhorar. Acrescente a antiguidade da mensagem mais antiga, as taxas de entrada e saída e os resultados agrupados por destino e classe. Interprete estas métricas juntamente com os eventos de admissão, rejeição, adiamento e expiração.
A aceitação pelo sistema seguinte deve ser apresentada como aceitação, não como entrega final. Se forem recebidos relatórios de entrega, o seu significado depende da origem e do nível de verificação: um DLR recebido não equivale necessariamente a uma receção no terminal verificada de forma independente. Documente essa incerteza nos painéis e relatórios.
- Profundidade da fila e antiguidade da mensagem mais antiga.
- Taxas de entrada e saída em intervalos coerentes com a operação.
- Aceitações, rejeições, adiamentos, expirações e mensagens encaminhadas para revisão.
- Resultados discriminados por destino e classe, com definições consistentes.
- Alertas associados a limiares operacionais próprios, revistos com dados reais.
Perguntas frequentes
A aceitação de uma mensagem pelo sistema seguinte significa que foi entregue?
Não. Indica que o sistema seguinte aceitou a mensagem, segundo a resposta observada. Por si só, não prova que o telefone a tenha recebido. Os relatórios de entrega também devem ser interpretados de acordo com a sua origem e o nível de verificação.
Qual deve ser o tamanho máximo de uma fila de saída?
Não existe um valor universal aplicável a todas as plataformas. O limite depende dos recursos, destinos, classes de tráfego, acordos e comportamento observado. Defina-o com base em dados operacionais e estabeleça uma ação explícita para quando for atingido.
É aconselhável voltar a tentar qualquer mensagem rejeitada?
Não. Primeiro, identifique se a causa é temporária, corrigível ou permanente, recorrendo à resposta e à documentação da interface ligada. Limite as novas tentativas, evite que o emissor e a plataforma repitam o envio sem coordenação e não volte a tentar automaticamente conteúdo expirado.
Deve utilizar-se sempre FIFO?
FIFO é razoável quando preservar a ordem é importante e as mensagens têm requisitos semelhantes. Se forem necessárias prioridades, defina classes e regras explícitas e verifique se uma classe não deixa outra à espera indefinidamente.
Fontes consultadas
- SMPP v3.4, Issue 1.2SMPP Developers Forum
- HTTP Semantics (RFC 9110)IETF
- 3GPP specifications by series3GPP
- ITU-T Recommendation E.164International Telecommunication Union
- GSMA networks resourcesGSMA