B2C Commerce Architecture
We provide several resources to help you learn about Salesforce B2C Commerce.
For a summary of the developer workflow, see Get Started with B2C Commerce.
B2C Commerce provides the resources and processing for your ecommerce sites, called a storefront in the B2C Commerce documentation. You create and build your sites in your realm.
A customer realm includes a primary instance group and a secondary instance group.
Typically, you have a single realm. The realm contains instances on which to develop, test, and deploy your online storefront. A B2C Commerce instance is an application infrastructure. It includes web servers, application servers, and database servers. You usually have six B2C Commerce instances: three or more sandbox instances for code development, and three instances for site staging, testing, and deployment. Development instance: used for site configuration, data enrichment, and data import. Staging instance: used to test your site before deployment. Production instance: hosts the live site that is used by customers. A Merchant can control their storefront online merchandising, configuration, and customization options. The instance administrator for the merchant has direct control over password management, user permissions, and stopping or starting instances within their realm.
In most cases, you have a single realm in which you can develop, stage, and deploy multiple sites with different branding or locales. The people managing the storefront site don't have to be in the same location. Sites can share product catalogs or have different catalogs.
If you have different lines of business or global teams that each have their own processes or business policies, consider maintaining multiple realms. You can also have separate realms if you have distinct organizations with separate back-end integrations, schedules, or other concerns that make it advantageous to let each team manage their sites independently. Sites in the same realm can share the product catalog for product data. Sites in different realms can't share data through the catalog structure. However, you can share data by importing it into different realms. Example: Let's say that you have sites with separate brands in Europe and the Pacific Rim. You can have a realm for the team managing the Pacific Rim sites and another realm for Europe.
The primary instance group has three instances, which merchants use to add data, test code, and run live sites. A realm can have only one PIG per realm.
The secondary instance group (SIG) contains your sandbox instances. The minimum number of sandboxes in a SIG is 3, and the maximum is 47.
The Commerce Cloud is the underlying resources used to run your instances and live sites that are managed by Salesforce. You never interact directly with the cloud, but it is the foundation that supports your site.
A B2C Commerce instance contains the tools and resources for customizing storefronts. You can access an instance through your browser, or you can use Business Manager.
There are four instance types: Sandbox, Staging, Development, and Production. Depending on the type, the instance is either in the realm's primary instance group (PIG) or a secondary instance group (SIG).
| Sandboxes | Staging | Development | Production | |
|---|---|---|---|---|
| Usage | Used by customer developers to create and update storefront code. Used by customer developers to create and update storefront code. | Merchandising work is done here. | Simulates the production environment. Used as the final step in testing the intersection of content and code. Goes through the CDN provided by B2C Commerce, but doesn't cache. | Live instance used for storefront transactions. Connected to the CDN provided by B2C Commerce. If active merchandising is enabled, collects active data. Storefront toolkit is disabled. |
| Location | SIG | PIG | PIG | PIG |
| 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. Active data is gathered from Production and imported into other instance types. Data can be exported from the instance and imported into Staging. |
| Global Release | Updated for: Preview and General Availability | Updated for: General Availability | Updated for: General Availability | Updated for: General Availability |
| Caching | Caching is disabled. Full file system checks are performed. | Not connected to the CDN provided by B2C Commerce. Caching is disabled. Full file system checks are performed. | Caching is disabled. No file system checks are performed. | Caching is enabled all the way through to the browser. |
Depending on the size of your team, one person can play more than one role.
| Role | Instance Type | Responsibilities |
|---|---|---|
| Developer | Sandbox, Staging | A developer creates or modifies templates, pipelines, and scripts on a local machine and uploads them to a Sandbox instance to test. Ultimately, the developer is responsible for uploading code to the Staging instance. The developer can also export data added by merchandisers on the Staging instance to use as test data for the sandboxes. Developers never use the Development instance unless they are involved in the testing process for the production site. |
| Merchandiser | Staging | A merchandiser or online marketer is typically responsible for creating campaigns and promotions, managing product information, and configuring search behavior. |
| Administrator | All instances | An admin is responsible for granting access to instances and functionality on instances. The admin restarts instances, manages data feeds, and uploads certificates. |
| Quality Assurance Engineer | Development | This role is responsible for testing the site in conditions as close to production as possible. No code development is done on the Development instance. |
If you have the correct permissions assigned to you, you can access the B2C Commerce tools.
- Business Manager--Configure storefronts in real time. Categorize, price, search, display, navigate, and promote merchandise.
- Control Center--Gives your IT staff operational control over your site, such as starting instances, and managing users.
- Account Manager--Lets your IT staff create user accounts on B2C Commerce, grant and revoke user access to B2C Commerce instan
You can import to and export from staging, development, and production instances and replicate between instances. If your storefront uses a third-party application, you are responsible for managing feeds into the catalog. You can create feeds from Salesforce B2C Commerce for other backend systems, such as an order management system (OMS), enterprise resource planning system (ERP), product information management system (PIM), or warehouse management system (WMS).
| B2C Commerce Feature | Description |
|---|---|
| Import and Export | Feeds data from external systems into B2C Commerce, such as product, pricing, and inventory information. You also Import and Export to move data from one instance type to another. Create XML feed files that conform to B2C Commerce schemas to import data into B2C Commerce. We recommend using the scheduled job feature to automate data import and export. Developers, administrators, and merchants must work together to determine the frequency and schedule of import feeds. Developers are responsible for implementing the cartridges. Admins are responsible for creating the XML files containing data from the systems of record for products, pricing, and other data. They are also responsible for configuring the jobs required to run the import. Data is validated during import. If the import experiences too many errors, it can fail. To recover from a failed import, you must successfully complete another import. |
| Data Replication and Code Replication | Securely moves data and code between instances. Replication is a one-way process from Staging to either a Development or Production instances. You can roll back from a replication to the previous version of the instance. |
| Code Upload | Used to upload code from a developer's local machine via UX Studio to a Sandbox or Staging instance. Developers are responsible for code upload. |
| Catalog Feeds | Used to process .zip files. This feature is only for additional information that is added to the catalog that isn't part of the normal catalog import and export process. |
The Batch Processing feature isn't used for data input and output.
In B2C Commerce, a site is the application and associated code that runs a storefront. A storefront the user's online experience. A site can have multiple storefronts with different URLs for different brands, locales (with currency and tax differences), or multiple channels. If you are referring to a specific URL, B2C Commerce uses the term storefront.
When designing your site, your architect must consider the following:
- The geographical relationship between storefronts and the teams that maintain them
- Data that is shared between sites, such as product data, tax and payment information, user roles and permissions, promotions, or application code
- Whether the storefront must be localized for different market locales or restructured for them
- Data that must remain separately controlled due to corporate structure or legal requirements
- Whether customer, basket, or transaction data carries over from one storefront to the next Example: An apparel retailer lets customers shop simultaneously at both their adult and children's sites. But a retailer with two different customer bases, such as a book publisher for religious books and fantasy fiction, can prevent crossover.
The simplest scenario is one site and one storefront that it supports.
If you have many storefronts and a single team maintaining them, you can manage them more easily as a single site, even if the products are different for each site. Similarly, if you want to share baskets between storefronts, the storefronts must be part of a single site. If you are deploying many localized sites with similar branding and products, it's faster and easier to manage new storefronts as an extension of an existing site.
You can have multiple sites, each of which supports multiple storefronts. You can also choose to share site data, such as customer data, between sites.
A live site is defined as a listing in the Manage Sites screen on the merchant's production instance of Business Manager with a status set to Online, not including those sites with other statuses or sites that have been deleted.