Protocollo e impostazioni del connettore SMS

NOTA

Il protocollo e le impostazioni del connettore SMS per Adobe Campaign Classic si trovano in questa pagina.

In questo documento, tutti i riferimenti a dettagli sul protocollo, nomi e valori dei campi fanno riferimento alla specifica SMPP 3.4.

Panoramica

SMS potrebbe essere limitato all'invio di messaggi di testo brevi senza formattazione, ma la sua semplicità lo rende un canale di comunicazione prezioso.

Esistono due modi principali per inviare un SMS:

  • Inviatelo manualmente da un telefono, il modo usuale per comunicare direttamente tra le persone.

  • Inviatelo da Internet, come Adobe Campaign invia messaggi. Per questo, è necessario un provider di servizi SMS che connetta Internet alla rete mobile.
    Adobe Campaign utilizza il protocollo SMPP per inviare SMS a un provider di servizi.

Questo documento illustra la connessione impostata tra Adobe Campaign e un provider SMPP.

I fornitori SMPP a volte possono deviare dalle specifiche ufficiali, ma il connettore SMS in Adobe Campaign offre molte opzioni per adattare il suo comportamento affinché sia compatibile con la maggior parte dei fornitori.

IMPORTANTE

La configurazione di una connessione a un nuovo provider potrebbe richiedere alcune competenze tecniche, conoscenza di TCP, binario, rappresentazione esadecimale e codifiche di testo. Sarà inoltre necessaria una collaborazione attiva con il fornitore.

Tipi di SMS

Quando si invia SMS di massa attraverso un fornitore di SMS, si incontreranno tre diversi tipi di SMS:

  • SMS MT (Mobile Terminated): un SMS emesso da Adobe Campaign verso i telefoni cellulari tramite il provider SMPP.

  • SMS MO (Mobile Originato): un SMS inviato da un dispositivo mobile a Adobe Campaign tramite il provider SMPP.

  • SMS SR (Stato Report), DR o DLR (Consegna consegna): una ricevuta di ritorno inviata dal dispositivo mobile a Adobe Campaign tramite il provider SMPP per indicare che l'SMS è stato ricevuto correttamente. Adobe Campaign potrebbe inoltre ricevere SR che indica che il messaggio non è stato recapitato, spesso con una descrizione dell'errore.

È necessario distinguere tra riconoscimenti (RESP PDU, parte del protocollo SMPP) e SR: SR è un tipo di SMS che viene inviato attraverso la rete end-to-end, mentre un riconoscimento è solo una conferma che un trasferimento ha avuto successo.

Entrambi i riconoscimenti e i SR possono causare errori, distinguendo tra i due aiuterà a risolvere i problemi.

Informazioni trasportate da un SMS

Un SMS contiene più informazioni che testo. Di seguito è riportato un elenco di ciò che ci si può aspettare in un SMS:

  • Il testo, che è limitato a 140 byte, ovvero tra 70 e 160 caratteri a seconda della codifica. Per informazioni dettagliate e limitazioni, vedere Codifica di testo SMS di seguito.

  • Un indirizzo destinatario, a volte denominato ADC o MSISDN. Questo è il numero del cellulare che riceverà l'SMS.

  • Un indirizzo del mittente, che può essere chiamato oADC o a volte sender id. Può trattarsi di un numero di telefono utilizzato giorno per giorno, di un codice breve inviato tramite un provider o un nome. Nome è una funzione opzionale, in tal caso non è possibile rispondere all'SMS.

  • Flag che indica se il messaggio è un messaggio Flash. Un messaggio Flash è un messaggio pop-up che non è memorizzato nella memoria.

  • Flag che indica se un SR è previsto o meno.

  • Una data di validità, dopo la quale non è consentito riprovare alcuna attrezzatura di rete.

  • Un campo data_coding che indica la codifica del testo.

Protocollo SMPP

Adobe Campaign Standard supporta il protocollo SMPP versione 3.4. Si tratta di un protocollo diffuso che consente l'invio di SMS a un provider (SMSC), la ricezione di SMS e ricevute. Per ulteriori informazioni, consultare la documentazione SMPP.

Le apparecchiature di rete sul lato del fornitore di servizi di SMS sono spesso chiamate SMSC.

Connessioni SMPP

Adobe Campaign si collega alle apparecchiature di rete del provider di servizi SMS tramite TCP. Il protocollo SMPP imposta connessioni TCP permanenti da Adobe Campaign al provider. Le connessioni TCP vengono sempre avviate da Adobe Campaign, anche per ricevere messaggi.
SMPP apre 1 o 2 connessioni TCP, a seconda della modalità. Tutte le connessioni sono sempre avviate da Adobe Campaign.

Il protocollo SMPP può funzionare in due modalità:

  • Trasmettitore+ricevitore (o TX+RX): per la trasmissione e la ricezione dei messaggi vengono utilizzate due diverse connessioni TCP.
  • Ricetrasmettitore (ABOR TRX): per la trasmissione e la ricezione dei messaggi viene utilizzata una singola connessione TCP.
NOTA

TRX è ideale per Adobe Campaign Standard, poiché riduce il numero di connessioni e semplifica il recupero delle connessioni in caso di guasto.

PDU SMPP

Le unità di trasmissione SMPP ("pacchetti") sono denominate PDU. Un PDU contiene un comando, uno stato, un numero di sequenza e dati.

Ciascuna PDU deve essere riconosciuta da un SMPP RESP PDU (risposta sincrona). Le richieste possono essere inoltrate: il mittente può inviare molti comandi senza attendere RESP, il numero di richieste che possono essere inoltrate in qualsiasi momento è chiamato finestra. RESP PDU possono arrivare in qualsiasi ordine, non collegato all'ordine della corrispondente PDU iniziatore.

Nella modalità Trasmettitore+ricevitore separata, la connessione utilizzata dipende dal tipo di messaggio trasmesso. La connessione del trasmettitore viene utilizzata per MT e la connessione del ricevitore viene utilizzata per MO e SR. Richieste e risposte per ogni tipo di messaggio vengono inviate attraverso la stessa connessione TCP.

Ad esempio, quando si invia un MT, viene utilizzata la connessione del trasmettitore e la RESP che riconosce che il MT viene inviato anche attraverso il canale del trasmettitore. Quando si riceve un MO (o un SR), la connessione del ricevitore viene utilizzata per ricevere il MO e inviare il RESP che riconosce il MO.

In Adobe Campaign Standard, MT e SR la riconciliazione è nativa dell'MTA, quindi non c'è un processo SMS dedicato.

Un SUBMIT_SM_RESP PDU riuscito attiva lo stato del messaggio "inviato" nel registro di invio mentre un DELIVER_SM (SR) PDU riuscito attiva lo stato del messaggio "ricevuto".

Aspetti di sicurezza

Il protocollo stesso non è crittografato. La maggior parte dei provider implementa una variante di IP inserire nell'elenco Consentiti, pertanto gli indirizzi IP del server Adobe Campaign devono essere dichiarati al provider.

Adobe Campaign supporta il passaggio di un login e una password durante la fase di binding. Supporta inoltre SMPP su TLS. Va notato che i certificati sono richiesti per una sicurezza adeguata. Anche se il connettore SMPP consente di bypassare i controlli dei certificati, dovrebbe essere utilizzato solo per il test, dal momento che TLS senza certificati fornisce un livello di protezione significativamente inferiore.

Il connettore utilizza i certificati predefiniti forniti dalla libreria di sistema openssl. Di solito è fornito dalla directory /etc/ssl/certs su Debian. Questa directory viene fornita per impostazione predefinita dal pacchetto "ca-certificates", ma può essere personalizzata.

Informazioni in ogni tipo di PDU

