Protocole et paramètres du connecteur SMS sms-connector-protocol

Dans le cadre de la transition de Campaign v7 vers v8, la documentation de Campaign Classic a été rationalisé et réorganisé. Les fonctionnalités communes sont désormais disponibles exclusivement dans le jeu de documentation de Campaign v8. Pour en savoir plus sur les paramètres du connecteur SMS, consultez la documentation de Campaign v8.

Vue d’ensemble overview

Les SMS peuvent se limiter à envoyer des SMS courts sans formatage, mais leur simplicité en fait un canal de communication précieux.

Il existe deux façons principales d’envoyer un SMS :

Ce document vous guide tout au long de la configuration de la connexion entre Adobe Campaign et un fournisseur SMPP.

Les fournisseurs SMPP peuvent parfois s’écarter des spécifications officielles, mais le connecteur SMS d’Adobe Campaign offre de nombreuses options pour adapter son comportement pour qu’il soit compatible avec la plupart des fournisseurs.

Protocole SMPP smpp-protocol

Adobe Campaign Classic prend en charge le protocole SMPP version 3.4. Il s’agit d’un protocole répandu qui permet d’envoyer des SMS à un fournisseur (SMSC) et de recevoir des SMS ainsi que des accusés de réception. Consultez à ce sujet la documentation SMPP.

L’équipement réseau côté fournisseur SMS est souvent appelé SMSC.

Connexions SMPP smpp-connections

Adobe Campaign se connecte à l’équipement réseau du fournisseur SMS via TCP. Le protocole SMPP définit des connexions TCP permanentes d’Adobe Campaign au fournisseur. Les connexions TCP sont toujours initiées par Adobe Campaign, même pour recevoir des messages.
SMPP ouvre 1 ou 2 connexions TCP, selon son mode. Toutes les connexions sont toujours initiées par Adobe Campaign.

Le protocole SMPP peut fonctionner en deux modes :

PDU SMPP smpp-pdu

Les unités de transmission SMPP (“paquets”) sont appelées PDU. Un PDU contient une commande, un statut, un numéro de séquence et des données.

Chaque PDU doit être acquitté par une SMPP RESP PDU (réponse synchrone). Les requêtes peuvent être acheminées : l’expéditeur peut envoyer de nombreuses commandes sans attendre RESP, le nombre de requêtes pouvant être acheminé par pipeline à tout moment est appelé la fenêtre. RESP PDU peut arriver dans n’importe quel ordre, sans rapport avec l’ordre de leur PDU initiateur correspondant.

Dans le mode séparé Transmitter + receiver, la connexion utilisée dépend du type de message transmis. La connexion de l’émetteur est utilisée pour les MT, et la connexion du récepteur est utilisée pour les MO et SR. Les requêtes et réponses pour chaque type de message sont envoyées via la même connexion TCP.

Par exemple, lors de l’envoi d’un MT, la connexion de l’émetteur est utilisée et le RESP qui acquitte le MT est également envoyé par l’intermédiaire du canal de l’émetteur. Lorsque vous recevez un MO (ou un SR), la connexion du récepteur est utilisée pour recevoir le MO et pour envoyer le RESP qui acquitte le MO.

Dans Adobe Campaign Classic, pour lier un SR à son MT correspondant, un identifiant est renvoyé par le SMSC avec les étapes SUBMIT_SM_RESP et DELIVER_SM. L’identifiant est stocké dans le champ providerId de la table nms::providerMsgId et est lié à broadLogId et deliveryId. Cette opération de correspondance est effectuée par le processus SMS lors de l’écriture dans la base de données.

Un SUBMIT_SM_RESP PDU réussi déclenche le statut du message “envoyé” dans le log d’envoi tandis qu’un DELIVER_SM (SR) PDU réussi déclenche le statut du message “reçu”.

Aspects liés à la sécurité security-aspects

Le protocole proprement dit n’est pas chiffré. La plupart des fournisseurs mettent en œuvre une variante d’IP sur la liste autorisée, de sorte que les adresses IP du serveur Adobe Campaign doivent être déclarées au fournisseur.

Adobe Campaign prend en charge la transmission d’un nom d’utilisateur et d’un mot de passe lors de la phase de liaison. Il prend également en charge le SMPP plutôt que le TLS. Il convient de noter que des certificats sont requis pour assurer une sécurité adéquate. Bien que le connecteur SMPP permette de contourner les vérifications de certificats, il ne doit être utilisé que pour les tests, car un TLS sans certificat offre un niveau de sécurité nettement inférieur.

