Quick Fixes or Emergency Edits of Production Content

You might occasionally need to make unplanned edits to content on the
Production instance that must be live within a short period of time. You
can configure page cache partitions on Salesforce B2C Commerce so that it
is safer and has less of an effect on site performance to make these edits
and replicate them.

What Are Page Cache Partitions?

A page cache
partition is the page cache for a group of pipelines. If the partition is
invalidated, then the page cache for those pipelines is invalidated, but
no other page caches are invalidated.

Why Are Page Cache Partitions Useful?

While it
is possible to edit products directly in Business Manger on a Production
instance to make a quick fix, if the page that shows the product is
cached, it might take a long time until the change appears in the
storefront. To make the change appear faster, you must invalidate the
page cache for the entire site. This makes the change go into effect
within fifteen minutes, but has a significant performance impact, because
the entire page cache is regenerated.

Changes made directly to the
Production instance are outside the normal workflow, which allows for
testing and previewing content. It also requires additional work to get
the Staging and Production instance data back in sync, which must happen
before the next replication of data from Staging to
Production.

Salesforce recommends that you configure page cache
partitions and replication jobs for quick fixes of product or content
information for a better workflow and site performance. Configuring
partitions requires the permissions and expertise of your administration
or operations staff.

Configuring Page Cache Partitions

Note: Changing your page
cache configuration causes a reset of the cache clear time and should
be done infrequently. Every time a partition is updated (pipelines
added or removed) the page clear time of the updated partition and
site is set to the shorter value of the partition or site. When a
partition is deleted, the site's page clear time is set to the
partition's page cache clear time if it's shorter. The clear time for
the page cache can be seen as the last invalidated date for
page cache of the site.

Replicate the cache settings site-level replication task to the Production instance.
This replicates the required configuration to the Production instance. When replicated,
you only need to replicate it again if you change the configuration of the
partitions.

Important: Replicating the cache settings causes a full page
cache invalidation across all sites.

When You Need to Make a Quick Fix:

1. Change product or search
Information

Make the quick fix to product information on your
Staging instance.

2. Configure
Replication Jobs Without Page Cache Invalidation

Create a
replication job for your changes where the Page
Cache option is set to Do not
invalidate. See New Data Replication Process Step 1 General
page.

Selecting Don't invalidate for your
replication process means that the page cache for the entire site is not
invalidated, as it normally is when you replicate. Because the entire page
cache isn't invalidated you will see no performance effect on the
storefront because of the replication. You will also not see any of your
changes reflected in the storefront.

3:
Invalidate Page Cache Partitions

After replicating your changes to
product or search, you invalidate the page cache partition manually in
Business Manager on the Production instance.

Note: The page cache does not
include the static content cache, which must be Invalidated
Separately. The developers in your organization can tell you what
pipelines to include in your partition definitions.