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

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 accompagne pour 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.

Types de SMS sms-types

Lorsque vous envoyez des SMS en masse par l'intermédiaire d'un fournisseur de services SMS, vous rencontrerez trois types de SMS différents :

Vous devez faire la distinction entre les accusés de réception (PDU RESP, partie du protocole SMPP) et SR : le SR est un type de SMS qui est envoyé par le réseau de bout en bout, alors qu'un acquittement n'est qu'une confirmation de la réussite d'un transfert.

Les acquittements et les SR peuvent déclencher des erreurs, la distinction entre les deux facilitera le résolution des problèmes.

Informations transportées par un SMS information-sms

Un SMS contient plus d'informations que de texte. Voici une liste de ce que vous pouvez vous attendre à trouver dans un SMS :

Protocole SMPP smpp-protocol

Adobe Campaign Standard prend en charge le protocole SMPP version 3.4, 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 Standard, la réconciliation MT et SR est native de la MTA, il n'y a donc pas de processus SMS dédié.

Un SUBMIT_SM_RESP PDU réussi déclenche le statut du message "envoyé" dans le journal 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 lui-même 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 bind-transmitter

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 la correspondance UNBIND_RESP PDU 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 SUBMIT_SM PDU :

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 une adaptation de la configuration.

DELIVER_SM_RESP deliver-sm-resp

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

Adobe Campaign Standard n'envoie un DELIVER_SM_RESP qu'une fois toutes les étapes de traitement réussies. Cela garantit qu'aucun SR ou MO n'est acquitté alors qu'il y a toujours un risque d'erreur de traitement.

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

Les SMS en plusieurs parties, ou les SMS longs, sont des SMS envoyés en plusieurs parties. En raison des limitations techniques du protocole de réseau mobile, un SMS ne peut pas dépasser 140 octets ou doit être fractionné. Consultez la section Encodage du texte SMS pour en savoir plus sur le nombre de caractères pouvant tenir dans un SMS.

Chaque partie d'un long message est un SMS individuel. Ces pièces se déplacent indépendamment sur le réseau et sont assemblées par le téléphone mobile récepteur. Pour gérer les reprises et les problèmes de connectivité, Adobe Campaign envoie ces pièces dans l'ordre inverse et ne demande un SR que sur la première partie du message, la dernière envoyée. Puisque le téléphone portable n'affiche un message que lors de la réception de sa première partie, les reprises sur d'autres parties ne produisent pas de doublons sur le téléphone portable.

Le nombre maximal de SMS par message peut être défini par diffusion à l'aide du paramètre Nombre maximal de SMS par message défini dans le Modèle de diffusion. Les messages qui dépassent cette limite échouent lors de l'envoi d'un SMS avec une raison d'échec trop longue.

Il y a deux façons d'envoyer des SMS longs :

Consultez la description des champs esm_class, short_message et message_payload du PDU SUBMIT_SM pour plus d'informations sur le protocole et les formats.

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'émission.

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.

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 Adobe Campaign Standard Extended 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.

Encodage du texte SMS sms-text-encoding

Vous devez toujours contacter le fournisseur SMSC en cas de problèmes d'encodage. Seuls les fournisseurs SMSC ont une connaissance précise de l'encodage qu'ils prennent en charge et des règles spéciales qui peuvent s'appliquer en raison de limitations de leur plateforme technique.

Les messages SMS utilisent un encodage spécial de 7 bits, souvent appelé encodage GSM7.

Dans le protocole SMPP, le texte GSM7 sera étendu à 8 bits par caractère pour faciliter le résolution des problèmes. La SMSC le compresse en 7 bits par caractère avant de l'envoyer au mobile. Cela signifie que le champ short_message du SMS peut comporter jusqu'à 160 octets dans le cadre SMPP, alors qu'il est limité à 140 octets lorsqu'il est envoyé sur le réseau mobile.

En cas de problème d'encodage, voici quelques éléments importants à vérifier :

Le champ data_coding indique l'encodage utilisé. Un problème majeur est que la valeur 0 signifie un encodage SMSC par défaut dans la spécification, qui fait généralement référence à GSM7. Vérifiez auprès du partenaire SMSC quel encodage est associé à data_coding = 0 qu'Adobe Campaign ne fait que prendre en charge. D'autres valeurs data_coding tendent à suivre la spécification, mais la seule façon de s'en assurer est de vérifier auprès du fournisseur SMSC.

