In the context of an Enterprise (FFDA) deployment, data replication ensures that the two databases, Campaign local database (PostgreSQL) and Cloud database (Snowflake), are operational in parallel and remain synchronized in real-time.
The Cloud database (Snowflake) is optimized for handling large data batches, such as updating 1 million addresses. Meanwhile, the Campaign local database (PostgreSQL) is better suited for individual or small-volume operations, like updating a single seed address. Synchronization occurs automatically and transparently in the background, ensuring data in Campaign local database (PostgreSQL) is duplicated in the Cloud database (Snowflake) in real-time, keeping both databases synchronized. Data synchronization involves schemas and tables, and data.
➡️ Discover how data replication works in video
Data replication can occur in different modes depending on the use case.
Replication policies define how much data is replicated from a Campaign local database (PostgreSQL) table. These policies depend on the size of the table and the specific use case. Some tables will have incremental updates when others will be entirely replicated. There are three main types of replication policies:
Campaign v8 relies on specific technical workflows to manage scheduled data replication. These technical workflows are available from the Administration > Production > Technical workflows > Full FFDA Replication node of Campaign Explorer. They must not be modified.
Technical workflows execute processes or jobs, scheduled on a regular basis on the server. The full list of technical workflows is detailed in this page.
Technical workflows ensuring data replication are as follows:
Technical workflow | Description |
---|---|
Replicate Reference tables (ffdaReplicateReferenceTables) | Performs automatic replication of built-in tables that need to be present on Campaign local database (PostgreSQL) and Cloud database (Snowflake). It is scheduled to execute every hour, daily. If lastModified field exists, replication happens incrementally, otherwise the whole table is replicated. |
Replicate Staging data (ffdaReplicateStagingData) | Replicates staging data for unitary calls. It is scheduled to execute every hour, daily. |
Deploy FFDA immediately (ffdaDeploy) | Performs an immediate deployment to the Cloud database. |
Replicate FFDA data immediately (ffdaReplicate) | Replicates the XS data for a given external account. |
If needed, you can launch data synchronization manually. To do this, right-click on the Scheduler activity and select Execute pending task(s) now.
In addition to the built-in Replicate Reference tables technical workflow, you can force data replication in your workflows using one of these methods
Add a specific Javascript code activity with the following code:
nms.replicationStrategy.StartReplicateStagingData("dem:sampleTable")
Add a specific nlmodule activity with the following command:
nlserver ffdaReplicateStaging -stagingSchema -instance:acc1
On-the-fly replication is handled by specific technical threads rather than workflows. Configuration for this mode is managed in the serverConf.xml file. You can configure the serverConf.xml to match specific use cases, such as requesting that XS tables are incrementally replicated rather than entirely. For more information, contact your Adobe representative.
APIs enable replication of both custom and out-of-the-box data from Campaign local database (PostgreSQL) to Cloud database (Snowflake). These APIs allow you to bypass predefined workflows and customize replication for specific requirements, such as replicating custom tables.
Example:
var dataSource = "nms:extAccount:ffda";
var xml = xtk.builder.CopyXxlData(
<params dataSource={dataSource} policy="xs">
<srcSchema name="cus:recipient"/>
</params>
);
When high volumes of replication requests occur simultaneously, performance issues may arise in the Cloud database (Snowflake) due to table-level locks during MERGE operations. To mitigate this, centralized replication workflows group requests into queues.
Each queue is handled by a technical workflow, which manages replication for a specific table, executing pending requests as a single MERGE operation. These workflows are triggered every 20 seconds to process new replication requests:
Technical workflow | Description |
---|---|
Replicate nmsDelivery queue (ffdaReplicateQueueDelivery) | Queue for the nms:delivery table. |
Replicate nmsDlvExclusion queue (ffdaReplicateQueueDlvExclusion) | Queue for the nms:dlvExclusion table. |
Replicate nmsDlvMidRemoteIdRel queue (ffdaReplicateQueueDlvMidRemoteIdRel) | Queue for the nms:dlvRemoteIdRel table. |
Replicate nmsTrackingUrl queue (ffdaReplicateQueueTrackingUrl) Replicate nmsTrackingUrl queue in concurrency (ffdaReplicateQueueTrackingUrl_2) |
Queues in concurrency for the nms:trackingUrl table, utilizing two workflows to improve efficiency by processing requests based on different priorities. |
This video presents the key concepts of which databases Adobe Campaign v8 uses, why data is being replicated, which data is being replicated and how the replication process works.
Additional Campaign v8 Client Console tutorials are available here.