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.
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.
A realm only has one PIG and one SIG.
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.
While sites in the same realm can share the same product 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. |
Upload data and code to staging and then replicate 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
Help: Concepts and Terminology