Learn About B2C Commerce Replication
Learning Objectives
After completing this unit, you’ll be able to:
- Describe the process flow between instances.
- List three types of data that are replicated.
- List two differences between the import/export and replication processes.
- Describe two ways to control replication.
- Explain the benefit of replication tasks.
Introduction
Replication is a Salesforce B2C Commerce process that pushes data and code from a staging instance to a development or production instance in a controlled manner, minimizing the risk of errors. Replication only happens on instances in the primary instance group (PIG), and not on the secondary instance group (SIG) or sandboxes.
Source and Target
During replication, changes are pushed from a replication source to a replication target. The replication source is always the staging instance; while the replication target can be a development or production instance. While the main goal of replication is to push changes from staging to production, a preliminary step is to push the same changes to development. This lets you verify that replication was successful.
Replication Control
Start by creating a replication process in Business Manager, the B2C Commerce tool for site configuration and management. A replication process is a collection of replication tasks that specify the changes since the last replication. The changes can be data (such as product data, content, and image files) or code.
You can define multiple replication processes and specify which replication tasks to include in each. This lets you control the level of granularity that’s pushed each time. You can push an entire site or a selected subset; for example, just the site's custom objects. You have a similar flexibility with organization-level changes.
Schedule start and end dates during times of low traffic, so it doesn't impact your site's performance, or adversely affect the shopper experience.
Two-Step Publishing
You can replicate data via two-step publishing, which helps you avoid running the entire process only to have it fail. This process helps if you’re just starting your replication and transfer processes, and need more control over the results.
- Transfer: Create a new replication, configure it for your site, and select Transfer as the replication type. If the transfer fails, figure out what went wrong. Once you've fixed it, try again.
- Publish: Create a second task called Data Publish to publish the data. For data replication, the data in the transfer and publish tasks must match. For example, you can’t transfer catalog, index, and promotion data, and then only publish catalog data.
Data Replication
Because data replication is intended to push the latest version of a storefront into production, it’s a replace operation, and not a merge. Data replication first creates a copy of the data from the source instance at a new location in the target instance, without replacing the original data. When the process completes, you switch from the existing data to the new data in the target system, effectively replacing the data. It’s seamless and instantaneous.
The first time you replicate data, all the data is included. For subsequent replications, you can replicate on a granular level. For example, you can replicate individual sites and their associated catalogs: all catalogs, one catalog, or the product catalog.
Choosing Data to Replicate
B2C Commerce data can have an organization or site scope. At the organization level, data is shared by all sites. At the site level, data is only used by an individual site. Within each scope, you can select different sets of data to replicate, such as all of the organization's catalogs or a specific storefront's promotions and coupons. This is the lowest level of data replication granularity supported. This capability is useful when some data is ready to replicate and some isn’t. For example, new content assets might be ready for production, while new catalog definitions aren’t.
There are some limitations. You can’t select a single product in a catalog or a promotion from within a data set to replicate. Data replication doesn’t copy these from staging:
- Orders
- Inventory lists
- Business Manager user profiles and login credentials
Schedule Data Replication
You can schedule a replication process four ways.
- Automatic: At a specified date and time, by default, or immediately after you’ve defined the replication process
- Manual: Ready to be started in Business Manager by a user with the proper permissions
- Recurring: On a daily, weekly, or monthly schedule
- Job Step: When triggered by a job
Be careful when you replicate. If a recurring data replication fails, subsequent repetitions of the job won’t run. Replication usually clears the page cache, which can have a dramatic impact on storefront performance.
Best Practices
Here are some data replication best practices.
- Test the replication process from staging to development first.
- Test the resulting configuration on development to ensure it works as expected.
- Always run transfer, followed by publish so you can verify the transfer process.
- Identify dependencies between different data replication groups.
- Always replicate the search indexes with catalogs.
- Perform the transfer to production step when storefront activity is at a minimum.
- Disable incremental and scheduled indexing and stop other jobs while replicating data. Though incremental indexing doesn’t need to be disabled for the transfer, it must be disabled before you publish. You can either replicate the search index or manually build it on the target instance.
- Avoid major data replications during the B2C Commerce standard maintenance windows.
- Use Business Manager permissions to limit who can perform data replication.
Code Replication
With Business Manager code replication, you replicate a code version between a source and a target instance. A code version is a folder that contains custom cartridges. An instance can have multiple code versions, but only uses the active code version.
When you’ve finished developing in your sandbox, upload your code to staging. The server connection should be secure.
On the production instance, a new version is automatically created, named a combination of the original version name with a timestamp. You can copy the code to production without activating it, or copy it while making it active. If you need to revert to a previous code version, B2C Commerce knows which version was previously active and reactivates it. We suggest you do the following on a production instance.
- Deploy the code version on staging.
- Replicate the code (and data) to development to test the process.
- Replicate the code to production.
Replication Types
Configure the target system to create code replication processes with a manual, automatic, or job step start. These are the replication types.
| Replication Type | Description |
|---|---|
| Code Transfer | The currently activated code version on the source system is transferred to the target system. Each replication creates a new code version on the target system, even if the name of all files within the version match an already installed version. Unlike data replication, there’s no synchronization because this could affect the existing, or even active, version on the target. |
| Code Transfer and Publishing | A Code Transfer is followed by an immediate activation of the new version. |
| Code Publishing | There’s no transfer. The previously transferred version is activated. This mode is only available when the previous replication type was Code Transfer. Because the version name can change between the two systems, additional logic ensures the correct handling. If this version no longer exists, publishing fails. If it’s been activated already, nothing happens. |
| Code Undo | This is similar to Code Publishing (with no data transfer), but it rolls back the previously activated version. The prior process must be either Code Transfer and Publishing or Code Publishing. If the version to be reverted is no longer active, nothing happens. If the version no longer exists or no version to rollback to exists, the process fails. |
Email Notification
You can configure email notifications for code replications using a comma-delimited list of recipients. An email is sent after the process finishes or fails. If the process hangs, no email is sent.
Replication Groups
Replication groups (or tasks) let you organize your data and processes in a manageable way. You can also replicate data at the site level, organizational level, or both. Custom objects, for example, can be replicated at both the organizational and site level.
Business Manager groups multiple objects that are replicated together. Spend time reviewing the relationships among the objects to understand their complexity.
Data/Code Replication Versus Import/Export
Use both import/export and data replication to populate instance databases.
- Replication moves code/data from one instance to another, once the code/data is already in the B2C Commerce system.
- Import and export moves data to and from external systems, from and to a B2C Commerce Database
Next Steps
In this module, we learned a lot about B2C Commerce architecture. We learned how sites and organizations are structured into PIGs and SIGs, the nuances of import and export, and how the replication process moves code and data from one instance to another. Now it’s time to earn a shiny new badge.