La taille maximale d'un message dépend de son encodage. Ce tableau récapitule toutes les informations pertinentes :

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

Mode de connexion SMPP smpp-connection-mode

Définit la connexion en mode Transmitter ou en mode Transmitter + receiver séparé. Lorsque vous passez en mode Transmitter + receiver séparé, les paramètres de la section Mode de connexion SMPP s'appliquent à l'émetteur et les paramètres de la section Paramètres de connexion du récepteur s'appliquent à la connexion du récepteur, uniquement si vous avez coché la case Utiliser des paramètres différents pour le récepteur.

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.

Serveur server

Nom DNS ou adresse IP du serveur auquel se connecter.

Port port

Port TCP auquel se connecter.

Compte account

Nom d'utilisateur de la connexion. Transmis dans le champ system_id du PDU BIND.

Mot de passe password

Mot de passe de la connexion SMPP. Transmis dans le champ du mot de passe du PDU BIND.

Type de système system-type

Valeur transmise dans le champ system_id du PDU BIND. Certains fournisseurs ont besoin d'une valeur spécifique ici.

Connexions simultanées simultaneous-connections

Dans Adobe Campaign Standard, ceci définit le nombre de connexions par thread SMS et par processus MTA.
Le nombre de processus MTA est déterminé par le déploiement : il y a généralement 2 MTA et 1 thread. Le nombre de threads peut être modifié dans le fichier config-instance.xml à l'aide du paramètre smppConnectorThreads. Il y a généralement 1 processus MTA par conteneur et 1 thread par processus MTA.

Formule de connexions totales pour Adobe Campaign Standard :

Les connexions simultanées sont définies dans le compte externe, le nombre de threads est défini dans le fichier config-instance.xml (smppConnectorThreads) et le nombre de MTA peut être limité dans le compte externe.

En mode transmitter / receiver séparé, le nombre de connexions ci-dessus représente le nombre de paires émetteur / récepteur, ce qui signifie qu'il y aura deux fois plus de connexions au total.

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.

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

Autoriser la translitération des caractères allow-character-transliteration

La translitération est le processus de recherche de caractères équivalents à ceux qui sont manquants. Par exemple, le caractère français "ê" (avec un accent circonflexe) est absent de l'encodage GSM, mais il peut être remplacé par "e" sans nuire à la lisibilité.

Si cette case n'est pas cochée, l'encodage du texte échoue s'il ne peut pas coder la chaîne telle quelle.

Si cette case est cochée, l'encodage de texte tentera de convertir la chaîne en une version approximative plutôt que d'échouer. Si certains caractères n'ont pas d'équivalent en encodage de cible, l'encodage de texte échoue.

Pour obtenir une explication plus générale du processus d'encodage, consultez la section Définir un mapping spécifique du paramètre d'encodage.

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.

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.

Numéro source source-number

Définit l'adresse source par défaut des messages. Ce paramètre ne s'applique que si le numéro source a été laissé vide dans la diffusion.

Par défaut, le champ du numéro source n'est pas transmis.Le fournisseur le remplace donc par le numéro court.

Ceci active la fonction d'écrasement de l'adresse de l'expéditeur / oADC.

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 :

NPI/TON source, NPI/TON destination ton-npi

Le TON (Type de numéro) et le NPI (Indicateur de plan de numérotation) sont décrits à la section 5.2.5 de la spécification SMPP 3.4 (page 117). Ces valeurs doivent être définies en fonction des besoins du fournisseur.

Ils sont transmis tels quels dans les champs source_addr_ton, source_addr_npi, dest_addr_ton et dest_addr_npi du SUBMIT_SM PDU.

Service type service-type

Ce champ est transmis tel quel dans le champ service_type du SUBMIT_SM PDU. Définissez cette variable en fonction des besoins du fournisseur.

Débit et délais throughput-timeouts

Ces paramètres contrôlent tous les aspects du timing du canal SMPP. Certains fournisseurs ont besoin d'un contrôle très précis du taux de message, des délais de fenêtre et des délais de reprise. Ces paramètres doivent être définis sur des valeurs correspondant à la capacité du fournisseur et aux conditions indiquées dans son contrat.

Fenêtre d'émission sending-window

La fenêtre est le nombre de SUBMIT_SM PDU qui peuvent être envoyés sans attendre une correspondance SUBMIT_SM_RESP.

