Sfruttando Snowflake, una tecnologia di database cloud, l’implementazione di Adobe Campaign Enterprise Full Federated Access (FFDA) migliora notevolmente la scalabilità e la velocità, con la possibilità di gestire un numero più significativo di profili cliente e garantendo inoltre tassi di consegna e transazioni all’ora più elevati.
Campaign v8 Enterprise (FFDA) offre una scalabilità end-to-end in qualsiasi fase del processo, dal targeting al reporting finale:
Questo è un cambiamento fondamentale nell’architettura del software. Adesso i dati sono remoti e Campaign unisce tutti i dati, inclusi i profili. I processi di Campaign ora vengono scalati in modalità end-to-end, dal targeting all’esecuzione dei messaggi: in genere l’acquisizione dei dati, la segmentazione, il targeting, le query e le consegne vengono eseguite in pochi minuti. Questa nuova versione risolve l’intera sfida della scalabilità mantenendo lo stesso livello di flessibilità ed estensibilità. Il numero di profili è quasi illimitato e la conservazione dei dati può essere estesa.
L’archiviazione cloud viene eseguita in Snowflake: un nuovo account esterno integrato garantisce la connettività con il database cloud. È configurato da Adobe e non deve essere modificato. Ulteriori informazioni
Le tabelle o gli schemi integrati che devono essere spostati o replicati nel database cloud hanno un’estensione di schema integrato nello spazio dei nomi xxl. Tali estensioni contengono eventuali modifiche necessarie per spostare gli schemi integrati dal database locale di Campaign al database cloud Snowflake e per adattarne di conseguenza la struttura: nuovo UUID, collegamenti aggiornati, ecc.
I dati dei clienti non vengono memorizzati nel database locale di Campaign. Di conseguenza, eventuali tabelle personalizzate devono essere create nel database cloud.
In un 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.
Sono disponibili API specifiche per la gestione dei dati tra il database locale e quello cloud. Per scoprire come funzionano queste nuove API e come utilizzarle, visita questa pagina.
La comunicazione generale tra server e processi viene eseguita in base allo schema seguente:
Il Snowflake database sul lato marketing utilizzato per:
Il database PostgreSQL nell’istanza di marketing viene utilizzato per:
Eseguire determinati carichi di lavoro, ad esempio API per volumi ridotti.
Memorizza tutti i dati di Campaign, incluse le impostazioni di consegna e campagna, le definizioni di flussi di lavoro e servizi.
Memorizza tutte le tabelle di riferimento incorporate (enumerazioni, paesi, ecc.) che vengono replicati in Snowflake.
Tuttavia, non è possibile:
Il database PostgreSQL nell’istanza di mid-sourcing viene utilizzato per:
Con Campaign Database cloud, le chiamate unitarie blast non sono consigliate a causa delle prestazioni (latenza e concorrenza). L'operazione batch è sempre preferibile. Al fine di garantire prestazioni ottimali delle API, Campaign continua a gestire le chiamate API a livello di database locale.
Il meccanismo di staging API è descritto in questa pagina
Sono disponibili nuove API per gestire la sincronizzazione dei dati tra Campaign database locale e database cloud. È stato inoltre introdotto un nuovo meccanismo per gestire le chiamate API a livello di database locale al fine di evitare la latenza e aumentare le prestazioni complessive.
Le nuove API sono dettagliate in questa pagina
Un flusso di lavoro tecnico specifico gestisce la replica delle tabelle che devono essere presenti su entrambi i lati (database Cloud e database locale di Campaign). Questo flusso di lavoro viene attivato ogni ora e si basa su una nuova libreria JavaScript integrata.
Sono stati creati diversi criteri di replica in base alle dimensioni della tabella (XS, XL, eccetera).
Alcune tabelle vengono replicate in tempo reale, altre vengono replicate su base oraria. Alcune tabelle avranno aggiornamenti incrementali, altre avranno un aggiornamento completo.
Ulteriori informazioni sulla replica dei dati
Ora gli oggetti di Campaign v8 utilizzano un ID universalmente univoco (UUID), che consente l’identificazione dei dati tramite valori univoci illimitati.
Tieni presente che questo ID è basato su stringhe e non è sequenziale. La chiave primaria non è un valore numerico in Campaign v8 e devi utilizzare gli attributi autouuid e autopk negli schemi.
In Campaign Classic v7 e versioni precedenti, l’unicità di una chiave all’interno di uno schema (ovvero una tabella) viene gestita a livello di motore del database. Più in generale, i motori di database classici come PostgreSQL, Oracle o SQL Server includono un meccanismo nativo per impedire l’inserimento di righe duplicate basate su una colonna o su un set di colonne attraverso l’uso di chiavi primarie e/o indici univoci. Quando l’indice e le chiavi primarie sono impostati correttamente a livello di database, l’ID duplicato non esiste in queste versioni.
Adobe Campaign v8 viene fornito con Snowflake come database di base. Poiché aumenta notevolmente la scalabilità delle query, l’architettura distribuita del database Snowflake non fornisce i meccanismi che consentono di gestire e dunque applicare l’unicità di una chiave all’interno di una tabella. Di conseguenza, in Adobe Campaign v8, è possibile effettuare l’inserimento di chiavi duplicate all’interno di una tabella. Gli utenti finali sono ora responsabili di garantire la coerenza delle chiavi all’interno del database di Adobe Campaign. Ulteriori informazioni
Alcune funzionalità non sono disponibili nel contesto di una distribuzione Enterprise (FFDA) di Campaign, ad esempio:
Argomenti correlati