Introduzione all’architettura di Campaign gs-ac-archi
Ambienti environments
Campaign è disponibile come istanza singola, dove ogni istanza rappresenta un ambiente Campaign completo.
Sono disponibili due tipi di ambienti:
-
Ambiente di produzione: ospita le applicazioni per gli utenti business.
-
Ambiente non di produzione: utilizzato per vari test di prestazioni e qualità prima che le modifiche all’applicazione vengano inviate all’ambiente di produzione.
Puoi esportare e importare pacchetti da un ambiente a un altro.
Ulteriori informazioni sui pacchetti in Documentazione di Campaign Classic v7
Modelli di distribuzione ac-deployment
Sono disponibili due modelli di distribuzione: Distribuzione FDA di Campaign (P1-P3) e Distribuzione di Campaign Enterprise (FFDA) (P4).
Distribuzione FDA di Campaign ac-deployment-fda
Nel suo Distribuzione FDA, Adobe Campaign v8 può essere connesso a Snowflake per accedere ai dati tramite la funzionalità Federated Data Access: puoi accedere ed elaborare dati e informazioni esterni memorizzati nel tuo Snowflake senza modificare la struttura dei dati di Adobe Campaign. PostgreSQL è il database primario ed è possibile utilizzare Snowflake come database secondario per estendere quindi il modello dati e archiviare i dati nel Snowflake. Successivamente, puoi eseguire ETL, segmentazione e rapporti su un set di dati di grandi dimensioni con prestazioni eccezionali.
Distribuzione di Campaign Enterprise (FFDA) ac-deployment-ffda
Nell'ambito di una Distribuzione aziendale (FFDA), Adobe Campaign v8 funziona con due database: uno locale Campaign database per la messaggistica in tempo reale, le query unitarie dell’interfaccia utente, le operazioni di scrittura tramite API e un cloud Snowflake database per l’esecuzione della campagna, le query batch e l’esecuzione dei flussi di lavoro.
Campaign v8 Enterprise introduce il concetto di Full Federated Data Access (FFDA): adesso tutti i dati sono remoti, nel database cloud. Con questa nuova architettura, l’implementazione di Campaign v8 Enterprise (FFDA) semplifica la gestione dei dati, in quanto nel database cloud non è richiesto alcun indice. È sufficiente creare le tabelle, copiare i dati e iniziare. La tecnologia del database Cloud non richiede una manutenzione specifica per garantire le prestazioni del servizio.
Esecuzione della consegna divisa split
A seconda del pacchetto Campaign v8, ti viene fornito un numero specifico di istanze di mid-sourcing responsabili dell’esecuzione delle consegne.
Per impostazione predefinita, gli account esterni di tutti i canali utilizzano un Alternate modalità di routing, che indica che una consegna viene inviata da ogni istanza mid alla volta in modo alternativo.
Per garantire prestazioni migliori in termini di velocità e scalabilità, puoi consentire la suddivisione automatica delle consegne tra le istanze di mid-sourcing in modo che vengano consegnate più rapidamente ai destinatari. Questa operazione è trasparente durante l’esecuzione della consegna dall’istanza di marketing: una volta inviata la consegna, tutti i registri vengono consolidati insieme, prima di essere rimandati all’istanza di marketing in un singolo oggetto di consegna.
A questo scopo, è necessario disporre di ulteriori account esterni con Split la modalità di routing viene creata al momento del provisioning per ogni canale:
- Consegna divisa - E-mail (splitDeliveryEmail)
- Consegna divisa - SMS (splitDeliverySMS)
- Consegna divisa - iOS (splitDeliveryIOS)
- Consegna divisa - Android (splitDeliveryAndroid)
Per impostare gli account esterni suddivisi come account predefinito per l’invio delle consegne, devi cambiare il provider di indirizzamento nei modelli di consegna. Per farlo, segui questi passaggi:
-
Accedi a Resources / Templates / Delivery templates e apri il modello di consegna desiderato. In questo esempio, desideri modificare il modello di consegna e-mail.
-
Fai clic su Properties e cambia il provider di indirizzamento con l’account esterno di consegna frazionata corrispondente.
-
Salva le modifiche. Tutte le consegne inviate utilizzando il modello ora utilizzano la modalità di routing diviso per impostazione predefinita.
Architettura del Centro messaggi transac-msg-archi
La messaggistica transazionale (Message Center) è il modulo di Campaign progettato per la gestione dei messaggi di attivazione.
Scopri come inviare messaggi transazionali in questa sezione.
In risposta a un’azione di un cliente su un sito web, un evento viene inviato a Campaign tramite un’API REST, il modello del messaggio viene compilato con le informazioni o i dati forniti tramite la chiamata API e un messaggio transazionale viene inviato in tempo reale al cliente. Questi messaggi possono essere inviati singolarmente o in batch tramite e-mail, SMS o notifiche push.
In questa architettura specifica, la cella di esecuzione è separata dall’istanza di controllo per garantire un’elevata disponibilità e la gestione del carico.
-
Il Istanza di controllo (o istanza Marketing) viene utilizzato dagli addetti al marketing e dai team IT per creare, configurare e pubblicare modelli di messaggio. Questa istanza centralizza anche il monitoraggio e la cronologia degli eventi.
Scopri come creare e pubblicare modelli di messaggio in questa sezione.
-
Il Istanza di esecuzione archivia gli eventi in arrivo (ad esempio, reimpostazione della password o ordini da un sito web) e invia messaggi personalizzati. Possono essere presenti più istanze di esecuzione per elaborare i messaggi tramite il load-balancer e scalare il numero di eventi da eseguire per ottenere la massima disponibilità.
Autenticazione
Per utilizzare queste funzionalità, gli utenti di Adobe Campaign accedono all’istanza di controllo per creare modelli di messaggi transazionali, generare l’anteprima dei messaggi utilizzando un elenco di seed, visualizzare i rapporti e monitorare le istanze di esecuzione.
-
Istanza di esecuzione singola Quando si interagisce con un’istanza di esecuzione del Centro messaggi ospitata da un Adobe, un sistema esterno può prima recuperare un token di sessione (che per impostazione predefinita scade tra 24 ore), effettuando una chiamata API al metodo di accesso alla sessione, utilizzando un account di accesso e una password forniti.
Quindi, con il sessionToken fornito dall’istanza di esecuzione in risposta alla chiamata di cui sopra, l’applicazione esterna può effettuare chiamate API SOAP (rtEvents o batchEvents) per inviare comunicazioni, senza dover includere in ogni chiamata SOAP l’accesso e la password dell’account. -
Più istanze di esecuzione In un’architettura di esecuzione a più celle con più istanze di esecuzione dietro un load balancer, il metodo di accesso richiamato dall’applicazione esterna passa attraverso il load balancer: per questo motivo, non è possibile utilizzare un’autenticazione basata su token. È necessaria un'autenticazione basata su utente/password.
Ulteriori informazioni sugli eventi di messaggistica transazionale in questa pagina.