Exemple de transmission avec une fenêtre maximale de 4 :

La fenêtre permet d'augmenter le débit lorsque la liaison réseau présente une latence élevée. La valeur de la fenêtre doit être au moins égale au nombre de SMS/s multiplié par la latence du lien en secondes, de sorte que le connecteur n'attend jamais un SUBMIT_SM_RESP avant d'envoyer le message suivant.
Si la fenêtre est trop grande, vous pouvez envoyer plus de messages en doublons en cas de problème de connexion. En outre, la plupart des fournisseurs ont une limite très stricte pour la fenêtre et refusent les messages qui dépassent la limite.

Comment calculer la formule optimale de la fenêtre d'émission :

Exemple : si 300 SMS/s sont définis dans le débit maximal MT et qu'il y a une latence de 100 ms entre SUBMIT_SM et SUBMIT_SM_RESP en moyenne, la valeur optimale sera 300×0.1 = 30.

Débit max de MT max-mt-throughput

Nombre maximal de MT par seconde et par connexion. Ce paramètre est strictement appliqué, le MTA n'enverra jamais de messages plus rapidement que cette limite. Il est utile pour les fournisseurs qui nécessitent un ralentissement précis.

Pour connaître la limite de débit totale, multipliez ce nombre par le nombre total de connexions, comme indiqué dans la formule ci-dessus.

0 signifie pas de limite, le MTA enverra le MT aussi vite que possible.

Il est généralement recommandé de maintenir ce paramètre en dessous de 1000, puisqu'il est impossible de garantir un débit précis au-dessus de ce nombre, à moins que l'architecture finale ne soit correctement évaluée. Si vous avez besoin d'un débit supérieur à 1000, contactez votre fournisseur. Il peut être préférable d'augmenter le nombre de connexions au-dessus de 1000 MT/s.

Temps avant reconnexion time-reconnection

Lorsque la connexion TCP est perdue, le connecteur attend ce nombre de secondes avant d'essayer d'établir une connexion.

Délai d'expiration des MT expiration-period

Délai entre SUBMIT_SM et son SUBMIT_SM_RESP correspondant. Si RESP n'est pas reçu à temps, le message sera considéré comme ayant échoué et la politique de nouvelle tentative globale du MTA s'appliquera.

Délai d'attente maximal d'un bind bind-timeout

Délai entre la tentative de connexion TCP et la réponse BIND_*_RESP. Lorsqu'elle expire, la connexion est fermée par le connecteur Adobe Campaign et il faut attendre le temps avant reconnexion avant de réessayer.

Période d'enquire_link enquire-link-period

enquire_link est un type spécial de PDU envoyé pour maintenir la connexion en vie. Cette période est en secondes. Le connecteur de campagne n'envoie enquire_link que lorsque la connexion est inactive pour économiser la bande passante. Si aucun RESP n'est reçu après deux fois cette période, la connexion est considérée comme étant inactive et un processus de reconnexion est déclenché.

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.

Définir un mapping des encodages spécifique encoding-specific-mapping

Pour plus d'informations, consultez la section Encodage de texte SMS pour plus d'informations sur l'encodage de texte.

Ce paramètre permet de définir un mapping de codage personnalisé différent de la spécification. Vous pourrez déclarer une liste d'encodages, ainsi que leur valeur data_coding.

Le MTA tentera d'effectuer un encodage en utilisant le premier de la liste. S'il échoue, il essaiera d'utiliser l'encodage suivant sur la liste, etc. Si aucun encodage ne peut être utilisé pour encoder le message, une erreur se produit. Une fois l'encodage trouvé, le MTA crée le SUBMIT_SM PDU avec le texte encodé et le champ data_coding défini avec la valeur spécifiée dans le tableau.

L'ordre des éléments du tableau est important : les encodages sont des tentatives de haut en bas. Placez l'encodage le moins cher ou le plus recommandé en haut de la liste, puis choisissez des encodages de plus en plus chers.

Veuillez noter que UCS-2 n'échouera jamais car il peut coder tous les caractères pris en charge dans Adobe Campaign et que la longueur maximale d'un SMS UCS-2 est beaucoup plus petite : 70 caractères uniquement.

Vous pouvez également utiliser ce paramètre pour forcer l'utilisation d'un encodage spécifique en ne déclarant que 1 ligne dans le tableau de mapping.

