Documentation Campaign Documentation de Campaign Classic v7

Protocole et paramètres du connecteur SMS

Dernière mise à jour : 28 janvier 2025

Rubriques :

Créé pour :

Développeur

NOTE

Dans ce document, toutes les références au protocole, aux noms de champs et aux valeurs se rapportent à la spécification SMPP 3.4.

Vue d'ensemble

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 :

L'envoyer manuellement à partir d'un téléphone, façon habituelle de communiquer directement entre personnes.
L'envoyer depuis Internet, façon dont Adobe Campaign envoie des messages. Pour cela, vous avez besoin d'un fournisseur de services de SMS destiné à connecter Internet au réseau mobile.
Adobe Campaign utilise le protocole SMPP pour envoyer des SMS à un fournisseur de services.

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.

IMPORTANT

La configuration d'une connexion à un nouveau fournisseur peut nécessiter des compétences techniques, des connaissances relatives au protocole TCP, au binaire, à la représentation hexadécimale et aux encodages de texte. Il faudra également une coopération active avec le fournisseur.

Types de SMS

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 :

SMS MT (Mobile Terminated) : un SMS émis par Adobe Campaign vers les téléphones portables par l'intermédiaire du fournisseur SMPP.
SMS MO (Mobile Originated) : un SMS envoyé par un téléphone mobile à Adobe Campaign par l'intermédiaire du fournisseur SMPP.
SMS SR (Status Report) ou DR ou DLR (Delivery Receipt) : un accusé de réception envoyé par le téléphone mobile à Adobe Campaign par l'intermédiaire du fournisseur SMPP indiquant que le SMS a été reçu avec succès. Adobe Campaign peut également recevoir des SR indiquant que le message n'a pas pu être remis, souvent avec une description de l'erreur.

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

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

Le texte, qui est limité à 140 octets, ce qui signifie entre 70 et 160 caractères selon l'encodage. Voir Encodage du texte SMS ci-dessous pour plus de détails et pour connaître les limitations.
Adresse du destinataire, parfois appelée ADC ou MSISDN. C'est le numéro du mobile qui recevra le SMS.
Adresse de l'expéditeur, qui peut être appelée oADC ou parfois sender id. Il peut s'agir d'un numéro de téléphone utilisé au quotidien, d'un numéro court envoyé par l'intermédiaire d'un fournisseur ou d'un nom. Le nom est une fonctionnalité facultative. Dans ce cas, vous ne pouvez pas répondre au SMS.
Indicateur indiquant si le message est un message Flash. Un message Flash est un pop-up qui n’est pas stocké en mémoire.
Indicateur indiquant si un SR est attendu ou non.
Date de validité, après laquelle aucun équipement réseau n'est autorisé à réessayer.
Champ data_coding qui indique l'encodage du texte.

Protocole SMPP

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

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 :

Transmitter + receiver (ou TX+RX) : deux connexions TCP distinctes sont utilisées pour la transmission et la réception de messages.
Transceiver (ou TRX) : une connexion TCP unique est utilisée pour transmettre et recevoir des messages.

NOTE

Adobe Campaign Classic ne prend en charge que le mode TX+RX. Cette limite est liée à son architecture technique.

PDU SMPP

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 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é

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

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 :

Mode

Types de SMS autorisés

Transmitter

MT

Receiver

MO + SR

Transceiver

MT + MO + SR

Champs visibles dans un BIND_* PDU :

system_id : nom d'utilisateur utilisé pour l'authentification. Défini dans le compte externe.
Password : mot de passe utilisé pour l'authentification. Défini dans le compte externe.
System_type : obligatoire pour définir une valeur spécifique pour certains fournisseurs. Défini dans le compte externe, disponible dans toutes les versions. Il est souvent fait la distinction entre différents types de contrats, canaux, pays, etc.
addr_ton et addr_npi : requis par certains fournisseurs. Défini par les paramètres Bind TON et Bind NPI dans le compte externe.
address_range : requis par certains fournisseurs. La plupart du temps, il s'agit d'une liste de numéros courts autorisés sur cette connexion. Défini dans le compte externe.

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

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

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

