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 nella documentazione di Campaign Classic v7
Modelli di distribuzione ac-deployment
Sono disponibili due modelli di distribuzione: Distribuzione FDA campagna (P1-P3) e Distribuzione Campaign Enterprise (FFDA) (P4).
Distribuzione FDA di Campaign ac-deployment-fda
Nella distribuzione FDA, Adobe Campaign v8 può essere connesso a Snowflake per accedere ai dati tramite la funzionalità Federated Data Access: è possibile accedere ed elaborare dati e informazioni esterni archiviati nel database 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
Nel contesto di una distribuzione di Enterprise (FFDA), Adobe Campaign v8 funziona con due database: un database Campaign locale per la messaggistica in tempo reale, le query unitarie dell'interfaccia utente e le operazioni di scrittura tramite API e un database Snowflake cloud per l'esecuzione della campagna, le query batch e l'esecuzione del flusso 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 una modalità di routing Alternate, il che significa che viene inviata una consegna 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, vengono creati account esterni aggiuntivi con la modalità di routing Split al momento del provisioning per ogni canale:
- Consegna divisa - E-mail (splitDeliveryEmail)
- Consegna divisa - SMS (splitDeliverySMS)
- Consegna divisa - iOS (splitDeliveryIOS)
- Consegna separata - 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:
-
Passare alla cartella Resources / Templates / Delivery templates e aprire il modello di consegna desiderato. In questo esempio, desideri modificare il modello di consegna e-mail.
-
Fare clic sul pulsante Properties e cambiare il provider di routing con l'account esterno di consegna divisa 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.
-
L'istanza di controllo (o istanza di marketing) viene utilizzata 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.
-
L'istanza di esecuzione recupera gli eventi in arrivo (reimpostazione password o ordini da un sito Web, ad esempio) 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 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 la necessità di 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.