Le connecteur utilise les certificats par défaut fournis par la bibliothèque système openssl. En général, il est fourni par le répertoire /etc/ssl/certs sur Debian. Ce répertoire est fourni par le package “ca-certificates” par défaut, mais il peut être personnalisé.

Informations sur chaque type de PDU information-pdu

Chaque type de PDU possède des champs distincts qui portent des éléments d’information différents. Ces PDU sont détaillés dans la spécification SMPP 3.4.

Chaque section ci-dessous décrit le PDU et sa réponse synchrone (*_RESP PDU). Tous les PDU doivent être acquittés par un RESP correspondant, c’est une partie obligatoire de la spécification.

Les PDU peuvent comporter des champs facultatifs. Seuls les champs les plus courants sont décrits ici. Pour plus d’informations, consultez la spécification SMPP 3.4.

BIND_TRANSMITTER / BIND_RECEIVER / BIND_TRANSCEIVER

Ce PDU est utilisé pour initier une connexion avec le SMSC. Les modes Transmitter, Receiver et Transceiver ne modifient que le type de SMS autorisé à être transféré sur ce lien, en particulier :

Champs visibles dans un BIND_* PDU :

BIND_*_RESP n’a pas de champ spécifique, il confirme si la connexion a réussi ou non.

UNBIND unbind

Ce PDU doit être envoyé par le système avant de se déconnecter. Il doit attendre le PDU UNBIND_RESP correspondant avant de fermer la connexion.

La conformité SMSC ne doit pas fermer la connexion, la connexion TCP est contrôlée par le connecteur Adobe Campaign.

SUBMIT_SM submit-sm

Ce PDU envoie un MT au SMSC. Sa réponse PDU donne l’ID du MT.

Champs visibles dans un PDUSUBMIT_SM :

Adobe Campaign prend en charge les champs facultatifs suivants :

SUBMIT_SM_RESP submit-sm-resp

Ce PDU contient l’ID du MT. Ceci est utile pour établir une correspondance avec le SR entrant.

Certains fournisseurs envoient SUBMIT_SM_RESP après l’envoi du SR. Pour tenir compte de ce comportement, Adobe Campaign attend 30 secondes avant de répondre Identifiant du message non valide à un SR avec un ID inconnu.

DELIVER_SM delivery-sm

Ce PDU est envoyé par le SMSC à Adobe Campaign. Il contient un MO ou un SR.

La plupart des champs ont la même signification que leur contrepartie SUBMIT_SM. Voici la liste des champs utiles :

Adobe Campaign peut lire l’identifiant du message dans le champ facultatif receipted_message_id avec un ajustement de la configuration.

DELIVER_SM_RESP deliver-sm-resp

Ce PDU est envoyé par Adobe Campaign pour acquitter SR et MO.

Adobe Campaign Classic reconnaît SR et MO une fois qu’ils ont été insérés dans la base de données. Certaines erreurs de traitement peuvent se produire même si un PDU DELIVER_SM_RESP réussi a été envoyé. Cette limite est due à l’architecture logicielle d’Adobe Campaign Classic.

ENQUIRE_LINK enquire-links

Ce PDU n’est utilisé que pour vérifier que la connexion est active. Sa fréquence doit être définie en fonction des besoins du fournisseur.

Les 60 secondes par défaut doivent correspondre à la plupart des configurations définies dans le compte externe.

ENQUIRE_LINK_RESP enquire-links-resp

Ce PDU acquitte le fait que la connexion est active.

SMS en plusieurs parties (SMS long) multipart

Limitation du débit et fenêtrage throughput-capping

La plupart des fournisseurs exigent une limite de débit pour chaque connexion SMPP. Pour ce faire, il est possible d’établir un certain nombre de SMS dans le compte externe. Notez que le ralentissement du débit se produit par connexion, le débit effectif total est la limite par connexion multipliée par le nombre total de connexions. Ceci est détaillé dans la section Connexions simultanées.

Pour atteindre le débit maximal possible, vous devez affiner la fenêtre d’émission maximale. La fenêtre d’émission est le nombre de SUBMIT_SM PDU qui peuvent être envoyés sans attendre un SUBMIT_SM_RESP. Pour plus d’informations, consultez la section Paramètres de la fenêtre d’envoi (documentation de Campaign v8).

Gestion des SR et des erreurs (“Annexe B”) sr-error-management

Le protocole SMPP définit des erreurs synchrones standard dans RESP PDU, mais il ne définit pas de codes d’erreur pour SR. Chaque fournisseur utilise ses propres codes d’erreur avec leur signification.