Le mapping par défaut utilisé lorsque la case à cocher n'est pas cochée est équivalent au tableau suivant :

Cela signifie que le MTA tente d'encoder le message en GSM. S'il réussit, il l'envoie avec data_coding défini sur 0.

Si le message ne peut pas être encodé en GSM, il est encodé en UCS-2 et définit data_coding sur 8.

Activer message_payload enable-message-payload

Lorsque l'option n'est pas cochée, les SMS longs sont fractionnés par le MTA et envoyés dans plusieurs SUBMIT_SM PDU avec l'UDH. Le message est recomposé par le téléphone portable suivant les données UDH.

Si cette option est cochée, un SMS long est envoyé dans un PDU SUBMIT_SM, plaçant le texte dans le champ message_payload facultatif. Consultez la spécification SMPP pour plus d'informations à ce sujet.

Si cette fonction est activée, Adobe Campaign ne peut pas comptabiliser les parties SMS individuellement : tous les messages sont comptés comme envoyés en une seule partie.

Envoyer le numéro de téléphone complet send-full-phone-number

Si cette case n'est pas cochée, seuls les chiffres du numéro de téléphone sont envoyés au fournisseur (champ destination_addr du champ SUBMIT_SM). Il s'agit du comportement par défaut puisque l'indicateur de numéro international, généralement un préfixe +, est remplacé par les champs TON et NPI en SMPP.

Si cette case est cochée, le numéro de téléphone est envoyé tel quel, sans prétraitement ni espaces potentiels, préfixe + ou signes dièse/hachage/étoile.

Cette fonctionnalité a également un effet sur le comportement de la fonctionnalité de liste bloquée de réponse automatique : lorsque la case n'est pas cochée, un préfixe + est ajouté aux numéros de téléphone insérés dans le tableau de quarantaine afin de compenser la suppression du préfixe + du numéro de téléphone par le protocole SMPP lui-même.

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.

Liaison TON/NPI bind-ton-npi

TON (Type de numéro) et NPI (Indicateur de plan de numérotation) décrits à la section 5.2.5 de la spécification SMPP 3.4 (page 117). Ces valeurs doivent être définies selon les besoins du fournisseur.

Ils sont transmis tels quels dans les champs addr_ton et addr_npi du PDU BIND.

Plage d'adresses address-range

Envoyé tel quel dans le champ address_range du PDU BIND. Cette valeur doit être définie selon les besoins du fournisseur.

Nombre d'acquittements d'identifiant invalides invalid-id

Limite le nombre d'identifiants de message non valides DELIVER_SM_RESP pouvant être envoyés pour un seule SR.

Cette valeur ne doit être utilisée qu'à des fins de résolution des problèmes en tant que solution de contournement et définie sur 0 dans des conditions normales.

Par exemple, lorsque vous définissez sur 2 :

La définition de ce champ sur 0 désactive le mécanisme où ID de message non valide est toujours renvoyé, c'est un comportement normal.

Si ce champ est défini sur 1, le connecteur répond toujours "OK", même si l'ID n'est pas valide. Cette valeur doit être définie sur 1 uniquement sous supervision, à des fins de résolution des problèmes et pour une durée minimale, par exemple pour récupérer d'un problème côté fournisseur.

Expression régulière d'extraction de l'ID dans le SR regex-extraction

Le format SR n'est pas strictement appliqué par la spécification du protocole SMPP. Il ne s'agit que d'une recommandation décrite à l'Annexe B (page 167) de la spécification. Certains implémenteurs de SMPP formattent ce champ différemment, de sorte qu'Adobe Campaign a besoin d'un moyen d'extraire le champ correct.

Par défaut, il capture jusqu'à 10 caractères alphanumériques après id:.

L'expression régulière doit comporter exactement un groupe de capture avec une partie entre parenthèses. Les parenthèses doivent entourer la partie ID. Le format d'expression régulière est PCRE.

Lors de la modification de ce paramètre, veillez à inclure le plus de contexte possible pour éviter les faux triggers. S'il existe des préfixes spécifiques, tels que id: dans la norme, incluez-les dans l'expression régulière. Utilisez également autant que possible des délimiteurs de mots (\b) pour éviter de capturer du texte au milieu d'un mot.