Champs visibles dans un PDUSUBMIT_SM :

service_type : requis par certains fournisseurs. Défini dans les propriétés de la diffusion.
source_addr_ton et source_addr_npi : indique le type d'adresse source transmise. La signification de ces champs est normalisée, mais comme certains fournisseurs les utilisent différemment, vous devriez demander au fournisseur sa valeur correcte. Défini dans le compte externe.
source_addr : l'adresse source / oADC du MT. Elle sera affichée sur le téléphone mobile. Définie dans le compte externe et la diffusion, la valeur de la diffusion prévaut sur la valeur du compte externe.
dest_addr_ton et dest_addr_npi : indique le type d'adresse de destination transmise (format local ou international, par exemple). La signification de ces champs est normalisée, mais comme certains fournisseurs les utilisent différemment, vous devriez demander au fournisseur sa valeur correcte. Défini dans le compte externe.
destination_addr : adresse du destinataire, numéro de téléphone ou MSISDN.
esm_class : permet de déterminer si UDH est utilisé ou non dans le champ de texte. Activé automatiquement par le connecteur pour scinder les SMS si le mode message_payload n'est pas utilisé.
priority_flag : priorité de ce message sur les autres. Cela est lié à la priorité de la diffusion elle-même.
validity_period : date et heure après lesquelles aucune nouvelle tentative ne doit être effectuée. Défini dans la diffusion elle-même.
registered_delivery : indique si un SR est demandé ou non. Adobe Campaign définit toujours cet indicateur, à l'exception des réponses automatiques. Pour les messages en plusieurs parties, l'indicateur n'est défini que pour la première partie. Toutes les versions ont le même comportement.
data_coding : indique le codage utilisé dans le champ de texte. Pour plus d'informations, consultez la section Encodage du texte SMS pour plus d'informations.
short_message : texte du message. Si UDH est utilisé, il contient également l'en-tête UHD.

Adobe Campaign prend en charge les champs facultatifs suivants :

Dest_addr_subunit : utilisé pour spécifier la cible du SMS : flash, mobile ou carte SIM. Défini dans les propriétés de la diffusion.
message_payload : lorsqu'il est activé dans le compte externe, de longs messages sont envoyés dans un seul PDU et le texte est transmis dans ce champ plutôt que dans le champ short_message.

SUBMIT_SM_RESP

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

IMPORTANT

De nombreux fournisseurs transmettent l'ID MT au format hexadécimal. Assurez-vous de définir correctement le format de l'ID dans l'acquittement MT dans le compte externe.

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

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 :

source_addr : adresse source du MO/SR. Il s'agit généralement d'un numéro de téléphone.
destination_addr : numéro court qui a reçu le MO ou le SR.
esm_class : utilisé pour déterminer si le PDU est un MO ou un SR.
short_message : texte du message. Pour le SR, il contient les données décrites à l'annexe B de la spécification du protocole SMPP. Voir Gestion des erreurs SR pour plus de détails.

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

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

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

Ce PDU acquitte le fait que la connexion est active.

SMS en plusieurs parties (SMS long)

IMPORTANT

Adobe Campaign prend uniquement en charge l’envoi de SMS en plusieurs parties ou de SMS longs. UDH et message_payload ne sont pas pris en charge pour les SMS entrants (MO), ce qui signifie que les MO sont limités à 160 caractères.

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 :

UDH : la méthode par défaut et recommandée pour envoyer des messages longs. Dans ce mode, le connecteur divise le message en plusieurs SUBMIT_SM PDU avec les informations UDH. Ce protocole est celui utilisé par les téléphones portables eux-mêmes. Cela signifie qu'Adobe Campaign a le plus grand contrôle sur la génération de messages, ce qui lui permet de calculer exactement combien de parties ont été envoyées et comment elles ont été fractionnées.
message_payload : la façon d'envoyer tout le long message en un seul SUBMIT_SM PDU. Le fournisseur devra le fractionner, ce qui signifie qu'il est impossible pour Adobe Campaign de savoir exactement combien de parties ont été envoyées. Certains fournisseurs exigent ce mode, mais nous vous conseillons de ne l'utiliser que s'ils ne prennent pas en charge l'UDH.

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

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

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 :