Une recommandation est faite dans la section de l’Annexe B de la spécification du protocole SMPP (page 167), mais sans indiquer les codes d’erreur réels ni leur signification.

Pour s’adapter à la gestion des erreurs, le système de messagerie broadlog d’Adobe Campaign a été exploité pour indiquer correctement les erreurs et leur sévérité (hard, soft, etc.).

Comme mentionné ci-dessus, il existe deux types d’erreurs :

Lorsqu’un SR est reçu, le statut et l’erreur se trouvent dans son champ short_message (exemple pour les mises en œuvre conformes à l’Annexe B). Le champ short_message du PDU est souvent appelé le champ de texte, car il contient du texte en MT. En cas de SR, il contient des informations techniques ainsi qu’un sous-champ nommé Texte. Ces deux champs sont différents et short_message contiennent en fait le champ Texte et d’autres informations.

Les connecteurs Adobe Campaign Classic (à l’exception de l’option SMPP étendu) utilisent un comportement codé en dur qui dépend du fournisseur sélectionné. Le SMPP générique ne fait que distinguer la réussite de l’erreur, sans aucun détail. Le log de diffusion peut contenir certaines informations qui ne sont pas garanties.

Format de champ de texte SR sr-text-field-format

La spécification recommande d’utiliser ce format pour le champ de texte SR. Il s’agit d’une liste de sous-champs séparés dans l’espace par deux points pour séparer le nom du champ et sa valeur. Les noms de champ ne respectent jamais la casse.

Exemple d’un champ de texte SR correspondant à la recommandation de l’Annexe B :

id:1234567890 sub:001 dlvrd:001 submit date:1608011415 done date:1608011417 stat:DELIVRD err:000 Text:Hello Adobe world

Le champ id correspond à l’ID reçu dans SUBMIT_SM_RESP PDU, c’est-à-dire l’acquittement de la valeur MT.

sub et dlvrd sont censés compter la quantité de parties délivrées et de messages délivrés, mais ceci n’est pas utilisé par Adobe Campaign puisque le système broadlog donne une information meilleure et plus intégrée.

Les champs submit date et done date sont des dates et heures indicatives du moment où le MT a été envoyé et du moment où le SR a été envoyé par le mobile. Vous pouvez vous attendre à des problèmes de fuseaux horaires ou même à des dates et heures incorrectes données par les mobiles avec un jeu de dates incorrect.

Le champ “stat” est important car il indique le statut du message. Les seuls statuts importants sont DELIVRD, UNDELIV et REJECTD. Le statut DELIVRD indique une réussite, les deux autres indiquent une erreur. D’autres valeurs sont possibles, mais il s’agit généralement de notifications intermédiaires, par exemple le MT a atteint l’opérateur de téléphonie mobile, mais pas le téléphone mobile. Ces notifications intermédiaires sont ignorées par Adobe Campaign.

Le champ “err” contient le code d’erreur propre au fournisseur. Le fournisseur doit fournir un tableau des codes d’erreur possibles ainsi que leur signification pour pouvoir interpréter cette valeur.

Enfin, le champ “text” contient généralement le début du texte du MT. Adobe Campaign n’en tient pas compte et certains fournisseurs ne le transmettent pas pour éviter les fuites d’informations d’identification personnelle et la consommation de bande passante du réseau. Il peut être utilisé lors de résolution des problèmes pour repérer plus facilement le SR correspondant à un test MT en lisant ce champ.

Exemple de traitement SR dans un SMPP générique étendu Adobe Campaign Classic sr-processing

Cet exemple montre comment afficher le cas d’une mise en œuvre suivant la recommandation de l’Annexe B, les valeurs par défaut dans le compte externe et un SMS MT réussi.

id:1234567890 sub:001 dlvrd:001 submit date:1608011415 done date:1608011417 stat:DELIVRD err:000 Text:Hello Adobe world

Tout d’abord, l’expression régulière id extraction est appliquée pour extraire l’identifiant et le réconcilier avec le MT correspondant.

Ensuite, les champs expression régulière status extraction et expression régulière error code extraction sont appliqués pour extraire ces champs et sont ajoutés à la chaîne.

Le message broadlog est construit à l’aide de ces informations et la chaîne d’origine non modifiée est ajoutée à titre de référence :

SR ExampleProvider DELIVRD 000|MESSAGE=id:1234567890 sub:001 dlvrd:001 submit date:1608011415 done date:1608011417 stat:DELIVRD err:000 Text:Hello Adobe world