Ogni tipo di PDU ha campi distinti che contengono informazioni diverse. Queste PDU sono descritte dettagliatamente nella specifica SMPP 3.4.

Ogni sezione seguente descrive sia la PDU che la risposta sincrona (*_RESP PDU). Tutte le PDU devono essere riconosciute da una RESP corrispondente, che è una parte obbligatoria della specifica.

Le PDU possono avere campi facoltativi. Qui sono descritti solo i campi più comuni. Per ulteriori informazioni, fare riferimento alla specifica SMPP 3.4.

BIND_TRANSMITTER / BIND_RECEIVER / BIND_TRANSCEIVER

Questa PDU viene utilizzata per avviare una connessione con SMSC. Trasmettitore, ​Ricezione e ​Trasmettitori cambia solo il tipo di SMS consentito per il trasferimento su questa connessione, in particolare:

Modalità Tipi di SMS consentiti
Trasmettitore MT
Ricevitore MO + SR
Ricetrasmettitore MT + MO + SR

Campi di rilievo in BIND_* PDU:

  • system_id: Login utilizzato per l'autenticazione. Impostato nell’account esterno.

  • password: Password utilizzata per l'autenticazione. Impostato nell’account esterno.

  • system_type: Obbligatorio per essere impostato su un valore specifico per alcuni provider. Impostato nell'account esterno, disponibile in tutte le versioni. Spesso distingue tra diversi tipi di contratti, canali, paesi, ecc.

  • addr_ tonand addr_npi: Richiesto da alcuni provider. Impostato dalle impostazioni Bind TON e Bind NPI nell'account esterno.

  • address_range: Richiesto da alcuni provider. Nella maggior parte dei casi, si tratta di un elenco di codici di scelta rapida consentiti in questa connessione. Impostato nell’account esterno.

BIND_*_RESP non ha un campo specifico, conferma se la connessione è stata eseguita correttamente o meno.

UNBIND

La PDU deve essere inviata dal sistema prima della disconnessione. Prima di chiudere la connessione, è necessario attendere la corrispondenza UNBIND_RESP PDU.

La connessione SMSC conforme non deve essere chiusa. La connessione TCP è controllata dal connettore Adobe Campaign .

SUBMIT_SM

Questa PDU invia un MT al SMSC. La sua PDU di risposta fornisce l'ID del MT.

Campi di rilievo in SUBMIT_SM PDU:

  • service_type: richiesto da alcuni fornitori. Impostate le proprietà di consegna.

  • source_addr_ tonand source_addr_npi: indica il tipo di indirizzo di origine trasmesso. Il significato di questi campi è standardizzato, ma poiché alcuni fornitori li utilizzano in modo diverso, è necessario chiedere al provider il valore corretto. Impostato nell’account esterno.

  • source_addr: l'indirizzo di origine / oADC del MT. Verrà visualizzato sul cellulare. Impostato nel conto esterno e nella consegna, il valore nella consegna ha la precedenza sul valore del conto esterno.

  • dest_addr_ tonand dest_addr_npi: indica quale tipo di indirizzo di destinazione viene trasmesso (ad esempio, formato locale o internazionale). Il significato di questi campi è standardizzato, ma poiché alcuni fornitori li utilizzano in modo diverso, è necessario chiedere al provider il valore corretto. Impostato nell’account esterno.

  • Destination_addr: indirizzo del destinatario, numero di telefono o MSISDN.

  • esm_class: utilizzato per indicare se l'UDH è utilizzato o meno nel campo di testo. Abilitato automaticamente dal connettore per SMS diviso se la modalità message_payload non è utilizzata.

  • priority_flag: priorità di questo messaggio rispetto agli altri. Ciò è legato alla priorità della consegna stessa.

  • validation_period: marca temporale dopo la quale non è necessario tentare alcun tentativo. Impostato nella consegna stessa.

  • registrato_delivery: indica se una SR è richiesta o meno. Adobe Campaign imposta sempre questo flag, ad eccezione delle risposte automatiche. Per i messaggi multiparte, il flag è impostato solo per la prima parte. Tutte le versioni hanno lo stesso comportamento.

  • data_coding: indica la codifica utilizzata nel campo di testo. Per ulteriori informazioni, vedere la sezione Codifica di testo SMS.

  • short_message: il testo del messaggio. Se viene utilizzato UDH, questo contiene anche l’intestazione UHD.

Adobe Campaign supporta i seguenti campi facoltativi:

  • dest_addr_subunit: utilizzato per specificare il target dell'SMS: scheda flash, mobile o SIM. Impostate le proprietà di consegna.

  • message_payload: se attivato nell'account esterno, i messaggi lunghi saranno inviati in un'unica PDU e il testo verrà trasmesso in questo campo anziché nel short_message campo.

SUBMIT_SM_RESP

La PDU conterrà l'ID del MT. Questo è utile per abbinarlo con SR in ingresso.

IMPORTANTE

Molti provider trasmettono l’ID MT in formato esadecimale. Accertatevi di impostare correttamente il formato ID in corrispondenza MT nell'account esterno.

Alcuni fornitori inviano SUBMIT_SM_RESP dopo l'invio dell'SR. Per tenere conto di tale comportamento, Adobe Campaign attende 30 secondi prima di rispondere a ID messaggio non valido a un SR con un ID sconosciuto.

DELIVER_SM

Il PDU viene inviato da SMSC a Adobe Campaign. Contiene un MO o una SR.

La maggior parte dei campi ha lo stesso significato della controparte SUBMIT_SM. Elenco di campi utili:

  • source_addr: indirizzo di origine del MO/SR. Di solito questo è un numero di telefono.

  • Destination_addr: codice breve che ha ricevuto il MO o la SR.

  • esm_class: utilizzato per indicare se la PDU è un MO o un SR.

  • short_message: testo del messaggio. Per SR, questo contiene i dati descritti nell'appendice B della specifica del protocollo SMPP. Per ulteriori informazioni, vedere Gestione errori SR.

Adobe Campaign è in grado di leggere l'ID del messaggio nel campo opzionale receipted_message_id con alcune impostazioni di configurazione.

DELIVER_SM_RESP

Questa PDU viene inviata da Adobe Campaign per confermare SR e MO.

Adobe Campaign Standard invia un DELIVER_SM_RESP solo una volta che tutte le fasi di elaborazione sono state completate correttamente. Ciò garantisce che non venga riconosciuta alcuna SR o MO mentre esiste ancora il rischio di errori di elaborazione.

Questa PDU viene utilizzata solo per verificare che la connessione sia attiva. La sua frequenza deve essere fissata in base alle esigenze del fornitore.

I 60 secondi predefiniti devono corrispondere alla maggior parte delle configurazioni impostate nell'account esterno.

Questa PDU riconosce che la connessione è attiva.

SMS multiparte (SMS esteso)

Gli SMS multiparte, o gli SMS lunghi, sono SMS inviati in più parti. A causa di limiti tecnici nel protocollo di rete mobile, un SMS non può essere maggiore di 140 byte o dovrà essere suddiviso. Per ulteriori informazioni sul numero di caratteri che possono essere inclusi in un SMS, vedere la sezione Codifica di testo SMS.

Ogni parte di un lungo messaggio è un singolo SMS. Queste parti viaggiano in modo indipendente sulla rete e sono assemblate dal telefono cellulare ricevente. Per gestire i tentativi e i problemi di connettività, Adobe Campaign invia queste parti in ordine inverso e richiede un SR solo per la prima parte del messaggio, l'ultimo inviato. Poiché il telefono cellulare visualizza un messaggio solo quando viene ricevuta la prima parte, i tentativi su parti aggiuntive non generano duplicati sul telefono cellulare.

Il numero massimo di SMS per messaggio può essere impostato per consegna utilizzando l'impostazione Numero massimo di SMS per messaggio nel modello di consegna. I messaggi che superano questo limite non riusciranno durante l'invio con un SMS per un motivo di errore troppo lungo.