Ne pas inclure suffisamment de contexte dans l'expression régulière peut introduire un petit défaut de sécurité : le contenu réel du message peut être inclus dans le SR. Si vous ne faites correspondre qu'un format d'ID spécifique sans contexte, par exemple un UUID, il se peut qu'il analyse le contenu du texte réel, par exemple un UUID incorporé dans le champ de texte, au lieu de l'ID.

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

Stocker l'identifiant du SR ou le code d'erreur dans un champ de texte

Si cette case est cochée, le champ Texte est conservé pendant le traitement du texte de statut du SR.

Cela s'avère utile si le fournisseur place des données importantes dans ce champ, telles que l'ID ou le statut. En règle générale, ce champ peut être ignoré en toute sécurité puisqu'il peut contenir du texte avec un codage non ASCII et perturber le traitement d'expression régulière.

L'activation de cette option peut introduire un très petit défaut de sécurité si l'expression régulière Extraction de l'ID dans le champ SR n'est pas suffisamment précise. Le contenu du champ Texte peut être analysé en tant qu'ID et un agresseur peut l'utiliser pour injecter des identifiants falsifiés, ce qui peut entraîner un déni de service partiel.

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 facultatifs de réponse automatique (TLV) automatic-reply-tlv

Depuis la version 21.1, vous pouvez ajouter des paramètres optionnels à la réponse automatique MT. Ils sont ajoutés en tant que paramètres TLV optionnels à SUBMIT_SM PDU de la réponse, comme décrit à la section 5.3 de la spécification SMPP(page 131).

Pour plus d'informations sur les paramètres optionnels, consultez cette section.

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

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

À partir du champ from-field

Ce champ est facultatif. Il permet d'écraser l'adresse de l'expéditeur (oADC). Le contenu de ce champ est placé dans le champ source_addr du SUBMIT_SM PDU.

Le champ est limité à 21 caractères par la spécification SMPP, mais certains fournisseurs peuvent autoriser des valeurs plus longues. Notez également que des restrictions très strictes peuvent être appliquées dans certains pays, par exemple la longueur, le contenu, les caractères autorisés.

Paramètres de diffusion delivery-parameters

Nombre maximal de SMS par message maximum-sms

Ce paramètre ne fonctionne que si le paramètre Payload du message est désactivé. Pour plus d'informations à ce propos, consultez cette page. Si le message nécessite plus de SMS que cette valeur, une erreur est déclenchée.

Le protocole SMS limite les SMS à 255 parties, mais certains téléphones portables ont du mal à assembler de longs messages avec plus de 10 parties environ, la limite dépend du modèle exact. Nous vous conseillons de ne pas dépasser 5 parties par message.

En raison du fonctionnement des messages personnalisés dans Adobe Campaign, la taille des messages peut varier. Le fait d'avoir beaucoup de messages longs pourrait augmenter les coûts d'envoi.

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+").

Paramètres facultatifs SMPP (TLV) smpp-optional-parameters

Depuis la version 21.1, vous pouvez ajouter plusieurs paramètres optionnels à chaque MT envoyé pour cette diffusion. Ces paramètres facultatifs sont ajoutés au SUBMIT_SM PDU de la réponse, comme décrit à la section 5.3 de la spécification SMPP (page 131).

Chaque ligne de la table représente un paramètre facultatif :

Si un paramètre facultatif possède le même identifiant de balise que l'identifiant de balise du service défini dans le compte externe, la valeur définie dans cette table prévaut.

Connecteur SMPP ACS-SMPP-connector

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

La chose la plus importante à noter ici est qu'il y a plusieurs threads de connecteur SMPP. Ces threads sont tous identiques et partagent la même configuration. C'est pourquoi le nombre de connexions est toujours multiplié par le nombre de threads.

Le nombre de threads ne peut pas être modifié par le client, car il nécessite de modifier les fichiers de configuration.

Description du comportement du connecteur SMPP behavior-smpp-connector

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

Dans Adobe Campaign, un message est une entrée broadlog. Dans Adobe Campaign Standard, les connecteurs externes n'ont besoin de connaître que le tableau broadlog qui fonctionne : nmsBroadLogExec. Un workflow est chargé de copier les entrées broadlog vers leurs dimensions de ciblage spécifiques (nmsBroadLogXXX).

Malheureusement, SMPP n'autorise pas l'envoi d'un identifiant avec un message : le fournisseur attribue un ID MT à chaque MT, puis fournit un ou plusieurs SR avec le même ID.