Le message est alors normalisé, supprimant la partie MESSAGE pour pouvoir faire correspondre plusieurs messages avec le même statut et le même code d’erreur.

SR ExampleProvider DELIVRD 000|#MESSAGE#

Si le message n’est pas déjà configuré dans le tableau des messages broadlog, une nouvelle entrée est créée, en utilisant le message entier comme firstText et le message normalisé. Ensuite, le connecteur utilise le succès et l’expression régulière error pour déterminer s’il s’agissait d’une réussite ou d’un échec :

Par défaut, toutes les erreurs sont configurées en tant qu’erreurs logicielles. Cela signifie que les erreurs hard doivent être corrigées à la main.

Paramètres de compte externe SMPP SMPP-parameters-external

Chaque mise en œuvre du protocole SMPP comporte de nombreuses variations. Pour améliorer la compatibilité et l’adaptabilité, de nombreux paramètres sont disponibles pour modifier le comportement du connecteur SMPP. Cette section décrit chaque paramètre et ses effets sur le connecteur.

Paramètres généraux et routage general-parameters-routing

Limiter les instances MTA pour ce compte

Il est possible de définir une limite au nombre d’instances MTA autorisées à se connecter au fournisseur SMPP. Si cette option est cochée, vous pouvez spécifier le nombre maximum de MTA à utiliser.

Cette option permet un contrôle plus précis du nombre de connexions, voir Connexions simultanées.

Si vous définissez une valeur supérieure au nombre de MTA en cours d’exécution, tous les MTA s’exécuteront normalement : cette option n’est qu’une limite et ne peut pas générer d’autres MTA.

Si vous devez contrôler précisément le nombre de connexions, par exemple les besoins du fournisseur, il est recommandé de toujours définir cette option même si le déploiement actuel comporte le nombre approprié de MTA en cours d’exécution. Si d’autres MTA sont ajoutés par la suite, la limite de connexion reste respectée.

Paramètres de connexion connection-settings

Nom de l’implémentation du SMSC smsc-implementation-name

Définit le nom de l’implémentation SMSC. Il doit être défini sur le nom de votre fournisseur. Contactez l’administrateur ou l’équipe chargée de la délivrabilité pour savoir ce qui doit être ajouté à ce champ. Le rôle de ce champ est décrit dans la section Gestion des erreurs SR.

Nombre de connexions enfant MTA number-mta-child

Dans Adobe Campaign Classic, il définit le nombre de connexions par enfant MTA.

Le connecteur SMPP étendu Adobe Campaign Classic peut contrôler le nombre de connexions par enfant MTA. Pour contrôler la limite globale des connexions, vous devrez limiter le nombre de processus enfant MTA, ce qui signifie souvent disposer d’une plateforme de mid-sourcing dédiée pour les SMS.

Pour Adobe Campaign Classic, le nombre de connexions de récepteurs et d’émetteurs peut être différent :

Comme nous l’avons suggéré plus haut, le processus SMS d’Adobe Campaign Classic ouvre davantage de connexions d’émetteur si la réponse automatique est activée. Ces connexions supplémentaires sont utilisées pour envoyer les réponses automatiques.

Si vous configurez des réponses automatiques, le processus SMS ouvrira des paires émetteur/récepteur, augmentant ainsi le nombre de connexions d’émetteur. Si vous n’avez pas configuré de réponse automatique, elle n’ouvrira que les connexions de récepteur.

Activer TLS via SMPP enable-TLS

Utilisez TLS pour vous connecter au fournisseur. La connexion sera chiffrée. La connexion TLS est gérée par la bibliothèque OpenSSL.Tout ce qui est applicable à OpenSSL sera vrai pour cette connexion.

Activer les traces SMPP en mode verbeux dans le fichier de log enable-verbose-log-file

Ce paramètre permet de vider tout le trafic SMPP dans les fichiers logs. Il est souvent nécessaire d’ajuster les paramètres lors de la configuration initiale. Ceci doit être activé lors de la résolution des problèmes du connecteur et comparé au trafic vu par le fournisseur.

Dans Adobe Campaign Classic, la sortie du log se trouve dans le log MTA pour le trafic lié aux MT et dans le log SMS pour le trafic lié aux MO et SR.

Paramètre de connexion du récepteur receiver-connection

Cette section est uniquement visible en mode Transmitter + receiver séparé.

Utiliser des paramètres différents pour le récepteur receiver-parameters