Ci sono 2 modi per inviare SMS lunghi:

  • UDH: il modo predefinito e consigliato per inviare messaggi lunghi. In questa modalità, il connettore divide il messaggio in più SUBMIT_SM PDUs con le informazioni UDH al loro interno. Questo protocollo è quello utilizzato dagli stessi telefoni cellulari. Ciò significa che Adobe Campaign ha il maggior controllo sulla generazione dei messaggi, rendendola in grado di calcolare esattamente quante parti sono state inviate e come sono state divise.

  • message_payload: il modo di inviare l'intero lungo messaggio in un solo SUBMIT_SM PDU. Il fornitore dovrà dividerlo, il che significa che è impossibile per Adobe Campaign sapere esattamente quante parti sono state inviate. Alcuni fornitori richiedono questa modalità, ma consigliamo di utilizzarla solo se non supportano UDH.

Per ulteriori informazioni sul protocollo e i formati, vedere la descrizione dei campi esm_class, short_message e message_payload della SUBMIT_SM PDU.

Limite di carico e finestra

La maggior parte dei fornitori richiede un limite di throughput per ogni connessione SMPP. Questo può essere ottenuto impostando un numero di SMS nell'account esterno. Si noti che la velocità di trasmissione avviene per connessione, la velocità effettiva totale è il limite per connessione moltiplicato per il numero totale di connessioni. Questo è illustrato nella sezione Connessioni simultanee.

Per raggiungere la massima velocità possibile, dovrete regolare la finestra massima di invio. La finestra di invio è il numero di SUBMIT_SM PDUs che possono essere inviati senza aspettare un SUBMIT_SM_RESP. Per ulteriori informazioni, vedere la sezione Impostazione della finestra di invio.

SR e gestione degli errori ("Appendice B")

Il protocollo SMPP definisce gli errori sincroni standard in RESP PDUs, ma non definisce i codici di errore per SR. Ogni provider utilizza i propri codici di errore con il proprio significato.

Una raccomandazione è fatta nella sezione Appendice B della specifica del protocollo SMPP (pagina 167), ma non elenca i codici di errore effettivi né il loro significato.

Per adattarsi alla gestione degli errori, il sistema di trasmissione dei messaggi di Adobe Campaign è stato sfruttato per fornire correttamente gli errori e la loro gravità (duro, morbido, ecc.).

Come già detto, vi sono due tipi diversi di errori:

  • risposte sincrone nella SUBMIT_SM_RESP che si verificano immediatamente dopo l'invio del messaggio all'SMSC
  • le ricevute che potrebbero essere visualizzate più tardi quando il dispositivo mobile ha ricevuto il messaggio o quando il messaggio è scaduto. In tal caso l'errore si trova in un SR.

Quando viene ricevuta una SR, lo stato e l'errore si trovano nel relativo campo short_message (ad esempio per le implementazioni conformi all'appendice B). Il campo short_message della PDU è spesso denominato campo di testo poiché contiene testo in MT. In caso di SR, contiene informazioni tecniche più un sottocampo denominato Text. Questi due campi sono diversi e short_message contiene effettivamente il campo Text e altre informazioni.

Formato del campo di testo SR

Si consiglia di utilizzare questo formato per il campo di testo SR. Si tratta di un elenco di campi secondari, separati da spazi con due punti per separare il nome del campo e il relativo valore. I nomi dei campi non fanno distinzione tra maiuscole e minuscole.

Esempio di un campo di testo SR che corrisponde alla raccomandazione dell'appendice B:

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

Il campo id è l'ID ricevuto nella SUBMIT_SM_RESP PDU, la conferma dell'MT.

sub e dlvrd devono contare la quantità di parti consegnate e di messaggi consegnati, ma questo non viene utilizzato da Adobe Campaign, dal momento che il sistema di trasmissione offre informazioni migliori e più integrate.

submit date e done date i campi sono marche temporali indicative di quando il MT è stato inviato e quando l'SR è stato inviato dal cellulare. Ci si aspetta qualche problema con i fusi orari o anche con marche temporali errate date da cellulari con data non corretta.

Il campo stat è importante perché indica lo stato del messaggio. L'unico stato importante sono DELIVRD, UNDELIV e REJECTD. Lo stato DELIVRD indica un esito positivo, mentre gli altri due indicano un errore. Altri valori sono possibili, ma di solito sono notifiche intermedie, ad esempio il MT ha raggiunto il vettore mobile, ma non il cellulare. Queste notifiche intermedie vengono ignorate da Adobe Campaign.

Il campo err contiene il codice di errore specifico del provider. Il provider deve fornire una tabella di possibili codici di errore con il relativo significato per essere in grado di interpretare questo valore.

Infine, il campo di testo in genere contiene l'inizio del testo del MT. Questo viene ignorato da Adobe Campaign e alcuni fornitori non lo trasmettono per evitare perdite di PII e il consumo di larghezza di banda della rete. Può essere utilizzato durante la risoluzione dei problemi per individuare più facilmente la SR che corrisponde a un MT di prova leggendo questo campo.

Esempio di elaborazione SR in Adobe Campaign Standard Extended SMPP generico

In questo esempio viene visualizzato il caso di un'implementazione successiva alla raccomandazione Appendice B, i valori predefiniti nell'account esterno e un SMS MT con esito positivo.

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

Innanzitutto, il regex id extraction viene applicato per estrarre l'ID e riconciliarlo con il MT corrispondente.

Quindi, i campi status extraction regex e error code extraction regex vengono applicati per estrarre questi campi e aggiunti alla stringa.

Il messaggio di broadcast viene creato con queste informazioni e la stringa originale non modificata viene aggiunta come riferimento:

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

Il messaggio viene quindi normalizzato, rimuovendo la parte MESSAGE per essere in grado di far corrispondere più messaggi con gli stessi codici di stato e di errore.

SR ExampleProvider DELIVRD 000|#MESSAGE#

Se il messaggio non è già stato fornito nella tabella dei messaggi di trasmissione, verrà creata una nuova voce utilizzando l'intero messaggio come firstText e il messaggio normalizzato. Quindi, il connettore utilizza il formato success e error regex per determinare se si è trattato di un esito positivo o negativo:

  • Se corrisponde al regex success, verrà considerato un successo.

  • Se corrisponde al regex error, il messaggio viene qualificato come errore.

  • Se nessuno di questi due regex corrisponde, l'SR viene ignorato. Potrebbe trattarsi di una notifica intermedia, che non viene gestita da Adobe Campaign.

Per impostazione predefinita, tutti gli errori vengono forniti come errori software. Ciò significa che gli errori gravi devono essere forniti a mano.

Codifica di testo SMS

È necessario contattare sempre il provider SMSC in caso di problemi di codifica. Solo i fornitori SMSC hanno una conoscenza precisa della codifica che supportano e regole speciali che possono essere applicate a causa di limitazioni nella loro piattaforma tecnica.

I messaggi SMS utilizzano una codifica speciale a 7 bit, spesso denominata codifica GSM7.

Nel protocollo SMPP, il testo GSM7 verrà espanso a 8 bit per carattere per facilitare la risoluzione dei problemi. SMSC lo impacchetterà in 7 bit per carattere prima di inviarlo al dispositivo mobile. Ciò significa che il campo short_message dell'SMS può avere una lunghezza massima di 160 byte nel frame SMPP, mentre è limitato a 140 byte quando viene inviato sulla rete mobile.