réponses synchrones dans le SUBMIT_SM_RESP qui surviennent immédiatement après l'envoi du message au SMSC
accusés de réception qui peuvent s'afficher beaucoup plus tard lorsque le mobile a reçu le message ou lorsque le message a expiré. Dans ce cas, l'erreur se trouve dans un SR.

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

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

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 :

S'il correspond à l'expression régulière success, il est considéré comme une réussite.
S'il correspond à l'expression régulière error, le message est qualifié d'erreur.
Si aucune de ces deux expressions régulières ne correspond, le SR est ignoré. Il peut s'agir d'une notification intermédiaire, qui n'est pas gérée par Adobe Campaign.

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

Vous devez toujours contacter le fournisseur SMSC en cas de problèmes d'encodage. Seuls les fournisseurs SMSC ont une connaissance de l'encodage qu'ils prennent en charge et des règles spéciales qui peuvent s'appliquer en raison des limites 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 :

Assurez-vous de connaître les caractères qui font partie de l'encodage. GSM7 ne prend pas entièrement en charge les signes diacritiques ou les accents. Surtout en français, où "é" et "è" font partie de GSM7, mais "ê", "â" ou "ï" non. Il en va de même pour l'espagnol.
Le C avec cédille (ç) n'est présent que dans les majuscules de l'alphabet GSM7, mais certains téléphones le rendent en minuscules ou "smart". La recommandation générale est d'éviter complètement la cédille ou de basculer en UCS-2.
N'utilisez pas l'ASCII dans les SMS, sauf si le fournisseur SMSC le demande explicitement. Cet encodage réduit l'espace car il comporte des caractères 8 bits et une couverture inférieure à celle de GSM7. Cet encodage peut être requis pour les réseaux CDMA, utilisés en Amérique du Nord.
Latin-1 n'est pas toujours pris en charge. Vérifiez la compatibilité avec votre fournisseur SMSC avant de tenter d'utiliser Latin-1.
Les tableaux de conversion de langue nationale ne sont pas pris en charge par le connecteur Adobe Campaign. Vous devez utiliser UCS-2 ou autre data_coding à la place.
UCS-2 et UTF-16 sont souvent mélangés par les téléphones. Ceci est un problème lors de l'utilisation d'émoticônes et d'autres caractères non présents dans UCS-2.
La plupart des téléphones ne contiennent pas de glyphes de police pour tous les caractères UCS-2. Les smartphones ont tendance à être en mesure d'afficher des caractères rares assez facilement, mais les téléphones numériques ont généralement un support limité à ce qui est utile dans la langue maternelle du pays dans lequel ils ont été achetés. Si vous voulez utiliser un émoticône ou de l'art ASCII, testez-le sur un large éventail de téléphones avant de l'envoyer. La prévisualisation Adobe Campaign ne simule pas les glyphes manquants et affiche les symboles disponibles dans le navigateur Web.

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 :

Encodage

data_coding habituel

Taille du message (caractères)

Taille de partie pour SMS à plusieurs parties

Caractères disponibles

GSM 7

0

160

152

Jeu de caractères de base GSM7 + extension (les caractères étendus prennent 2 caractères)

Latin -1

3

140

134

ISO-8859-1

UCS-2
UTF-16

8

70

67

Unicode (varie d'un téléphone à l'autre)

Paramètres de compte externe SMPP

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

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

Nom de l'implémentation du SMSC

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.

NOTE

L’engagement de l’équipe chargée de la délivrabilité repose sur un contrat. La clientèle doit contacter son représentant ou sa représentante Adobe pour obtenir des informations relatives à l’engagement en matière de délivrabilité.

Serveur

Nom DNS ou adresse IP du serveur auquel se connecter.

Port

Port TCP auquel se connecter.

Compte

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

Mot de passe

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

Type de système

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

Nombre de connexions enfant MTA

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 :

Connexions de l'émetteur = Nombre de connexions enfant MTA * Nombre de processus enfant MTA * Nombre de MTA (si la réponse automatique est définie) * Nombre de connexions enfant MTA

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.

