Sfruttando Snowflake, una tecnologia di database cloud, l’implementazione di Adobe Campaign Enterprise Full Federated Access (FFDA) migliora notevolmente la sua scala e velocità, con la possibilità di gestire un numero più significativo di profili cliente, oltre a tassi di consegna e transazioni molto più elevati all’ora.
Campaign v8 Enterprise (FFDA) porta la scala 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: locale Campaign database per la messaggistica in tempo reale e le query unitarie dell’interfaccia utente e per la scrittura tramite API e un cloud Snowflake database 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.
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 secondo il seguente schema:
La Snowflake database sul lato marketing viene utilizzato per:
Il database PostgreSQL nell'istanza di marketing viene utilizzato per:
Esegui alcuni carichi di lavoro, ad esempio API per volumi ridotti.
Archivia tutti i dati di Campaign, comprese le impostazioni di consegna e campagna, il flusso di lavoro e le definizioni dei servizi.
Memorizza tutte le tabelle di riferimento integrate (enumerazioni, paesi, ecc.) che vengono replicati in Snowflake.
Tuttavia, non puoi:
Il database PostgreSQL nell'istanza di mid-sourcing viene utilizzato per:
Con Campaign Database cloud, le chiamate unitarie di esplosione non sono raccomandate a causa delle prestazioni (latenza e concorrenza). L'operazione batch è sempre preferita. Per 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 dati tra Campaign database locale e database cloud. È stato inoltre introdotto un nuovo meccanismo per gestire le chiamate API a livello di database locale per evitare la latenza e migliorare le prestazioni complessive.
Le nuove API sono descritte in dettaglio 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