In caso di problemi di codifica, è necessario verificare alcuni aspetti importanti:

  • Accertatevi di sapere quali caratteri appartengono a quale codifica. GSM7 non supporta completamente i segni diacritici (accenti). Specialmente in francese, dove é ed è fanno parte del GSM7, ma ê, o ï no. Lo stesso vale per lo spagnolo.

  • Il C con cedilla (ç) è presente solo in lettere maiuscole nell’alfabeto GSM7, ma alcuni telefoni lo rendono in lettere minuscole o "smart". La raccomandazione generale è di evitarlo completamente e rimuovere il cedilla o passare a UCS-2.

  • Non utilizzare ASCII in SMS, a meno che non sia espressamente richiesto dal provider SMSC. Questa codifica consente di sprecare spazio perché contiene caratteri a 8 bit e una copertura inferiore rispetto a GSM7. Questa codifica può essere necessaria per le reti CDMA, utilizzate in America del Nord.

  • Latin-1 non è sempre supportato. Verificare la compatibilità con il provider SMSC prima di tentare di utilizzare Latin-1.

  • Le tabelle di spostamento della lingua nazionale non sono supportate dal connettore Adobe Campaign . È necessario utilizzare UCS-2 o altro data_coding.

  • UCS-2 e UTF-16 sono spesso mescolati dai telefoni. Questo è un problema quando si utilizzano emoji e altri caratteri non presenti nell'UCS-2.

  • La maggior parte dei telefoni non dispone di glifi di font per tutti i caratteri UCS-2. Gli smartphone tendono ad essere in grado di visualizzare caratteri rari piuttosto facilmente, ma i telefoni cellulari con caratteristiche generalmente hanno un supporto limitato a ciò che è utile nella lingua nativa del paese in cui sono stati acquistati. Se desiderate utilizzare emoji o ASCII-art, testatela su un'ampia varietà di telefoni prima di inviarla. anteprima Adobe Campaign non simula i glifi mancanti e visualizzerà i simboli disponibili nel browser Web.

Il campo data_coding indica la codifica utilizzata. Un problema importante è che il valore 0 indica la codifica SMSC predefinita nella specifica, che in genere si riferisce a GSM7. Verificare con il partner SMSC quale codifica è associata a data_coding = 0 che solo Adobe Campaign supporta. Altri valori data_coding tendono a seguire la specifica, ma l'unico modo per essere certi è di controllare con il provider SMSC.

La dimensione massima di un messaggio dipende dalla codifica. Questa tabella riassume tutte le informazioni pertinenti:

Codifica Solito data_coding Dimensione del messaggio (caratteri) Dimensioni parte per SMS multiparte Caratteri disponibili
GSM7 0 160 152 GSM7 set di caratteri di base + estensione (i caratteri estesi prendono 2 caratteri)
Latin-1 3 140 134 ISO-8859-1
UCS-2
UTF-16
8 70 67 Unicode (varia da telefono a telefono)

Parametri del conto esterno SMPP

Ogni implementazione del protocollo SMPP presenta numerose variazioni. Per migliorare la compatibilità e l'adattabilità, sono disponibili diverse impostazioni per modificare il comportamento del connettore SMPP. Questa sezione descrive ogni parametro e i relativi effetti sul connettore.

Parametri generali e routing

Limita le istanze MTA per l'account

È possibile impostare un limite al numero di istanze MTA consentite per connettersi al provider SMPP. Se questa opzione è selezionata, potete specificare il numero massimo di MTA utilizzabili.

Questa opzione consente un controllo più preciso del numero di connessioni, vedere Connessioni simultanee.

Se imposti un valore maggiore del numero di MTA in esecuzione, tutti i MTA verranno eseguiti normalmente: questa opzione è solo un limite e non può generare ulteriori MTA.

Se è necessario controllare con precisione il numero di connessioni, ad esempio il requisito del fornitore, si consiglia di impostare sempre questa opzione anche se la distribuzione corrente ha il numero corretto di MTA in esecuzione. Se successivamente verranno aggiunte ulteriori MTA, il limite di connessione sarà comunque rispettato.

Impostazioni di connessione

Modalità di connessione SMPP

Imposta la connessione in modalità trasmettitore o in modalità trasmettitore+ricevitore separata. Quando si passa alla modalità trasmettitore+ricevitore separata, le impostazioni nella sezione modalità di connessione SMPP si applicano al trasmettitore e le impostazioni nella sezione Impostazioni connessione ricevitore si applicano alla connessione del ricevitore, solo se è stata selezionata la casella Usa parametri diversi per il ricevitore.

Nome implementazione SMSC

Definisce il nome dell'implementazione SMSC. Deve essere impostato sul nome del provider. Contatta l’amministratore o il team di recapito per sapere cosa aggiungere in questo campo. Il ruolo di questo campo è descritto nella sezione Gestione errori SR.

Server

Nome DNS o indirizzo IP del server a cui connettersi.

Porta

La porta TCP a cui connettersi.

Account

Login della connessione. Trasmesso nel campo system_id della PDU BIND.

Password

Password della connessione SMPP. Trasmesso nel campo password della BIND PDU.

Tipo di sistema

Valore passato nel campo system_id della PDU BIND. Alcuni fornitori necessitano di un valore specifico.

Connessioni simultanee

In Adobe Campaign Standard, definisce il numero di connessioni per thread SMS e per processo MTA.
Il numero di processi MTA è determinato dalla distribuzione: di solito ci sono 2 MTA e 1 filo. Il numero di thread può essere modificato nel file config-instance.xml utilizzando l'impostazione smppConnectorThread. Di solito c'è 1 processo MTA per contenitore e 1 thread per processo MTA.

Formula di connessioni totali per Adobe Campaign Standard:

  • Connessioni totali = Connessioni simultanee * numero di thread * numero di MTA

Le connessioni simultanee sono impostate nell'account esterno, il numero di thread è impostato nel file config-instance.xml (smppConnectorThread) e il numero di MTA può essere limitato nell'account esterno.

In modo separato trasmettitore/ricevitore, il numero di connessioni sopra riportato rappresenta il numero di coppie trasmettitore/ricevitore, il che significa che ci sarà il doppio del numero di connessioni in totale.

Abilita TLS su SMPP

Utilizzate TLS per la connessione al provider. La connessione sarà crittografata. La connessione TLS è gestita dalla libreria OpenSSL, tutto ciò che è applicabile a OpenSSL è vero per questa connessione.

Abilitare tracce SMPP dettagliate nel file di registro

Questa impostazione scarica tutto il traffico SMPP nei file di registro. Spesso è necessario regolare i parametri durante la configurazione iniziale. Questa opzione deve essere abilitata per la risoluzione dei problemi relativi al connettore e confrontata con il traffico visualizzato dal provider.

Impostazione connessione ricevitore

Questa sezione è visibile solo in modalità trasmettitore+ricevitore separata.

Utilizzare parametri diversi per il ricevitore

Quando la casella è deselezionata, le stesse impostazioni vengono utilizzate per il trasmettitore e il ricevitore.

Quando la casella è selezionata, le impostazioni della sezione Impostazioni di connessione si applicano al trasmettitore e le impostazioni della Connessione ricevitore si applicano al ricevitore.

Server di ricezione, porta, account, password, tipo di sistema

Queste impostazioni si applicano al ricevitore in modalità trasmettitore+ricevitore. Funzionano come la parte del trasmettitore, vedi sopra per maggiori dettagli.

Impostazioni canale SMPP

Consenti traslitterazione caratteri

Transliteration è il processo di ricerca di caratteri equivalenti a quelli mancanti. Ad esempio, il carattere francese "ê" (con accento circonflesso) non è presente nella codifica GSM, ma può essere sostituito da "e" senza compromettere la leggibilità.

Se questa casella è deselezionata, la codifica del testo non riuscirà se non sarà in grado di codificare la stringa esattamente come è.

