Skip to main content
C’est le côté opérateur. Si vous êtes un client changeant votre intégration, lisez Migrer depuis Jasmin à la place.

​
Depuis Jasmin

L’API est assez proche pour que la plupart des clients changent une ligne. Votre travail est surtout de la configuration et une réconciliation. Les changements visibles pour le client sont sur leur page. Ce qui compte pour vous :
Les messages sont maintenant facturés à l’accountId du login, pas à son nom de login.Auparavant HTTP facturait au nom d’utilisateur alors que SMPP facturait à accountId. Donc un client apparaissait comme deux identités selon la façon dont il se connectait. accountId est à la fois la portée de tarification et la clé de crédit prépayé, donc les deux devaient être réconciliés avant que le crédit puisse fonctionner sur HTTP du tout.
Vérifiez votre table de tarifs avant de basculer. Si rates.conf a un [scope] nommé d’après un nom d’utilisateur HTTP, renommez-le en l’accountId de ce login. Sinon ces messages cessent de correspondre et deviennent sans tarif, ce qui signifie envoyés et facturés rien plutôt que refusés.

​
Depuis Kannel

GET /sendsms a été supprimé. Il n’y a pas de couche de compatibilité.
L’échelle coding a changé, et elle échoue silencieusement. C’est maintenant le champ data_coding SMPP.Un client envoyant coding=2 pour UCS-2 obtient maintenant un alphabet d’octet non spécifié. Rien n’erreur. Le message sort mal encodé. UCS-2 est 8.Balayez les intégrations de vos clients pour coding=2 avant la bascule, parce que ni un côté ni l’autre ne remarquera jusqu’à ce qu’un destinataire signale du mojibake.
Les accusés de réception ont changé aussi. FireFlo POSTe un corps JSON par défaut, donc un handler DLR Kannel s’attendant à %d/%s substitués dans un GET cesse de fonctionner. Réglez smsg.dlr.forward.format = kannel pour garder l’ancien comportement pendant que les clients migrent.

​
Le changement de facturation qui altère les factures

La facturation est d’une unité par requête REST, quel que soit le nombre de segments que le corps occupe.
C’est moins cher que le même message sur SMPP, où chaque PDU entrant est facturé. Un client qui passe de SMPP à REST obtient une facture plus basse pour un trafic identique, et un qui passe dans l’autre sens en obtient une plus haute.Réglez smsg.restapi.billing.units=segment pour les tarifer pareil. Décidez ceci avant la bascule. Le changer après ressemble à une hausse de prix.

​
Un ordre de bascule qui fonctionne

1

Réconcilier les portées de tarif à accountId

Avant que quoi que ce soit ne bouge. Une portée non correspondante signifie du trafic sans tarif, ce qui est silencieux.
2

Décider l'unité de facturation REST

Requête ou segment. C’est une décision de tarification, pas une technique.
3

Régler le format d'accusé attendu par les clients

kannel s’ils ont des handlers Kannel, pour que leur côté continue de fonctionner pendant qu’ils migrent.
4

Lancer le whitelisting en report-only pour une période

whitelist_would_reject vous dit ce que l’application refuserait avant qu’elle refuse quoi que ce soit.
5

Déplacer une petite part de trafic en premier

Comparez les taux de livraison en sachant que FireFlo rapporte le pire segment d’un long message, donc ses chiffres sont légitimement inférieurs à un gateway rapportant le premier.

​
Connexes

Avis clients

Ce qu’il faut dire aux clients, et comment trouver qui est affecté.

Le côté du client

Ce que leur intégration doit changer.