Conectar por SMPP e HTTP
Levar uma rota de teste à produção sem quebrar binds, janelas ou recibos: estado do bind, taxa, keep-alive, codificação, callbacks e falhas.
Uma conexão de mensageria em produção é um contrato operacional, não apenas um endpoint. O SMPP adiciona estado de bind, uma janela de taxa, tráfego de keep-alive e recibos na sessão. O HTTP adiciona autenticação por requisição e callbacks. O guia converte os dois em uma sequência do teste à produção.
Nesta página
O estado do bind é a primeira coisa a dominar
Um bind é uma sessão com uma direção declarada. Um transmissor envia, um receptor aceita mensagens recebidas e recibos, e um transceptor faz as duas coisas. O provedor emite credenciais para o tipo de bind que você precisa, e o cliente deve tratar o bind como estado: abrindo, vinculado, limitado, reconectando ou fechado. Um cliente que assume que o bind está sempre no ar perde mensagens na primeira queda.
Registre o estado do bind de forma explícita. Anote cada requisição e resposta de bind, a versão de interface, o system ID e o código de erro. Em uma queda, reconecte com backoff e não reenvie os envios em voo até saber se a central os aceitou. O message ID de submit_sm_resp é a única forma confiável de saber.
O bind e o primeiro envio
- Aplicação (ESME)
- bind_transceiver Abrir a sessão
- SMSC
- submit_sm_resp Aceito para entrega
- Recibo de entrega
Descrição em texto
O cliente envia uma requisição de bind e recebe uma resposta. Envia uma mensagem com submit_sm e recebe submit_sm_resp com um message ID. Mais tarde a central envia uma PDU deliver_sm com o recibo, e o cliente responde com deliver_sm_resp. Um unbind fecha a sessão.
Janela, heartbeat e codificação
A janela é o número de requisições em voo que a central aceita em um bind. Mantenha o contador abaixo dela e deixe a janela esvaziar antes de uma rajada. Um envio limitado é um sinal para reduzir o ritmo; tentar de novo no mesmo ritmo enche a fila e converte uma mensagem lenta em um congestionamento. Dimensione o número de binds pela taxa de pico, não pela média mensal.
As trocas de keep-alive dizem aos dois lados que a sessão está viva. Envie enquire_link em uma cadência e feche uma sessão que para de responder. Para a codificação, envie GSM-7 quando o conteúdo permitir e UCS-2 caso contrário. Um único caractere fora do conjunto GSM-7 muda a mensagem inteira para UCS-2 e pode mudar o número de segmentos. Teste o modelo exato, incluindo os valores das variáveis.
Recibos de entrega
Um recibo chega de forma assíncrona como uma PDU deliver_sm. Carrega o message ID original, um estado como entregue, expirado, não entregue ou desconhecido, e muitas vezes um código de rede. Pareie por message ID e guarde o estado com o registro da mensagem. Não pareie por ordem de chegada e não trate um recibo ausente como uma mensagem que falhou.
Os formatos de recibo diferem. Centrais novas usam um campo tag-length-value message_state; as antigas colocam texto chave-valor no campo da mensagem curta. Analise os dois. Normalize os estados que a sua aplicação precisa e guarde o código bruto, para que um caso de suporte possa ser rastreado até o que a rede disse.
Modos de falha e primeira resposta
| Sintoma | Causa provável | Primeira checagem |
|---|---|---|
| Bind recusado | Credenciais, tipo de bind ou versão de interface errados | Leia o código de resposta do bind e a versão de interface |
| Timeouts subindo | Janela excedida ou rota lenta | Verifique as requisições em voo e os códigos de resposta antes de repetir |
| Bind aberto, sem respostas | A sessão está morta ou o cliente parou o keep-alive | Envie enquire_link e reconecte com backoff |
| Recibo ausente | O recibo nunca chegou ao handler | Verifique o log da sessão e o message ID antes de reenviar |
| Caracteres errados | Conteúdo GSM-7 enviado como UCS-2, ou o contrário | Verifique a codificação de dados e a contagem de segmentos |
| Callback com timeout | O endpoint está lento ou inacessível | Responda rápido, processe de forma assíncrona, verifique a assinatura |
A ordem da resposta importa: observe e depois mude uma variável.
Da rota de teste à produção
-
Conecte à rota de teste
Use as credenciais de teste e o tipo de bind que vai usar em produção. Confirme a resposta do bind e a versão de interface.
-
Envie os modelos reais
Teste o conteúdo que vai lançar, com links, variáveis e a mensagem mais longa. Registre a codificação e o número de segmentos.
-
Leia os recibos
Pareie cada recibo por message ID. Confirme os estados e os códigos de erro que a sua aplicação vai receber.
-
Teste o caminho de falha
Envie para um número inválido, um celular cheio e um serviço bloqueado. Confirme os estados e o tratamento da aplicação.
-
Dimensione a janela
Rode um teste na taxa de pico e confirme que as requisições em voo ficam abaixo da janela. Adicione um bind se não ficarem.
-
Ligue o monitoramento
Alerte sobre o estado do bind, a latência de envio, a latência de recibo e a mistura de estados. Nomeie a pessoa que age em cada alerta.
-
Mude o tráfego de produção
Mova primeiro uma parcela pequena, compare os recibos com o teste e aumente. Mantenha a rota de teste como alternativa.
Autenticação HTTP e callbacks
Uma integração HTTP autentica cada requisição com a chave emitida no onboarding. Rotacione a chave antes de ela expirar e mantenha a anterior válida durante a sobreposição. Um envio devolve uma resposta aceita com um message ID; o recibo e qualquer mensagem recebida chegam à sua URL de callback.
O endpoint de callback deve verificar a assinatura, responder rápido e processar o evento depois da resposta. Um endpoint lento provoca retentativas, e retentativas provocam duplicados se o handler não for idempotente. Mantenha o endpoint acessível através de mudanças de certificado e DNS, e alerte quando a taxa de falhas do callback subir. A explicação de SMPP cobre a sessão; a comparação de transportes cobre a escolha.
Perguntas frequentes
Qual versão de SMPP devemos usar?
Quantos binds precisamos?
O callback deve responder antes de processar?
E se um recibo nunca chegar?
Como testamos uma falha?
Relacionado
- Manual global de Sender ID para A2P
Como os Sender IDs funcionam nos mercados: caminhos alfanuméricos, numéricos e de código curto, expectativas de registro e exemplos de países.
- A2P SMS
SMS aplicação-pessoa: o tráfego que uma aplicação envia ao aparelho de uma pessoa, como um código de verificação ou um alerta de transação.
- DLR
Um recibo de entrega informa o status que a rede móvel atribui a um SMS enviado: entregue, expirado, rejeitado ou desconhecido, entre outros.
Adjacente ao que oferecemos
Explicamos isto aqui porque afeta o uso do nosso serviço.