Quando questa casella è selezionata, la codifica del testo tenterà di convertire la stringa in una versione approssimativa anziché in errore. Se alcuni caratteri non hanno un equivalente nella codifica di destinazione, la codifica del testo non riuscirà.

Per una spiegazione più generale del processo di codifica, vedere Definire una mappatura specifica delle impostazioni di codifica.

Archiviare l'MO in entrata nel database

Se abilitata, la MO in entrata verrà memorizzata nella tabella inSMS del database. Questa tabella può essere interrogata utilizzando l'attività di query di qualsiasi flusso di lavoro.

Abilitare gli aggiornamenti KPI in tempo reale durante l'elaborazione SR

Se attivato, i KPI verranno aggiornati in tempo reale sulla pagina di consegna principale quando viene visualizzato un SR di errore.

L'inconveniente può essere a basse prestazioni a causa del contenzioso del database generato. Se disabilitata, le statistiche vengono aggiornate dal flusso di lavoro syncfromexec, che viene eseguito ogni 20 minuti.

Numero di origine

Definisce l'indirizzo di origine predefinito per i messaggi. Questa impostazione è valida solo se il numero di origine è rimasto vuoto nella consegna.

Per impostazione predefinita, il campo relativo al numero di origine non viene passato, pertanto il provider lo sostituirà al codice breve.

Questo abilita la funzione di sostituzione indirizzo del mittente/oADC.

Codice breve

Indica il codice breve principale del conto. Se per questo account sono utilizzati più codici brevi o se il codice breve è sconosciuto, lasciare vuoto questo campo.

La specifica del codice breve è utile per due funzioni:

  • Nell'anteprima viene visualizzato il codice breve se non viene fornito alcun numero di origine. Rifletterà il comportamento reale sul cellulare.

  • L'impostazione di elenco Bloccati della funzione di risposta automatica invia solo all'utente la quarantena per un codice breve specifico.

Origine TON/NPI, destinazione TON/NPI

TON (Tipo di numero) e NPI (Indicatore del piano di numerazione) sono descritti nella sezione 5.2.5 della specifica SMPP 3.4 (pagina 117). Questi valori devono essere impostati in base alle esigenze del provider.

Vengono trasmesse così come sono nei campi source_addr_ton, source_addr_npi, dest_addr_ton e dest_addr_npi di SUBMIT_SM PDU.

Tipo di servizio

Questo campo viene trasmesso così come si trova nel campo service_type della SUBMIT_SM PDU. Impostate questo valore in base alle esigenze del provider.

Throughput e timeout

Queste impostazioni controllano tutti gli aspetti temporali del canale SMPP. Alcuni fornitori richiedono un controllo molto preciso della frequenza dei messaggi, degli orari delle finestre e dei tentativi. Tali impostazioni devono essere impostate su valori che corrispondano alla capacità del fornitore e alle condizioni indicate nel contratto.

Finestra di invio

La finestra è il numero di SUBMIT_SM PDUs che possono essere inviati senza aspettare un SUBMIT_SM_RESP corrispondente.

Esempio di trasmissione con una finestra massima di 4:

La finestra consente di aumentare il throughput quando il collegamento di rete ha una latenza elevata. Il valore della finestra deve essere almeno il numero di SMS/s moltiplicato per la latenza del collegamento in secondi, in modo che il connettore non sia mai in attesa di un SUBMIT_SM_RESP prima di inviare il messaggio successivo.
Se la finestra è troppo grande, è possibile inviare altri messaggi duplicati in caso di problemi di connessione. Inoltre, la maggior parte dei fornitori hanno un limite molto stretto per la finestra e rifiutano i messaggi che oltrepassano il limite.

Come calcolare la formula ottimale della finestra di invio:

  • Misurare la latenza massima tra SUBMIT_SM e SUBMIT_SM_RESP.

  • Moltiplica questo valore in secondi fino al throughput MT massimo. Questo darà il valore ottimale della finestra di invio.

Esempio: Se hai 300 SMS/s impostato in velocità di trasmissione max MT e c'è una latenza di 100 ms tra SUBMIT_SM e SUBMIT_SM_RESP in media, il valore ottimale sarebbe 300×0.1 = 30.

Velocità max MT

Numero massimo di MT al secondo e per connessione. Questa impostazione è rigorosamente applicata, l'MTA non invierà mai i messaggi push più velocemente di questo limite. È utile per i fornitori che richiedono una limitazione precisa.

Per conoscere il limite di throughput totale, moltiplicate questo numero per il numero totale di connessioni come descritto nella formula precedente.

0 significa nessun limite, l'MTA invierà MT il più velocemente possibile.

Si raccomanda in genere di mantenere questa impostazione su 1000, poiché è impossibile garantire una velocità di trasmissione precisa al di sopra di questo numero, a meno che non venga adeguatamente valutata l'architettura finale. Se avete bisogno di un throughput superiore a 1000, contattate il vostro fornitore. Potrebbe essere meglio aumentare il numero di connessioni per superare i 1000 MT/s.

Tempo prima della riconnessione

Se la connessione TCP viene persa, il connettore attenderà questo numero di secondi prima di provare a creare una connessione.

Periodo di scadenza del MT

Timeout tra SUBMIT_SM e la SUBMIT_SM_RESP corrispondente. Se la RESP non viene ricevuta in tempo, il messaggio verrà considerato come non riuscito e verrà applicato il criterio globale dei tentativi dell'MTA.

Timeout associazione

Timeout tra il tentativo di connessione TCP e la risposta BIND_*_RESP. In caso di timeout, la connessione viene chiusa dal connettore Adobe Campaign e prima di riprovare, si attende Tempo.

enquire_link è un tipo speciale di PDU inviato per mantenere la connessione in vita. Questo periodo è in secondi. Il connettore della campagna invia solo enquire_link quando la connessione è inattiva per conservare la larghezza di banda. Se non viene ricevuto alcun RESP dopo il doppio di questo periodo, la connessione verrà considerata morta e verrà attivato un processo di riconnessione.

Specifiche di SMSC

Queste impostazioni sono impostazioni avanzate che adattano il connettore Adobe Campaign alla maggior parte delle peculiarità di implementazione SMPP.

Definire una mappatura specifica delle codifiche

Per informazioni dettagliate sulla codifica del testo, vedere la sezione Codifica testo SMS.

Questa impostazione consente di definire una mappatura di codifica personalizzata, diversa dalla specifica. Sarà possibile dichiarare un elenco di codifiche, insieme al relativo valore data_coding.

L'MTA tenterà di codificare utilizzando la prima codifica nell'elenco. Se non riesce, proverà a utilizzare la codifica successiva nell'elenco, ecc. Se non è possibile utilizzare alcuna codifica per codificare il messaggio, si verificherà un errore. Una volta trovata la codifica, l'MTA creerà il SUBMIT_SM PDU con il testo codificato e il campo data_coding impostato con il valore specificato nella tabella.

L'ordine degli elementi nella tabella è importante: le codifiche sono tentativi dall'alto verso il basso. Si dovrebbe mettere la codifica più economica o quella più consigliata in cima all'elenco, seguita da codifiche sempre più costose.

Tenere presente che UCS-2 non fallirà mai in quanto può codificare tutti i caratteri supportati in Adobe Campaign e che la lunghezza massima di un SMS UCS-2 è molto inferiore: Solo 70 caratteri.

È inoltre possibile utilizzare questa impostazione per applicare a una codifica specifica un utilizzo sempre dichiarando solo 1 riga nella tabella di mappatura.

La mappatura predefinita utilizzata quando la casella di controllo non è selezionata equivale alla tabella seguente:

data_coding Codifica
0 GSM
9 UCS-2

Questo significa che l'MTA cercherà di codificare il messaggio in GSM. Se riesce, lo invierà con data_coding impostato su 0.

Se il messaggio non può essere codificato in GSM, verrà codificato in UCS-2 e verrà impostato su 8 da data_coding.