Connexions de récepteur = Nombre de connexions enfant MTA

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

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

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

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

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

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

Autoriser la translitération des caractères

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

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)

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 source

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

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 :

La prévisualisation affiche le numéro court si aucun numéro source n'est fourni. Il reflétera le comportement réel sur le téléphone portable.
Le paramètre de liste bloquée de la fonction de réponse automatique envoie uniquement à la quarantaine l'utilisateur pour un numéro court spécifique.

NPI/TON source, NPI/TON destination

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

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

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

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 :

Mesurez la latence maximale entre SUBMIT_SM et SUBMIT_SM_RESP.
Multipliez cette valeur en secondes jusqu'au débit max de MT. Cela donnera la valeur 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

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 et que le fournisseur SMPP ait été spécifiquement demandé. Il peut être préférable d'augmenter le nombre de connexions au-dessus de 1000 MT/s.

Temps avant reconnexion

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

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

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 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

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

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 :

data_coding

Encodage

0

GSM

9

UCS -2

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

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

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

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 :

Procéder à une vérification complète de la certification (y compris le nom d'hôte), par défaut.
Ignorer la vérification du nom d'hôte.
Ignorer la vérification du certificat.

Liaison 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

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

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 :

Le fournisseur envoie un SR (DELIVER_SM) avec l'ID "1234".
L'ID "1234" est introuvable dans la base de données.
Le connecteur comptabilise 1 erreur ID non valide pour cet ID, de sorte qu'il envoie DELIVER_SM_RESP avec le code d'erreur "Identifiant du message non valide" (comportement normal).
Le fournisseur réessaye le même SR avec l'ID "1234".
L'ID "1234" est toujours introuvable dans la base de données.
Le connecteur comptabilise 2 erreurs ID non valide pour cet ID, de sorte qu'il envoie DELIVER_SM_RESP "OK", même s'il n'a pas été traité correctement.
Cette fonctionnalité est destinée à vider les tampons SR côté fournisseur lorsque des blocs SR non valides sont légitimes pour que les messages ne puissent pas être traités.

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

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

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

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

Ne pas modifier : l'ID est stocké tel quel dans la base de données, sous la forme de texte encodé en ASCII. Aucun prétraitement ni filtrage n'est effectué.
Nombre décimal : l'ID doit être un nombre décimal au format ASCII. Les espaces de début et de fin et les zéros de début sont supprimés lorsque ce paramètre est utilisé.
Nombre hexadécimal : l'ID doit être un nombre hexadécimal au format ASCII, sans 0x ni h à la fin.L'ID est ensuite converti en nombre décimal avant d'être stocké dans la base de données.
Chaîne hexadécimale : l'ID doit être un texte encodé en ASCII qui est lui-même une chaîne d'octets encodés en hexadécimal. Par exemple, dans le PDU, vous trouverez 0x34 0x31 0x34 0x32 0x34 0x33, qui se traduit par "414243" en ASCII. Cette chaîne est alors décodée sous la forme d'une chaîne hexadécimale d'octets et vous obtenez "ABC" en conséquence : vous stockerez l'ID "ABC" dans la base de données.

Format de l'ID dans le 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

NOTE

Disponible uniquement dans le connecteur SMPP étendu Adobe Campaign Classic.

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

IMPORTANT

Vous pouvez uniquement capturer les champs facultatifs contenant des valeurs de texte (ASCII/UTF-8). En particulier, les champs binaires ne peuvent pas être capturés de manière fiable avec le système d'expressions régulières actuel.

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

IMPORTANT

Dans Adobe Campaign Classic et avec une architecture hybride, l’application d’une réponse automatique pour le connecteur SMPP étendu nécessite l’ajout d’un accès en écriture pour l’opérateur mid sur le dossier Compte externe.

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.

IMPORTANT

Le paramètre d'envoi du numéro de téléphone complet a un impact sur le comportement du mécanisme de quarantaine de réponse automatique : si l'envoi du numéro de téléphone complet n'est pas vérifié, le numéro de téléphone mis en quarantaine sera précédé d'un signe plus ("+") afin de le rendre compatible avec le format de numéro de téléphone international.

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

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

À partir du champ

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

Nombre maximal de SMS par message

Ce paramètre ne fonctionne que si le paramètre Payload du message est désactivé. 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

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.

L'option Non spécifié n'envoie aucun champ facultatif dans le PDU.
Flash définit la valeur sur 1. Cela envoie un message Flash qui s'affiche sur le mobile et n'est pas stocké en mémoire.
Normal définit la valeur sur 0. Cela envoie un message normal.
Enregistrer sur mobile définit la valeur sur 2. Cela dit au téléphone de stocker le SMS dans la mémoire interne.
Enregistrer sur le terminal définit la valeur sur 3. Cela indique au téléphone de stocker le SMS dans la carte SIM.

Période de validité

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

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

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 :

Colonnes mises à jour lorsqu'un MT est envoyé et fait l'objet d'un accusé de réception : iBroadLogId, iDeliveryId
Colonnes mises à jour lors de la réception d'un SR : iMsgId, iStatus
Colonnes toujours mises à jour : tsCreated, sProviderId

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 :

La ligne complète est lue.
Le processus SMS calcule le nom de la table de broadlog en fonction du mapping de diffusion.
Le processus SMS met à jour la table du broadlog avec l'identifiant du message et l'état.

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.

Avant la mise en ligne

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

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.

Si 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

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 l'Assistance clientèle d'Adobe de vous aider.

Tester votre SMS

Envoyer des SMS avec toutes sortes de caractères
Si vous devez envoyer des SMS avec des caractères non GSM ou non ASCII, essayez d'envoyer des messages avec autant de caractères différents que possible. Si vous définissez un tableau de mapping de caractères personnalisé, envoyez au moins un SMS pour toutes les valeurs data_coding possibles.
Vérifier que les SR sont correctement traités
Le SMS doit être marqué comme reçu dans le log de diffusion. Le journal de diffusion ne doit pas rencontrer de problème et se présenter comme suit :
SR yourProvider stat=DELIVRD err=000|#MESSAGE
Vérifiez que vous avez modifié le nom du fournisseur de diffusions. Le log de diffusion ne doit jamais contenir SR Generic sur les environnements de production.
Vérifier que les MO sont traités
Si vous devez traiter les MO (réponses automatiques, stockage de MO dans la base de données, etc.), essayez de procéder à des tests. Envoyez quelques SMS pour tous les mots-clés de réponse automatique et vérifiez si la réponse est assez rapide, pas plus de quelques secondes.
Archivez le journal auquel Adobe Campaign répond avec un DELIVER_SM_RESP réussi (command_status=0).

Vérifier les PDU

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

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

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

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 :

Vérifiez que data_coding est correct, 0 par défaut.
Vérifiez que short_message est correctement encodé. Essayez de le décoder à l'aide d'un convertisseur hexadécimal qui prend en charge plusieurs encodages.

Avec le SUBMIT_SM_RESP PDU :

Vérifiez qu'il a réussi, command_status = 0.
Vérifiez que son corps contient un ID correctement formaté suivi d'un octet "0".

Avec le DELIVER_SM PDU :

Décodez le champ hexadécimal short_message.
Vérifiez avec un outil de vérification d'expression régulière que l'expression régulière définie dans l'expression régulière Extraction de l'identifiant dans le SR renvoie exactement un groupe de capture et qu'il capture l'identifiant entier dans le message.
Vérifiez que l'ID extrait correspond à celui dans SUBMIT_SM_RESP.
Vérifiez que l'expression régulière définie dans l'expression régulière Extraction du statut dans le SR renvoie le contenu du champ "stat".
Vérifiez que l'expression régulière définie dans l'expression régulière Extraction de l'erreur dans le SR renvoie le contenu du champ "err".

Avec le DELIVER_SM_RESP PDU :

Vérifiez qu'il a été envoyé rapidement après avoir reçu le DELIVER_SM PDU, généralement moins d'une seconde.
Vérifiez qu'il a réussi, command_status = 0.

Vérifiez auprès de votre fournisseur

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

Désactiver les traces SMPP de 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.

recommendation-more-help