Se connecter en SMPP et en HTTP
Passer d’une route de test à la production sans casser les binds, les fenêtres ni les accusés : débit, keep-alive, codage, callbacks et pannes.
Une connexion de messagerie en production est un contrat d’exploitation, pas seulement un endpoint. SMPP ajoute l’état du bind, une fenêtre de débit, du trafic keep-alive et des accusés sur la session. HTTP ajoute une authentification par requête et des callbacks. Le guide transforme les deux en une séquence du test à la production.
Sur cette page
L’état du bind est la première chose à maîtriser
Un bind est une session avec une direction déclarée. Un émetteur envoie, un récepteur accepte les messages entrants et les accusés, et un émetteur-récepteur fait les deux. Le fournisseur émet des identifiants pour le type de bind dont vous avez besoin, et le client doit traiter le bind comme un état : ouverture, lié, limité, reconnexion ou fermé. Un client qui suppose que le bind est toujours debout perdra des messages à la première coupure.
Suivez l’état du bind explicitement. Journalisez chaque requête et réponse de bind, la version d’interface, le system ID et le code d’erreur. En cas de coupure, reconnectez avec backoff et ne rejouez pas les envois en cours avant de savoir si le centre les a acceptés. Le message ID de submit_sm_resp est le seul moyen fiable de le savoir.
Le bind et le premier envoi
- Application (ESME)
- bind_transceiver Ouvrir la session
- SMSC
- submit_sm_resp Accepté pour remise
- Accusé de remise
Description textuelle
Le client envoie une requête de bind et reçoit une réponse. Il envoie un message avec submit_sm et reçoit submit_sm_resp avec un message ID. Plus tard, le centre envoie une PDU deliver_sm avec l’accusé, et le client répond avec deliver_sm_resp. Un unbind ferme la session.
Fenêtre, heartbeat et codage
La fenêtre est le nombre de requêtes en cours que le centre accepte sur un bind. Gardez le compteur en dessous et laissez la fenêtre se vider avant une rafale. Un envoi limité est un signal pour ralentir ; réessayer au même rythme remplit la file et transforme un message lent en embouteillage. Dimensionnez le nombre de binds à partir du débit de pointe, pas de la moyenne mensuelle.
Les échanges de keep-alive disent aux deux extrémités que la session est vivante. Envoyez enquire_link à une cadence régulière et fermez une session qui cesse de répondre. Pour le codage, envoyez GSM-7 quand le contenu le permet et UCS-2 sinon. Un seul caractère hors du jeu GSM-7 fait passer tout le message en UCS-2 et peut changer le nombre de segments. Testez le modèle exact, valeurs de variables comprises.
Accusés de remise
Un accusé arrive de façon asynchrone sous forme de PDU deliver_sm. Il porte le message ID d’origine, un état comme remis, expiré, non remis ou inconnu, et souvent un code réseau. Rapprochez-le par message ID et conservez l’état avec l’enregistrement du message. Ne rapprochez pas par ordre d’arrivée et ne traitez pas un accusé absent comme un message en échec.
Les formats d’accusé diffèrent. Les centres récents utilisent un champ étiquette-longueur-valeur message_state ; les anciens placent un texte clé-valeur dans le champ du message court. Analysez les deux. Normalisez les états dont votre application a besoin et conservez le code brut, pour qu’un dossier de support puisse remonter à ce que le réseau a dit.
Modes de défaillance et première réponse
| Symptôme | Cause probable | Premier contrôle |
|---|---|---|
| Bind refusé | Identifiants, type de bind ou version d’interface erronés | Lisez le code de réponse du bind et la version d’interface |
| Timeouts en hausse | Fenêtre dépassée ou route lente | Vérifiez les requêtes en cours et les codes de réponse avant de réessayer |
| Bind ouvert, sans réponse | La session est morte ou le client a cessé le keep-alive | Envoyez enquire_link, puis reconnectez avec backoff |
| Accusé absent | L’accusé n’a jamais atteint le gestionnaire | Vérifiez le journal de session et le message ID avant de renvoyer |
| Caractères erronés | Contenu GSM-7 envoyé en UCS-2, ou l’inverse | Vérifiez le codage des données et le nombre de segments |
| Callback en timeout | L’endpoint est lent ou injoignable | Répondez vite, traitez en asynchrone, vérifiez la signature |
L’ordre de la réponse compte : observez, puis changez une variable.
De la route de test à la production
-
Connectez la route de test
Utilisez les identifiants de test et le type de bind que vous aurez en production. Confirmez la réponse du bind et la version d’interface.
-
Envoyez les modèles réels
Testez le contenu que vous allez lancer, avec les liens, les variables et le message le plus long. Notez le codage et le nombre de segments.
-
Lisez les accusés
Rapprochez chaque accusé par message ID. Confirmez les états et les codes d’erreur que votre application recevra.
-
Testez le chemin de panne
Envoyez vers un numéro invalide, un téléphone plein et un service bloqué. Confirmez les états et le traitement de l’application.
-
Dimensionnez la fenêtre
Lancez un test au débit de pointe et confirmez que les requêtes en cours restent sous la fenêtre. Ajoutez un bind sinon.
-
Activez la supervision
Alertez sur l’état du bind, la latence d’envoi, la latence d’accusé et la répartition des états. Nommez la personne qui agit sur chaque alerte.
-
Basculez le trafic de production
Déplacez d’abord une petite part, comparez les accusés au test, puis augmentez. Gardez la route de test comme repli.
Authentification HTTP et callbacks
Une intégration HTTP authentifie chaque requête avec la clé émise à l’onboarding. Faites tourner la clé avant expiration et gardez l’ancienne valide pendant le chevauchement. Un envoi renvoie une réponse acceptée avec un message ID ; l’accusé et tout message entrant arrivent sur votre URL de callback.
L’endpoint de callback doit vérifier la signature, répondre vite et traiter l’événement après la réponse. Un endpoint lent provoque des reprises, et les reprises créent des doublons si le gestionnaire n’est pas idempotent. Gardez l’endpoint joignable à travers les changements de certificat et de DNS, et alertez quand le taux d’échec du callback monte. L’explication de SMPP couvre la session ; la comparaison des transports couvre le choix.
Questions fréquentes
Quelle version de SMPP utiliser ?
Combien de binds faut-il ?
Le callback doit-il répondre avant de traiter ?
Et si un accusé n’arrive jamais ?
Comment tester une panne ?
Voir aussi
- Guide des ID expéditeur A2P dans le monde
Comment fonctionnent les ID expéditeur selon les marchés : alphanumérique, numérique, code court, enregistrement et exemples par pays.
- A2P SMS
SMS A2P : le trafic qu’une application envoie vers un téléphone (code de vérification, alerte de transaction), via une route à expéditeur enregistré.
- DLR
Un accusé de remise indique le statut qu’un réseau mobile renvoie pour un SMS envoyé : remis, expiré, rejeté ou inconnu, entre autres.
Proche de ce que nous proposons
Nous l’expliquons ici car cela influe sur l’usage de notre service.