Abilita message_payload

Se questa opzione è deselezionata, gli SMS lunghi verranno suddivisi dalla MTA e inviati in più SUBMIT_SM PDUs con UDH. Il messaggio sarà ricomposto dal cellulare dopo i dati UDH.

Se questa opzione è attivata, gli SMS lunghi verranno inviati in una delle PDU SUBMIT_SM, inserendo il testo nel campo facoltativo message_payload. Per ulteriori informazioni, vedere la specifica SMPP.

Se questa funzione è attivata, Adobe Campaign non sarà in grado di contare le parti SMS singolarmente: tutti i messaggi saranno conteggiati come inviati in una parte.

Invia il numero di telefono completo

Se questa casella di controllo non è selezionata, vengono inviate al provider solo le cifre del numero di telefono (destination_addr campo del campo SUBMIT_SM). Questo è il comportamento predefinito, in quanto l’indicatore internazionale del numero, in genere il prefisso +, viene sostituito dai campi TON e NPI in SMPP.

Quando la casella di controllo è selezionata, il numero di telefono viene inviato così come è, senza pre-elaborazione e spazi potenziali, + prefisso o cancelletto/hash/stelle segni.

Questa funzione ha anche un effetto sul comportamento della funzione di elenco Bloccati di risposta automatica: se la casella di controllo non è selezionata, ai numeri di telefono inseriti nella tabella di quarantena verrà aggiunto un prefisso + per compensare la rimozione del prefisso + dal numero di telefono da parte del protocollo SMPP stesso.

Ignora controllo certificato TLS

Quando TLS è abilitato, ignora tutti i controlli dei certificati.

Se questa opzione è selezionata, la connessione non è più sicura e non deve essere abilitata in produzione.

Può essere utile a scopo di debug o test.

Associazione TON/NPI

TON (tipo di numero) e NPI (indicatore del piano di numerazione) descritti al punto 5.2.5 della specifica SMPP 3.4 (pagina 117). Questi valori devono essere impostati in base alle esigenze del provider.

Vengono trasmesse così come sono nei campi addr_ton e addr_npi della PDU BIND.

Intervallo di indirizzi

Inviato come nel campo address_range della PDU BIND. Questo valore deve essere impostato a prescindere dalle esigenze del provider.

Numero di riconoscimenti ID non valido

Limita il numero di ID messaggio non valido DELIVER_SM_RESP che possono essere inviati per un singolo SR.

Deve essere utilizzato solo per la risoluzione dei problemi come soluzione alternativa e impostato su 0 in condizioni normali.

Esempio Fox, quando si imposta su 2:

  • Il provider invia un SR (DELIVER_SM) con ID "1234".

  • Impossibile trovare l'ID "1234" nel database.

  • Il connettore conteggia 1 ID non valido per tale ID, quindi invia DELIVER_SM_RESP con il codice di errore "ID messaggio non valido" (comportamento normale).

  • Il provider tenta lo stesso SR con ID "1234".

  • Impossibile trovare l'ID "1234" nel database.

  • Il connettore conteggia 2 ID non valido per tale ID, quindi invia DELIVER_SM_RESP "OK", anche se non è stato elaborato correttamente.

  • Questa funzione consente di cancellare i buffer SR dal lato del provider quando il blocco SR non valido è legittimo che i messaggi non possano essere elaborati.

Se si imposta questo campo su 0, viene disattivato il meccanismo in cui viene sempre restituito ID messaggio non valido, si tratta di un comportamento normale.

Impostando questo campo su 1, il connettore risponde sempre "OK" anche se l'ID non è valido. Questo valore deve essere impostato su 1 solo sotto supervisione, per la risoluzione dei problemi e per il periodo minimo di tempo, ad esempio per recuperare da un problema sul lato del fornitore.

Area di estrazione dell'ID nell'SR

Il formato SR non è applicato in modo rigoroso dalla specifica del protocollo SMPP. Si tratta solo di una raccomandazione descritta nell' Appendice B (pagina 167) della specifica. Alcuni implementatori SMPP formattano questo campo in modo diverso, quindi Adobe Campaign ha bisogno di un modo per estrarre il campo corretto.

Per impostazione predefinita, dopo id: vengono acquisiti fino a 10 caratteri alfanumerici.

Il regex deve avere esattamente un gruppo di cattura con una parte contenuta tra parentesi. Le parentesi devono racchiudere la parte ID. Il formato regex è PCRE.

Quando regolate questa impostazione, accertatevi di includere il maggior numero possibile di contesti per evitare falsi attivatori. Se nello standard sono presenti prefissi specifici, ad esempio id:, includerli nel regex. Usate anche i delimitatori di parole (\b) il più possibile per evitare di acquisire testo al centro di una parola.

Non includendo abbastanza contesto nel regex può introdurre un piccolo difetto di sicurezza: il contenuto effettivo del messaggio può essere incluso nella SR. Se confrontate solo un formato ID specifico senza contesto, ad esempio un UUID, potrebbe essere l’analisi del contenuto di testo effettivo, ad esempio un UUID incorporato nel campo di testo invece dell’ID.

Regex applicato per determinare lo stato di riuscita/errore

Quando si incontrano messaggi con una combinazione di campi di stato/errore sconosciuta, questi regex vengono applicati al campo di stato per determinare se l'SR è stato un successo o un errore. L'SR con valori di stato che non corrispondono a nessuno di questi regessi viene ignorato.

Per impostazione predefinita, i valori stat iniziano con DELIV, ad esempio DELIVRD nell' Appendice B, sarà considerato come consegnato con successo e tutti i valori di stato che corrispondono a errori, ad esempio REJECTED, UNDELIV sono considerati errori.

Formato ID nella conferma MT

Indica il formato dell'ID restituito nel campo message_id di SUBMIT_SM_RESP PDU.

  • Non modificare: L’ID viene memorizzato così come è nel database, come testo con codifica ASCII. Non si verifica alcuna pre-elaborazione né filtraggio.

  • Numero decimale: L’ID deve essere un numero decimale in formato ASCII. Gli spazi iniziali e finali e gli zero iniziali vengono rimossi quando questa impostazione viene utilizzata.

  • Numero esadecimale: L’ID deve essere un numero esadecimale in formato ASCII, senza l’iniziale 0x o h finale. L'ID viene quindi convertito in un numero decimale prima di essere memorizzato nel database.

  • Stringa esadecimale: L’ID deve essere un testo con codifica ASCII che a sua volta è una stringa di byte codificati come esadecimali. Ad esempio, nella PDU si trova 0x34 0x31 0x34 0x32 0x34 0x33, che si traduce in ASCII "414243". Questa stringa viene quindi decodificata come una stringa esadecimale di byte ed è quindi possibile ottenere "ABC": nel database verrà memorizzato l'ID "ABC".

Formato ID in SR

Indica il formato dell'ID acquisito dal regex Extraction dell'ID nell'SR. I valori hanno lo stesso significato e lo stesso comportamento del formato indicato in MT sopra.

ID SR o codice di errore nel campo facoltativo

Se questa opzione è attivata, il contenuto dei campi facoltativi verrà aggiunto al testo elaborato dai regex sopra. Il testo avrà il formato 0xTAG:VALUE, 0xTAG che corrisponde al valore esadecimale di 4 cifre del tag in lettere maiuscole, ad esempio 0x002E.

Ad esempio, potresti voler acquisire l'ID nel campo receipted_message_id. Per questo, abilita questa casella di controllo e il testo seguente verrà aggiunto allo stato:

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

In questo esempio, 0x001E è il tag del campo facoltativo e UUID è il valore del campo.

Per acquisire questo valore, ora puoi impostare il seguente regex nel regex di estrazione dell’ID nel campo SR:

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

