Campaign FFDA deployment gs-ac-ffda
By leveraging , a cloud database technology, ۶Ƶ Campaign Enterprise Full Federated Access (FFDA) deployment dramatically improves its scale and speed, with the ability to manage a more significant number of customer profiles, as well as much higher delivery rates and transactions per hour.
Benefits ffda-benefits
Campaign v8 Enterprise (FFDA) brings end-to-end scale at any step of the process, from targeting to the final reporting:
- Scale the volume of data you can handle (until 8 TB)
- Scale the performance of queries for segmentation and targeting but also data ingestion and egress
- Scale the delivery preparation (from hours to minutes)
This is a foundational change in the software architecture. Data is now remote and Campaign federates the whole data, including Profiles. Campaign processes now scales end-to-end, from targeting to message execution: data ingestion, segmentation, targeting, queries, deliveries will now typically run in minutes. This new version solves the whole challenge of scaling while keeping the same level of flexibility & extensibility. The number of profiles is almost unlimited, and data retention can be extended.
Cloud storage is performed in Snowflake: a new built-in external account ensures connectivity with the Cloud Database. It is configured by ۶Ƶ and must not be modified. Learn more
Any built-in schema/table which needs to be moved or replicated in Cloud Database comes with a built-in schema extension under the xxl namespace. Those extensions contain any modification required to move built-in schemas from the Campaign local database to the Snowflake Cloud database and to adapt their structure accordingly: new UUID, updated links, etc.
Campaign Enterprise (FFDA) architecture ffda-archi
In an Enterprise (FFDA) deployment, ۶Ƶ Campaign v8 works with two databases: a local Campaign database for the user interface real-time messaging and unitary queries and write through APIs, and a Cloud Snowflake database for campaign execution, batch queries and workflow execution.
Campaign v8 Enterprise brings the concept of Full Federated Data Access (FFDA): all data is now remote on the Cloud Database.
Specific APIs are available to manage data between the local and the cloud database. Learn how these new APIs work and how to use them in this page.
General communication between servers and processes is carried out according to the following schema:
- The execution and bounce management modules are disabled on the instance.
- The application is configured to perform message execution on a remote “mid-sourced” server that is driven using SOAP calls (over HTTP or HTTPS).
The Snowflake database on the marketing side is used to:
- Store all customer data: profiles, custom data such as transactions, products, locations, etc.
- Store all events and behavior data generated or collected by Campaign, such as delivery logs, tracking logs, push registrations, etc.
- Store all data aggregates of the above.
- Store a copy (h+1) of reference tables (such as deliveries, enumerations, countries, etc.) which are used in workflows, campaigns and reports.
- Run all batch processes and workloads
The PostgreSQL database on the marketing instance is used to:
-
Execute certain workloads, such as low volume APIs.
-
Store all Campaign data, including delivery and campaign settings, workflow and service definitions.
-
Store all built-in reference tables (enumerations, countries, etc.) which are replicated to Snowflake.
However, you cannot:
- create customizations for customer data, for example do not create a household table in PostgreSQL, but only in Snowflake
- store any delivery logs, tracking logs, etc. on FFDA targeting dimension.
- store large volume of data.
The PostgreSQL database on the mid-sourcing instance is used to:
- Execute batch and real-time (RT) deliveries.
- Send delivery and tracking logs - note that delivery and tracking log IDs are UUIDs and not 32-bit IDs.
- Collect and store tracking data.
Impacts ffda-impacts
Campaign API staging mechanism staging-api
With Campaign Cloud database, blast unitary calls are not recommended due to performance (latency & concurrency). BUnless you are sending extremely sending volume, batch operation must be used to guarantee optimal performances of APIs, Campaign keeps handling API calls at the local database level.
API staging mechanism is detailed in this page
New APIs new-apis
New APIs are available to manage data synchronization between Campaign local database and Cloud database. A new mechanism has also been introduced to handle API calls at the local database level to avoid latency and increase the overall performance.
New APIs are detailed in this page
Data replication data-replication
A specific technical workflow handles replication of tables that need to be present on both sides (Campaign local database and Cloud database). This workflow is triggered every hour and relies on a new built-in JavaScript library.
Some tables are replicated in real-time, others will be replicated on an hourly basis. Some tables will have incremental updates, others will go through a full update.
Learn more about Data replication
ID management id-mgt-ffda
Campaign v8 objects now use a Universally Unique ID (UUID), which allows for unlimited unique values to identify data.
Please note that this ID is string-based and not sequential. The primary key is not a numerical value in Campaign v8, and you need to use autouuid and autopk attributes in your schemas.
In Campaign Classic v7 and earlier versions, the unicity of a key within a schema (i.e. table) is handled at the database engine’s level. More generally, Classic Database engines like PostgreSQL, Oracle, or SQL Server include a native mechanism to prevent inserting duplicated rows based on a column or a set of columns via primary keys and/or unique indexes. Duplicated ID do not exist in these versions when proper index and primary keys are set at Database level.
۶Ƶ Campaign v8 comes with Snowflake as the core Database. As it dramatically increases the scale of queries, the distributed architecture of the Snowflake database does not provide such mechanisms to manage then enforce the unicity of a key within a table. As a consequence, with ۶Ƶ Campaign v8, nothing prevents the ingestion of duplicated keys in a table. End-users are now responsible for ensuring consistency of Keys within the ۶Ƶ Campaign database. Learn more
Feature availability feature-availability
Some capabilities are not available in the context of an Enterprise (FFDA) deployment of Campaign, such as:
- Marketing Resource Management
- Coupons
- Web tracking
- Surveys
Related topics