Skip to main content
Un message peut traverser le gateway de quatre façons. Ce sont vraiment des chemins de code différents et ils échouent différemment, donc pouvoir piloter chacun seul est ce qui transforme « quelque chose ne va pas » en une bissection.

​
Mettre en place une voie

Cela crée un compte avec du crédit, un produit avec whitelisting désactivé, un login SMPP et un login HTTP, un tarif plat, et les règles de routage dont les quatre directions ont besoin. C’est idempotent, et un script de démantèlement correspondant retire exactement ce qu’il a ajouté.
Changez les deux mots de passe avant de pointer quoi que ce soit dessus qui ne soit pas votre propre machine.

​
Lisez l’ordre de correspondance avant d’envoyer quoi que ce soit

Le routeur prend la première règle qui correspond, et la dernière règle correspond à tout. Deux choses en découlent, et les deux ont déjà mordu un déploiement réel :
Un accusé de livraison pour un message dont l’expéditeur était une adresse indienne numérique arrive avec ce numéro dans to, une fois que flag.reverseDlrSrcDst a échangé source et destination.Placé sous une règle to matches ^91…, cet accusé va à un vendeur au lieu du client.C’est pourquoi le seed déplace les règles de destination vers le bas plutôt que de simplement insérer une règle de classe au-dessus du catch-all.
Il tombe sur le catch-all, atteint le worker vendeur, et est soumis en amont comme un nouveau message sortant.conf/routingTable.conf a toujours porté cette règle. La base non. Et en mode base la base gagne.
Les deux échecs sont silencieux du côté du client : dans le premier l’accusé n’arrive simplement jamais, dans le second il arrive chez un opérateur comme du trafic que vous payez. Ni l’un ni l’autre ne produit une erreur quelque part.

​
Ce que chaque direction prouve

1

Direction 1 d'abord, MT out sur SMPP

Si celle-ci échoue, rien d’autre ne fonctionnera. Elle couvre le chemin le plus long.
2

Direction 2, l'ingress REST

Échouer ici pendant que 1 fonctionne isole le problème à l’ingress HTTP : auth, parsing, limites de débit.
3

Direction 3, accusés retour

Celle le plus souvent cassée par l’ordre de routage plutôt que par le chemin d’accusé lui-même.
4

Direction 4, MO in

Nécessite le numéro de destination mappé à un compte. Un message non mappé est enregistré et livré nulle part, sans rien d’observable du côté du client.

​
Lire le résultat

Ne jugez pas une voie par le fait que l’envoi a renvoyé 200. Cela signifie seulement accepté pour routage. Vérifiez :
  • cdr_submit pour une ligne, et cdr_final pour un résultat
  • cdr_rejected pour tout refus, avec sa raison
  • /ops/health pour submitted qui bouge sur le vendeur
  • Le log pour message.accepted, message.submitted, message.dlr

​
Connexes

Débit

Une baseline mesurée pour comparer un run de charge contre.

Premiers contrôles

Quand une voie ne fonctionne pas.