L'ID donné par le fournisseur est stocké dans la colonne sProviderId du tableau nmsBroadLogExec. Le SR arrive toujours après l'envoi et l'acquittement avec succès du MT, mais peut parfois arriver dans le mauvais ordre, ce qui est connu dans Adobe Campaign comme SR exceptionnel. Le thread de traitement stocke ces SR temporairement dans la mémoire RAM jusqu'à ce que les informations complètes arrivent.

Lorsqu'un MT est acquitté (SUBMIT_SM_RESP), sProviderId est immédiatement mis à jour dans la base de données.

Chaque SR est traité individuellement par les threads de traitement SMPP. Ce processus est pseudo-synchrone : il est considéré comme synchrone depuis l'extérieur, mais mis en œuvre en interne avec des implémentations pilotées par l'événement. Les SR ne sont acquittés que lorsqu'une mise à jour broadlog a réussi.Si une erreur se produit, le SR est rejeté.

Voici le processus appliqué à chaque SR :

Pour vérifier les étapes ci-dessus, Activez les traces SMPP de verbose afin de vérifier manuellement que toutes les étapes sont correctement appliquées. Ceci est requis chaque fois qu'Adobe Campaign est connecté à un nouveau fournisseur SMPP.

Avant la mise en ligne checklist

Cette liste de contrôle fournit une liste de choses que vous devriez vérifier avant la mise en ligne. Une configuration incomplète peut entraîner de nombreux problèmes.

Rechercher les conflits de compte externe external-account-conflict

Vérifiez que vous n'avez pas de vieux comptes externes SMS. Si vous laissez le compte test désactivé, il existe un risque qu'il soit réactivé sur le système de production et qu'il génère des conflits potentiels.

Vérifiez qu’aucune autre instance ne se connecte à ce compte. En particulier, assurez-vous que l’environnement d’évaluation ne se connecte pas au compte. Certains fournisseurs assurent cette prise en charge, mais cela nécessite une configuration très spécifique à la fois du côté d’Adobe Campaign et sur la plateforme du fournisseur.

Si vous devez connecter plusieurs comptes de la même instance Adobe Campaign se connectent au même fournisseur, contactez ce dernier pour vérifier qu'il distingue effectivement les connexions entre ces comptes. La présence de plusieurs comptes avec le même nom d'utilisateur nécessite une configuration supplémentaire.

Activer les traces SMPP de verbose lors des vérifications enable-verbose

Vous devez toujours activer les traces SMPP de verbose lors des vérifications.
Même si vous ne pouvez pas vérifier vous-même les logs, il sera plus facile pour le Support de vous aider.

Tester votre SMS test

Vérifier les PDU check-pdus

Même si les messages semblent avoir réussi, il est important de vérifier que les PDU sont correctement formatés.

Cette étape est nécessaire lors de la connexion avec un fournisseur qui n'était pas connecté à Adobe Campaign auparavant.

BIND bind

Vérifiez que les BIND_* PDUs sont correctement envoyés. La chose la plus importante à vérifier est que le fournisseur renvoie toujours un BIND_*_RESP PDUs (command_status = 0) réussi.

Vérifiez qu'il n'y a pas trop de BIND_* PDU.S'il y en a trop, cela peut indiquer que la connexion est instable. Pour plus d'informations, consultez la section Problèmes liés aux connexions instables.

ENQUIRE_LINK enquire-link-pdus

Vérifiez que les ENQUIRE_LINK PDU sont échangés régulièrement lorsque la connexion est inactive.

SUBMIT_SM / DELIVER_SM submit-sm-deliver-sm

Envoyez un message, puis recherchez dans les journaux les SUBMIT_SM, SUBMIT_SM_RESP, DELIVER_SM et DELIVER_SM_RESP PDU correspondants.

Avec le SUBMIT_SM PDU :

Avec le SUBMIT_SM_RESP PDU :

Avec le DELIVER_SM PDU :

Avec le DELIVER_SM_RESP PDU :

Demandez au fournisseur si tout va bien provider

Même si votre SMS réussit, contactez le fournisseur pour voir si tout est en ordre.

Désactiver les traces SMPP de verbose disable-verbose

Une fois toutes les vérifications terminées, la dernière chose à faire est de désactiver les traces SMPP de verbose pour ne pas générer trop de journaux. Vous pouvez les réactiver à des fins de résolution des problèmes, même sur les systèmes de production.