Lorsque la case n’est pas cochée, les mêmes paramètres sont utilisés pour l’émetteur et le récepteur.

Lorsque la case est cochée, les paramètres de la section Paramètres de connexion s’appliquent à l’émetteur et les paramètres de la connexion du récepteur s’appliquent au récepteur.

Serveur du récepteur, port, compte, mot de passe, type de système

Ces paramètres s’appliquent au récepteur en mode Transmitter + receiver. Ils fonctionnent comme la partie émetteur, voir ci-dessus pour plus de détails.

Paramètres du canal SMPP smpp-channel-settings

Stocker les MO entrants dans la base de données incoming-mo-storing

Lorsque l’option est activée, le MO entrant est stocké dans le tableau inSMS de la base de données. Ce tableau peut être interrogé à l’aide de l’activité requête de tout workflow.

Adobe Campaign Classic stocke toujours tous les MO dans la base de données inSMS. Cette option n’est donc pas disponible.

Activer les mises à jour des KPI en temps réel pendant le traitement du SR (rapport d’état) real-time-kpi

Lorsqu’ils sont activés, les KPI (indicateurs de performance clés) sont mis à jour en temps réel sur la page de diffusion principale lors de la réception d’un SR d’erreur.

L’inconvénient peut être de faibles performances en raison de la contention de base de données qu’elle génère. Si cette option est désactivée, les statistiques sont mises à jour par le workflow syncfromexec, qui s’exécute toutes les 20 minutes.

Adobe Campaign Classic dispose d’un mécanisme entièrement différent pour les KPI (indicateurs de performance clés). Cette option n’est donc pas disponible.

Numéro court short-code

Indique le numéro court principal du compte. Si plusieurs numéros courts sont utilisés pour ce compte ou si le numéro court est inconnu, laissez ce champ vide.

La spécification d’un numéro court s’avère utile pour deux fonctionnalités :

Spécificités des SMSC SMSC-specifics

Ces paramètres sont des paramètres avancés qui adaptent le connecteur Adobe Campaign à la plupart des particularités d’implémentation SMPP.

Ignorer la vérification du certificat TLS skip-tls

Lorsque le TLS est activé, ignorez toutes les vérifications de certificat.

Lorsque l’option est cochée, la connexion n’est plus sécurisée, elle ne doit pas être activée en production.

Ceci peut être utile à des fins de débogage ou de test.

Vous pouvez choisir entre trois valeurs différentes pour la validation du certificat :

Expression régulière appliquée pour déterminer le statut de réussite / erreur regex-applied

Lorsque des messages avec une combinaison de champs “stat” / “err” inconnue sont détectés, ces expressions régulières sont appliqués sur le champ “stat” pour déterminer si le SR a été un succès ou une erreur. Les SR avec des valeurs “stat” qui ne correspondent à aucune de ces expressions régulières sont ignorés.

Par défaut, les valeurs “stat” commençant par DELIV, par ex.DELIVRD dans l’Annexe B, seront considérées comme délivrées avec succès et toutes les valeurs “stat” qui correspondent à des erreurs, p.ex.REJECTED, UNDELIV, sont considérées comme des erreurs.

Format de l’ID dans l’acquittement MT id-format-mt

Indique le format de l’ID renvoyé dans le champ message_id du SUBMIT_SM_RESP PDU.

Format de l’ID dans le SR id-format-sr

Ceci indique le format de l’ID capturé par l’expression régulière Extraction de l’ID dans le SR. Les valeurs ont la même signification et le même comportement que le format en MT ci-dessus.

L’identifiant du SR ou le code d’erreur dans un champ optionnel

Si cette case est cochée, le contenu des champs facultatifs est ajouté au texte traité par les expressions régulières ci-dessus. Le texte aura le format 0xTAG:VALUE, 0xTAG étant la valeur hexadécimale de 4 chiffres de la balise en majuscules, par exemple 0x002E.

Par exemple, vous pouvez capturer l’identifiant dans le champ receipted_message_id. Pour cela, activez cette case à cocher et le texte suivant est ajouté au statut :

0x001E:05e3299e-8d37-49d0-97c6-8e4fe60c7739

Dans cet exemple, 0x001E est la balise du champ facultatif et UUID est la valeur du champ.

Pour capturer cette valeur, vous pouvez désormais définir l’expression régulière suivante dans l’expression régulière d’extraction de l’ID dans le champ de SR :

\b0x001E:([0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12})\b

Balise d’ID de service