È possibile acquisire solo i campi facoltativi con valori di testo (ASCII/UTF-8). In particolare, i campi binari non possono essere acquisiti in modo affidabile con il sistema regex corrente.

ID SR o codice di errore nel campo di testo

Se selezionato, il campo Testo verrà mantenuto durante l'elaborazione del testo dello stato dell'SR.

Questo è utile se il provider inserisce dati importanti in questo campo come l'ID o lo stato. In genere questo campo può essere eliminato in modo sicuro, poiché può contenere testo con una codifica non ASCII e interrompere l’elaborazione regolare.

Abilitando questa opzione è possibile che si verifichi un difetto di sicurezza molto piccolo se il regex Extraction dell'ID nel campo SR non è sufficientemente specifico. Il contenuto del campo Testo può essere analizzato come ID e un utente malintenzionato può utilizzarlo per iniettare ID falsi, il che può portare a una situazione di rifiuto parziale del servizio.

ID servizio

Consente di aggiungere un TLV personalizzato. Questo campo imposta la porzione del tag. Il valore può essere personalizzato per consegna nel valore Service o program ID nei parametri avanzati della consegna.

Questa impostazione consente solo di aggiungere un’opzione TLV per messaggio.

NOTA

A partire dalla release 21.1, è ora possibile aggiungere più di un parametro opzionale. Per ulteriori informazioni, consulta questa sezione.

Risposta automatica inviata al MO

Questa funzione consente di rispondere rapidamente al testo su MO e di gestire per codice breve l'invio al elenco Bloccati.

Le colonne Parola chiave e Codice breve definiscono le condizioni per attivare la risposta automatica. Se entrambi i campi corrispondono, l'MO viene inviato e l'azione aggiuntiva viene attivata. Per specificare un carattere jolly, lasciare vuoto il campo. La parola chiave corrisponde alla prima parola alfanumerica nel testo MO, ignorando la punteggiatura e gli spazi iniziali. Significa che il campo Parola chiave non può contenere spazi e deve essere una sola parola.

L'impostazione Parola chiave è un prefisso. Ad esempio, se specificate "AD", i valori corrispondenti saranno "AD", "ADAPT" e " ADOBE". Se si dispone di più parole chiave con un prefisso comune, è necessario prestare attenzione all'ordine in quanto le parole chiave vengono elaborate dall'alto verso il basso.

La colonna Rispondi è il testo da rispondere. In questo campo non è disponibile alcuna personalizzazione. Se lasciate vuoto questo campo, non verrà risposto alcun messaggio, ma verrà comunque attivata l'azione aggiuntiva.

La colonna Azioni aggiuntive fornisce un'azione aggiuntiva quando Parola chiave e Codice breve corrispondono, il codice breve vuoto corrisponde a tutti i codici brevi. È possibile inviare alla quarantena o rimuovere dalla quarantena, con valore none risponde al testo. Se si specifica un'azione aggiuntiva ma si lascia vuoto il campo Rispondi, l'azione verrà eseguita ma non verrà inviata alcuna risposta. La quarantena viene applicata solo per il codice breve specificato, oppure per tutti i codici brevi se il campo viene lasciato vuoto.

IMPORTANTE

L'impostazione Invia numero di telefono completo ha un impatto sul comportamento del meccanismo di quarantena automatica delle risposte: se l'opzione Invia numero di telefono completo non è selezionata, il numero di telefono messo in quarantena sarà preceduto dal segno più ("+") per renderlo compatibile con il formato del numero di telefono internazionale.

Tutte le voci della tabella vengono elaborate nell'ordine specificato, fino a quando una regola non corrisponde. Se più regole corrispondono a una regola MO, verrà applicata solo la regola superiore.

Parametri opzionali di risposta automatica (TLV)

A partire dalla release 21.1, è possibile aggiungere parametri facoltativi alla risposta automatica MT. Sono aggiunti come parametri TLV facoltativi alla SUBMIT_SM PDU della risposta, come descritto nella sezione 5.3 della specifica SMPP(pagina 131).

Per ulteriori informazioni sui parametri facoltativi, fare riferimento a questa sezione sezione.

Parametri modello di consegna SMS

Alcuni parametri possono essere impostati per modello di consegna.

Da campo

Questo campo è facoltativo. Consente di sovrascrivere l'indirizzo del mittente (oADC). Il contenuto di questo campo viene inserito nel campo source_addr della SUBMIT_SM PDU.

Il campo è limitato a 21 caratteri dalla specifica SMPP, ma alcuni fornitori possono consentire valori più lunghi. È inoltre possibile applicare restrizioni molto rigorose in alcuni paesi, ad esempio lunghezza, contenuto e caratteri consentiti.

Parametri di consegna

Numero massimo di SMS per messaggio

Questa impostazione funziona solo se l'impostazione Messaggio payload è disabilitata. Per ulteriori informazioni, fare riferimento a questa pagina. Se il messaggio richiede più SMS di questo valore, verrà attivato un errore.

Il protocollo SMS limita gli SMS a 255 parti, ma alcuni telefoni cellulari hanno problemi a mettere insieme lunghi messaggi con più di 10 parti circa, il limite dipende dal modello esatto. Ti consigliamo di non superare 5 parti per messaggio.

A causa del funzionamento dei messaggi personalizzati in Adobe Campaign, i messaggi possono avere dimensioni diverse. Avere una grande quantità di messaggi lunghi potrebbe aumentare i costi di invio.

Modalità di trasmissione

Questo campo indica il tipo di SMS che si desidera trasferire: messaggi normali o flash, memorizzati sulla scheda mobile o SIM.

Questa impostazione viene trasmessa nel campo dest_addr_subunit facoltativo della SUBMIT_SM PDU.

  • Nessun campo facoltativo nella PDU.

  • Imposta il valore su 1. Invia un messaggio Flash che viene visualizzato sul dispositivo mobile e non viene memorizzato nella memoria.

  • In genere il valore viene impostato su 0. Invia un messaggio normale.

  • Salva su mobilesimposta il valore su 2. Indica al telefono di memorizzare l'SMS nella memoria interna.

  • Salva su terminali imposta il valore su 3. Indica al telefono di memorizzare l'SMS nella scheda SIM.

Periodo di validità

Il periodo di validità viene trasmesso nel campo validity_period della SUBMIT_SM PDU. La data viene sempre formattata come formato di ora UTC assoluto (il campo data termina con "00+").

Parametri opzionali SMPP (TLV)

A partire dalla release 21.1, è possibile aggiungere più parametri facoltativi a ogni MT inviato per questa consegna. Questi parametri opzionali vengono aggiunti alla SUBMIT_SM PDU della risposta, come descritto nella sezione 5.3 della specifica SMPP(pagina 131).

Ogni riga della tabella rappresenta un parametro facoltativo:

  • Parametro: Descrizione del parametro. Non trasmesso al provider.
  • ID tag: Tag del parametro opzionale. Deve essere un valore esadecimale valido, utilizzando il formato 0x1234. Valori non validi causeranno un errore di preparazione del recapito.
  • Valore: Valore del campo facoltativo. Codificato come UTF-8 quando viene trasmesso al provider. Impossibile modificare il formato di codifica. Non è possibile inviare valori binari o utilizzare codifiche diverse come UTF-16 o GSM7.

Se un parametro opzionale ha lo stesso ID tag dell' ID tag servizio definito nell'account esterno, il valore definito in questa tabella prevarrà.

Connettore SMPP

Le frecce rappresentano il flusso di dati.

La cosa più importante da notare è che ci sono più thread di connettore SMPP. Questi thread sono tutti identici e condividono la stessa configurazione. Per questo motivo il numero di connessioni viene sempre moltiplicato per il numero di thread.

