📢 Attention Salesforce Certified Trailblazers! Maintain your credentials and link your Trailhead and Webassessor accounts by April 19th. Learn more.
close

Get Started Configuring Your B2C Commerce Sites

Learning Objectives

After completing this unit, you’ll be able to:

  • List the instance types.
  • Explain what the instance types are used for.
  • Describe how sites relate to organizations.
  • Describe how a multisite realm is managed.

Introduction

Salesforce B2C Commerce includes the resources and processes you need to run your ecommerce storefronts. You don’t interact directly with the cloud; it’s the foundation that supports your site. This unit explains how it all works: realms, PIGs, SIGs, and the types of instances that run on them.

When a site is created, or provisioned, it is structured into what is called a realm, which includes two groups: the primary instance group (PIG) and the secondary instance group (SIG). Realms are merchant-specific. Both groups include tools that you can use to configure your ecommerce site.

A realm has a primary and a secondary instance group.

Realms

Merchants typically have a single realm that’s just for them. A realm contains instances on which to develop, test, and deploy a storefront application. A B2C Commerce instance is an application infrastructure that includes the following components:

  • Web servers
  • Application servers
  • Database servers

Typically, a merchant receives nine instances per realm. This includes three instances for staging, testing, and deployment on the PIG, five sandbox instances for code development on the SIG, and one demo instance. For scalability, customers can have up to 47 sandboxes per realm.

Note

Note

A realm only has one PIG and one SIG.

Within Business Manager, the B2C Commerce tool for site configuration and management, you use the PIG instances as follows.

  • Staging—For site configuration, data enrichment, and data import
  • Development—For testing the site before deployment
  • Production—For hosting the live site that's visited by shoppers

Single and Multiple Realm Configurations

Typically, a merchant has a single realm in which to develop, stage, and deploy multiple sites with different branding or locales. The people managing the storefront site don’t need to be in the same location. Sites can share product catalogs or have different catalogs. They can even share some site admin settings.

Merchants with multiple lines of business or global teams that each have their own processes or business policies often use multiple realms. Separate realms are also useful for merchants with distinct organizations that have separate back-end integrations, schedules, or other concerns that are better managed independently.

Each realm, whether in a single or multiple configuration, has one primary and one secondary instance group.

While sites in the same realm can share the same master catalog for product data, sites in different realms can’t share data through the catalog structure. They can, however, share data by importing it into different realms.

Say you have two sites with separate brands: one in Europe and the other in the Pacific Rim. You can have a realm for the team managing the Pacific Rim site and another realm for the team managing the European site.

Sites and Organizations

In Business Manager, you can configure one or more sites within each instance. The multiple sites on a particular instance are considered an organization. When you configure settings, for example, you can configure them as site-specific (one site) or across all the sites (the organization).

Instances

A B2C Commerce instance contains the tools and resources for customizing storefronts. View an instance by typing its URL in a browser or open it in Business Manager. The four types of instances—sandbox, staging, development, and production—have different considerations:

Sandbox Staging Development Production
Usage Create and update storefront code. Configure campaigns, promotions, products, catalogs, and content. Simulate the production environment. Used as the final step in testing the content with code. Goes through the CDN provided by B2C Commerce, but doesn't cache (content). Live instance used for storefront transactions. Connected to the CDN provided by B2C Commerce.
Data I/O Most system jobs are disabled for sandboxes. Data and code are uploaded to staging and then replicated to production or development. Data and code are replicated from staging. Data can be exported from the instance. Data and code are replicated from staging. Data can be exported from the instance and imported into staging.

Instance Type Users

Depending on the size of the team, a person can play multiple roles. These are some general responsibilities.

Role Instance Type Responsibilities
Developer Sandbox, Staging

A developer creates or modifies templates, controllers, and scripts on a local machine and uploads them to a sandbox to test. The developer uploads code to staging. They can also export data added by merchandisers on staging to use as test data for sandboxes.

Note: Developers only use the development instance when they are testing what will be on production.

Merchandiser Staging A merchandiser creates campaigns and promotions, manages product information, and configures search behavior.
Administrator All instances An admin grants access to instances and functionality on instances. They restart instances, manage data feeds, and upload certificates.
Quality Assurance Engineer Development This engineer tests the site in conditions as close to production as possible. No code development is done here.

Next Steps

We explored the PIGs and SIGs of B2C Commerce site configurations. In the next unit, we talk about how B2C Commerce storefront data is imported and exported to and from systems of record.

Resources

retargeting