Permet d’ajouter un fichier TLV personnalisé. Ce champ définit la partie balise. La valeur peut être personnalisée par diffusion dans la valeur Identifiant service ou programme dans les paramètres avancés de la diffusion.

Ce paramètre permet uniquement d’ajouter une option TLV par message.

Réponse automatique aux MO automatic-reply

Cette fonctionnalité permet de répondre rapidement du texte au MO et de gérer l’envoi de numéro court à la liste bloquée.

Les colonnes Mot-clé et Numéro court définissent les conditions pour déclencher la réponse automatique. Si les deux champs correspondent, le MO est envoyé et l’action supplémentaire est déclenchée. Pour spécifier un caractère de remplacement, vous devez laisser le champ vide. Le mot-clé correspond au premier mot alphanumérique du texte MO, en ignorant la ponctuation et les espaces de début. Cela signifie que le champ Mot-clé ne peut pas contenir d’espaces et doit être un seul mot.

Le paramètre Mot-clé est un préfixe. Par exemple, si vous spécifiez “AD”, il correspondra à “AD”, “ADAPT” et “ADOBE”. Si vous avez plusieurs mots-clés avec un préfixe commun, vous devez prêter attention à l’ordre car les mots-clés sont traités de haut en bas.

La colonne Répondre correspond au texte à répondre. Aucune personnalisation n’est disponible dans ce champ. Si vous laissez ce champ vide, aucun message ne sera répondu, mais l’action supplémentaire sera quand même déclenchée.

La colonne Action supplémentaire fournit une action supplémentaire lorsque Mot-clé et Numéro court correspondent tous les numéros courts vides. Vous pouvez envoyer en quarantaine ou supprimer de la quarantaine, la valeur “aucune réponse au texte”. Si vous spécifiez une action supplémentaire mais que le champ Répondre reste vide, l’action est exécutée mais aucune réponse n’est envoyée. La quarantaine est appliquée uniquement pour le numéro court spécifié ou pour tous les numéros courts si le champ est vide.

Toutes les entrées du tableau sont traitées dans l’ordre spécifié, jusqu’à ce qu’une règle corresponde. Si plusieurs règles correspondent à un MO, seule la règle la plus élevée est appliquée.

Paramètres du modèle de diffusion SMS sms-delivery-template-parameters

Certains paramètres peuvent être définis par modèle de diffusion.

Paramètres de diffusion delivery-parameters

Mode de transmission transmission-mode

Ce champ indique le type de SMS que vous souhaitez transférer : messages normaux ou flash, stockés sur le mobile ou la carte SIM.

Ce paramètre est transmis dans le champ facultatif dest_addr_subunit du SUBMIT_SM PDU.

Période de validité validity-period

La période de validité est transmise dans le champ validity_period du SUBMIT_SM PDU. La date est toujours formatée au format des heures UTC absolu, le champ de date se termine par “00+”.

Connecteur SMPP générique étendu acc-extended-connector

Les flèches représentent les flux de données.

Lors de l’envoi de fragments de diffusion, le MTA génère des enfants MTA. Le nombre de processus enfant MTA est dynamique et dépend d’une configuration dans le fichier serverConf.xml. Chaque enfant MTA instancie le connecteur CSmppConnectorWorker qui se connecte au fournisseur SMPP. Les connexions sont maintenues actives tant que l’enfant MTA est en vie, ce qui est également configurable dans serverConf.xml.

Le processus SMS ne traite que le SR, se connecte au fournisseur et laisse la connexion ouverte. Le processus se reconnecte toutes les 10 minutes pour recharger de nouveaux paramètres, ce qui est normal.

Correspondance des entrées MT, SR et broadlog matching-mt

Une table nmsProviderMsgId intermédiaire est utilisée pour stocker temporairement les données MT et SR avant la validation asynchrone sur le broadlog.

La table nmsProviderMsgId comprend 3 groupes de colonnes :

Une fois le traitement des MT et SR terminé, vous devriez avoir des lignes complètes, avec des informations concernant à la fois le broadlog et l’état.

Ici, iMsgId est lié à la table nmsBroadLogMsg, ce qui indique le message d’état/d’erreur complet.

Le processus SMS recherche toutes les minutes des lignes complètes, puis les traite de façon asynchrone :

Débit et connexions parallèles

Chaque enfant MTA crée un nombre configurable de connexions, de sorte que la limite du nombre d’enfants MTA restreint le nombre de connexions. Comme les processus enfant MTA et le trafic sont corrélés, il existe un certain contrôle bien qu’encore un peu imprévisible.