Hot reload. Edições aplicam em cerca de 200 ms sem restart.
Uma regra tem quatro partes separadas por dois pontos
Target é uma instância de worker (vendor1, smppserver.smpp), um grupo, ou outra tabela para
encadear (MESSAGE).
Regras são avaliadas de cima para baixo dentro de uma tabela, e o primeiro match vence.
Uma regra malformada faz o reload inteiro falhar e a tabela anterior é mantida. Cheque o log por
Error parsing new routing table depois de editar. O gateway continua funcionando na tabela antiga,
então nada parece errado até você se perguntar por que sua mudança não fez nada.
Os dois erros que o parser não vai salvar você
== é um operador numérico. Use equals para strings:
matches é ancorado, startsWith é literal. ^61.* casa com um número inteiro; um 61 puro
não. E startsWith compara texto literal. Uma expressão regular passada para ele não casa com nada,
em silêncio.
Uma tabela mínima
O catch-all vai no fim. Acima de outras regras ele torna tudo abaixo inalcançável, e nada avisa
você. As regras parseiam bem, simplesmente nunca rodam.
product vem do system_type no bind SMPP do cliente, caindo de volta para o product da
credencial. Chamadores HTTP sempre usam o valor da credencial.
Grupos de fornecedor
Um grupo é outro nome para o qual uma regra pode enviar. Em vez de nomear um fornecedor, a regra
nomeia um grupo e o grupo escolhe um membro. Pulando qualquer um que esteja suspenso ou não
aceitando. Que é o failover que uma regra de alvo único não faz.
Blocos de grupo precisam vir antes do primeiro cabeçalho [table]. Dentro de um bloco de tabela
uma linha de membro não casa com nada e é descartada em silêncio.Um peso é lido só por weighted. Definir um nos outros dois não muda nada, e o gateway diz isso em
WARN em vez de deixar você acreditar que uma divisão está acontecendo.
Tabelas least-cost routing
Uma tabela marcada ->function(LCR) se comporta diferente: em vez de parar na primeira regra que
casa, toda regra que casa é candidata e o fornecedor com a tarifa mais barata em rates.conf
vence.
Ordem de regra é portanto irrelevante em uma tabela LCR. As regras são alternativas, não uma cadeia
de fallback.
- Fornecedores que estão down ou não aceitando são pulados, então o próximo mais barato carrega o
tráfego.
- Um fornecedor com nenhuma tarifa que case é usado só se nada mais casar, então uma linha de
tarifa ausente degrada em vez de bloquear.
- Regras apontando para outra tabela são ignoradas dentro de uma tabela LCR.
Veja Least-cost routing.
Filtros
Uma regra pode referenciar um filtro nomeado da biblioteca de filtros em vez de soletrar as condições
inline.
Um filtro ausente ou desabilitado pula toda regra que o referencia, em vez de carregar a regra
com menos condições. Descartar uma condição faria a regra casar com mais tráfego, então falhar
dessa forma seria silencioso e rotearia as coisas erradas.É por isso que desabilitar um filtro pode fazer uma regra parecer casar com menos, e por que a
correção nunca é “só remover a condição”.
app_route_table, app_route_rule e suas tabelas de condição. Veja
Banco de dados. 