Skip to main content
Une base migrée est vide, et une base vide ne démarre pas. C’est le chemin le plus court de là à un message qui sort.

​
bootstrap

Écrit le minimum dont une base fraîche a besoin :
  • une table de routage default
  • une table MESSAGE vide pour qu’un vendeur y aille
  • un listener sur 27777
  • un login SMPP, dont il génère le mot de passe et l’affiche une seule fois
Le mot de passe généré est affiché une seule fois et jamais plus. Capturez-le avant de fermer le terminal.

​
Ce qu’il n’écrit délibérément pas

Les deux absences sont nommées dans sa sortie de fin, donc il ne les omet pas simplement en silence.
bootstrap refuse dès qu’il trouve une table de routage, un worker ou un login, il ne peut donc pas écraser un déploiement en cours. Il n’y a pas de drapeau qui le force.Pour importer une configuration fichier existante à la place, utilisez import.

​
Puis, dans cet ordre

L’ordre compte : chaque étape est ce qui rend la suivante significative.
1

Un produit

Un tarif nommé sous lequel un message est tarifé. Sans lui, la tarification n’a rien sur quoi s’aligner et une règle de tarif à portée de produit ne peut jamais correspondre.
2

Un tarif pour ce produit

Les deux côtés : ce que vous payez à un vendeur (coût) et ce qu’un compte vous paye (prix). Un message ne correspondant à aucune règle côté vente est enregistré UNKNOWN, pas gratuit. Livré et facturé à personne. Voir rates.conf.
3

Un vendeur

Hôte, port, system id, mot de passe, et les comptes de binds. Rien ne quitte le bâtiment tant qu’il n’en existe pas un. Voir Vendeurs.
4

Une règle de routage qui le nomme

bootstrap laisse [MESSAGE] vide exprès. Un catch-all envoyant tout à votre seul vendeur est le minimum :
5

Un login client

Un id de compte, un produit, et soit un systemId/password SMPP soit une paire HTTP. Le compte est la clé de facturation. Voir credentials.yml.
6

Du crédit, si vous l'appliquez

Avec smsg.balance.enabled activé, un compte sans ligne de solde n’envoie rien. Le crédit entre par la base sous forme d’entrée de grand livre. Le panel écrit des lignes RECHARGE et jamais la colonne solde directement.

​
Vérifiez-le avant d’y croire

Sortie 4 est la réponse attendue à mi-chemin de cette liste : le déploiement est sain, ses propres données ne le sont pas. Rien à router encore. Cela devient 0 une fois qu’un vendeur et une règle existent.
Puis envoyez-en un, comme un client le ferait :
Un 200 signifie accepté, facturé et mis en file. Pas livré. Surveillez l’enregistrement d’appel pour le résultat.

​
Les deux choses les plus susceptibles d’être fausses

Aucune règle de tarif côté vente n’a correspondu. L’enregistrement d’appel montre le message sans tarif. Soit le compte n’a pas de portée de tarif, soit chaque règle dans sa portée porte un produit que le message n’a pas. Un message sans produit ne voit jamais que les règles sans produit.
Soit [MESSAGE] est encore vide, soit le catch-all est au-dessus de vos règles spécifiques et elles sont inaccessibles, soit le vendeur n’est pas bindé. scripts/fireflo health distingue les trois.