Rechargé à chaud — les éditions s’appliquent en 200 ms environ sans redémarrage.
Une règle est en quatre parties séparées par deux-points
Target est une instance de worker (vendor1, smppserver.smpp), un groupe, ou une autre
table sur laquelle enchaîner (MESSAGE).
Les règles sont évaluées de haut en bas au sein d’une table, et la première correspondance
l’emporte.
Une règle mal formée fait échouer tout le rechargement et la table précédente est conservée.
Vérifiez le log pour Error parsing new routing table après édition — la passerelle continue de
fonctionner sur l’ancienne table, donc rien ne paraît anormal jusqu’à ce que vous vous demandiez
pourquoi votre changement n’a rien fait.
Les deux erreurs dont le parseur ne vous sauvera pas
== est un opérateur numérique. Utilisez equals pour les chaînes :
matches est ancrée, startsWith est littéral. ^61.* correspond à un numéro entier ; un
simple 61 non. Et startsWith compare du texte littéral — une expression régulière qu’on lui
passe ne correspond à rien, silencieusement.
Une table minimale
L’attrape-tout se met à la fin. Au-dessus des autres règles, il rend tout ce qui le suit
inaccessible, et rien ne vous avertit — les règles parsent bien, elles ne s’exécutent tout
simplement jamais.
product vient du system_type sur le bind SMPP du client, retombant sur le product du
credential. Les appelants HTTP utilisent toujours la valeur du credential.
Groupes de fournisseurs
Un groupe est un autre nom vers lequel une règle peut envoyer. Au lieu de nommer un fournisseur, la
règle nomme un groupe et le groupe choisit un membre — en sautant tout membre suspendu ou
n’acceptant pas, ce qui est le failover qu’une règle à cible unique ne peut pas faire.
Les blocs de groupe doivent venir avant le premier en-tête [table]. À l’intérieur d’un bloc de
table, une ligne de membre ne correspond à rien et est ignorée silencieusement.Un poids n’est lu que par weighted. En définir un sur les deux autres ne change rien, et la
passerelle le dit en WARN plutôt que de vous laisser croire qu’un partage se produit.
Tables de routage au moindre coût
Une table marquée ->function(LCR) se comporte différemment : au lieu de s’arrêter à la première
règle qui correspond, toutes les règles qui correspondent sont des candidats et le fournisseur
avec le tarif le moins cher dans rates.conf gagne.
L’ordre des règles est donc sans importance dans une table LCR — les règles sont des alternatives,
pas une chaîne de repli.
- Les fournisseurs en panne ou n’acceptant pas sont ignorés, donc le suivant le moins cher porte le
trafic.
- Un fournisseur sans tarif correspondant n’est utilisé que si rien d’autre ne correspond, donc
une ligne de tarif manquante dégrade plutôt qu’elle ne bloque.
- Les règles qui pointent vers une autre table sont ignorées à l’intérieur d’une table LCR.
Voir Routage au moindre coût.
Filtres
Une règle peut référencer un filtre nommé de la bibliothèque de filtres au lieu d’écrire ses
conditions en ligne.
Un filtre manquant ou désactivé saute chaque règle qui le référence, plutôt que de charger la
règle avec moins de conditions. Retirer une condition rendrait la règle correspondante à plus de
trafic, donc échouer ainsi serait silencieux et router les mauvaises choses.C’est pourquoi désactiver un filtre peut faire correspondre une règle à moins de trafic, et
pourquoi le correctif n’est jamais « simplement retirer la condition ».
app_route_table, app_route_rule et leurs tables de condition. Voir
Base de données. 