Il numero di thread non può essere modificato dal cliente perché richiede la modifica dei file di configurazione.

Descrizione del comportamento del connettore SMPP

Voci MT, SR e broadcast corrispondenti

In Adobe Campaign, un messaggio è una voce di registro. In Adobe Campaign Standard, i connettori esterni devono conoscere solo la tabella di broadcast funzionante: nmsBroadLogExec. Un flusso di lavoro ha il compito di copiare le voci del registro di trasmissione nelle relative dimensioni di targeting specifiche (nmsBroadLogXXX).

Sfortunatamente, SMPP non consente l'invio di un ID con un messaggio: il provider fornisce un MT ID a ciascun MT, quindi uno o più SR con lo stesso ID.

L'ID fornito dal provider è memorizzato nella colonna sProviderId della tabella nmsBroadLogExec. SR arriva sempre dopo che il MT è stato inviato con successo e riconosciuto, ma a volte può arrivare fuori ordine, noto in Adobe Campaign come SR eccezionale. Il thread di elaborazione memorizza temporaneamente questi SR nella RAM fino all'arrivo delle informazioni complete.

Quando un MT viene riconosciuto (SUBMIT_SM_RESP), sProviderId viene aggiornato immediatamente nel database.

Ogni SR viene elaborato singolarmente dai thread di elaborazione SMPP. Questo processo è pseudo-sincrono: viene visto come sincrono dall’esterno, ma implementato internamente con implementazioni basate sugli eventi. L'SR viene riconosciuto solo quando il log di trasmissione è stato aggiornato correttamente, se si verifica un errore, l'SR viene rifiutato.

Questo è il processo applicato a ciascun SR:

  • L'ID della SR viene estratto utilizzando un regex.
  • L'ID viene ricercato in nmsBroadLogExec:sProviderId.
  • Il codice di errore status + viene estratto dalla SR utilizzando i regessi.
  • Il meccanismo dei messaggi del registro di trasmissione viene utilizzato per qualificare l'errore e trovare l'ID del messaggio del registro di trasmissione.
  • Il registro di trasmissione viene aggiornato con tutte le informazioni riportate sopra.
  • La SR è riconosciuta.

Per controllare i passaggi di cui sopra è necessario abilitare tracce SMPP dettagliate per verificare manualmente che tutti i passaggi siano correttamente applicati. Questo è necessario ogni volta che Adobe Campaign è collegato a un nuovo provider SMPP.

Prima di andare in diretta

Questa lista di controllo contiene un elenco di elementi da verificare prima di iniziare a vivere. Una configurazione incompleta può causare molti problemi.

Verificare i conflitti di account esterni

Controlla di non avere vecchi account esterni SMS. Se l'account di test viene disattivato, si corre il rischio che venga riattivato nel sistema di produzione e si generino potenziali conflitti.

Verificate che nessun'altra istanza si connetta a questo account. In particolare, accertatevi che l'ambiente dell'area di visualizzazione non si connetta all'account. Alcuni fornitori lo supportano, ma richiede una configurazione molto specifica sia lato Adobe Campaign che sulla piattaforma del fornitore.

Se è necessario avere più account sulla stessa istanza di Adobe Campaign che si connettono allo stesso provider, contattate il provider per essere sicuri che distinguano effettivamente le connessioni tra questi account. La presenza di più account con lo stesso accesso richiede una configurazione aggiuntiva.

Abilitare tracce SMPP dettagliate durante i controlli

È sempre necessario abilitare le tracce SMPP dettagliate durante i controlli.
Anche se non è possibile controllare personalmente i file di registro, sarà più semplice per il supporto di aiutarvi.

Test dell'SMS

  • Invia SMS con tutti i tipi di
    caratteriSe devi inviare SMS con caratteri non GSM o non ASCII, prova a inviare alcuni messaggi con il maggior numero possibile di caratteri diversi. Se imposti una tabella di mappatura caratteri personalizzata, invia almeno un SMS per tutti i possibili
    data_coding values.

  • Verificare che SR siano
    elaborati correttamenteL'SMS deve essere contrassegnato come ricevuto nel registro di consegna. Il registro di consegna deve avere esito positivo ed essere simile al seguente:

Verificate di aver modificato il nome del provider di consegna. Il registro di consegna non deve mai contenere SR yourProvider stat=DELIVRD err=000|#MESSAGE
Verificate di aver modificato il nome del provider di consegna. Il registro di distribuzione non deve mai contenere SR Generic negli ambienti di produzione.

  • Verificare che MO siano
    elaboratiSe è necessario elaborare MO (risposte automatiche, memorizzazione MO nel database, ecc.) prova a fare qualche test. Inviate qualche SMS per tutte le parole chiave di risposta automatica e controllate se la risposta è abbastanza veloce, non più di pochi secondi.
    Archiviare il registro che Adobe Campaign risponde con un esito positivo
    DELIVER_SM_RESP (command_status=0).

Controllare le PDU

Anche se i messaggi hanno un aspetto positivo, è importante verificare che le PDU siano formattate correttamente.

Questo passaggio è necessario quando ci si connette a un provider che non era già connesso a Adobe Campaign.

BIND

Verificate che BIND_* PDUs venga inviato correttamente. La cosa più importante da verificare è che il provider restituisca sempre correttamente BIND_*_RESP PDUs (command_status = 0).

Verificare che non siano presenti troppi BIND_* PDUs. Se ce ne sono troppi, potrebbe indicare che la connessione è instabile. Per ulteriori informazioni, vedere la sezione Problemi con connessioni instabili.

Verificare che ENQUIRE_LINK PDUs siano scambiati regolarmente quando la connessione è inattiva.

SUBMIT_SM / DELIVER_SM

Inviate un messaggio, quindi cercate nei registri le SUBMIT_SM, SUBMIT_SM_RESP, DELIVER_SM e DELIVER_SM_RESP PDUs corrispondenti.

Con la SUBMIT_SM PDU:

  • Verificare che data_coding sia corretto, 0 per impostazione predefinita.
  • Verificare che short_message sia codificato correttamente. Provate a decodificarlo utilizzando un convertitore esadecimale che supporta più codifiche.

Con la SUBMIT_SM_RESP PDU:

  • Verificare che sia stato eseguito correttamente, command_status = 0.
  • Verificate che il relativo corpo contenga un ID formattato correttamente seguito da un byte '0'.

Con la DELIVER_SM PDU:

  • Decodificare il campo esadecimale short_message.
  • Verificare con uno strumento di controllo del regex che il regex definito in Extraction regex dell'ID nell'SR restituisca esattamente un gruppo di acquisizione e che acquisisca l'intero ID nel messaggio.
  • Verificare che l'ID estratto corrisponda a quello in SUBMIT_SM_RESP.
  • Verificare che il regex definito in Extraction regex dello stato nell'SR restituisca il contenuto del campo stat.
  • Verificate che il regex definito in Extraction regex dell'errore nell'SR restituisca il contenuto del campo err.

Con la DELIVER_SM_RESP PDU:

  • Verificate che sia stato inviato rapidamente dopo la ricezione del DELIVER_SM PDU, in genere meno di 1 secondo.
  • Verificare che sia stato eseguito correttamente, command_status = 0.

Chiedi al provider se tutto è OK

Anche se il tuo SMS ha successo, contatta il provider per vedere se tutto è in ordine.

Disattivazione di tracce SMPP dettagliate

Una volta completati tutti i controlli, l'ultima cosa è Disabilita tracce SMPP dettagliate per non generare troppi log. Potete riattivarli per la risoluzione dei problemi anche sui sistemi di produzione.

In questa pagina

Adobe Summit Banner

A virtual event April 27-28.

Expand your skills and get inspired.

Register for free
Adobe Summit Banner

A virtual event April 27-28.

Expand your skills and get inspired.

Register for free