by Kyle Ballard | Programming, Salesforce

Developer Introduction to Salesforce B2C Commerce Cloud

Introduction

In 2016, Salesforce acquired a company known as Demandware, and re-branded their solution as Salesforce Commerce Cloud. Later, in 2018, Salesforce acquired a company known as CloudCraze, and that later became known as Salesforce B2B Commerce, and the original Demandware acquisition became known as B2C Commerce. One key difference between these two solutions is that the B2B Commerce product runs “on platform”, and the B2C (Demandware) product does not.

The development paradigm for B2C Commerce Cloud relies on developer knowledge of server-side Javascript (similar to NodeJS, but is actually Rhino Javascript). Similar to the Marketing Cloud (ExactTarget) product, developers who are used to developing with Salesforce DX, Lightning Web Components, and Apex will find that there is none of that here. The entire solution is different, however that has changed somewhat with the introduction of add-on products like Salesforce OMS, Salesforce Loyalty, and other features which run on-platform, but are integrated with B2C Commerce. Additionally, there is in-fact, an accelerator from Mulesoft, which will let you quickly connect your B2C Commerce instance to your core sales/service instance(s). It is not required to integrate the two, but does greatly simplify the process.

Core Features

As you would expect with any Enterprise grade commerce solution, core features exist such as multi-site and advanced discounting/promotions while also providing technology features such as logging, caching, an open commerce API (OCAPI), and separate environments. Salesforce deploys 8-10 updates a year to the product (just not during peak shopping season).

The back office of B2C Commerce is management dashboard is referred to as Business Manager. This is the UI that allows you to setup and configure your solution. Here you can configure core features, or more advanced features like Einstein search, code deployments, jobs, and so on.

Newer add-ons to the solution are on-demand sandboxes (ODS) (allowing a simple CI/CD development pipeline), and their page designer feature which is fully capable of handling baseline content needs for any commerce solution. If the page designer is insufficient for content needs, it is also possible to use B2C Commerce in a headless fashion, or to pull in content from Salesforce CMS.

Developing for Salesforce Commerce Cloud

Historically, development for Salesforce Commerce Cloud was done using the Eclipse IDE and the UX Studio plugin. Recently, there has been a shift over to using Visual Studio Code using the Prophet Debugger extension. This extension will allow you to deploy code up to your sandbox, remotely debug your code, and more. All of the code you deploy runs in what Salesforce calls realms and you can think of this as a remote server for simplicity sake, with different environments for dev, staging, and production. Details for how to setup your environment are all available on the Github repo for the extension.

As an important aside to developer sandboxes, which are necessary to do development for B2C Commerce Cloud… you currently must either be a Salesforce customer or a Salesforce partner in order to obtain one of these sandboxes. I do hope with the introduction of the on-demand sandboxes that this is something which is opened for all developers in the future, but for now those two important caveats apply.

Once you are up and running, know that all of your code will be organized into cartridges. Think of these cartridges as consolidated blocks of functionality. If you come from the world of .NET, then this would be akin to a class library. Inside each cartridge, you may setup controllers (for page components), view files (referred to as ISML templates), model files, as well as jobs and other business logic. Jorge Hernandez has a great set of sample repositories on Github, including this sample cartridge repository.

One you have your cartridge created, you add your cartridge name to the cartridge path. This path defines all of the cartridges (and thus all controllers, views, back-end logic, etc) that are loaded for a given site, and also loads those cartridges in the order they were specified. So you may have a base/core ‘product’ controller you typically use, but later downstream in your cartridge path you may add a site-specific cartridge which has a unique product controller, and that will override your base controller.

Next Steps

This post could carry on to cover an entire book, but hopefully I’ve provided you with enough information to provide a solid foundation around the tools and capabilities used to support development for B2C Commerce. There are several resources you could use if you wished to learn more:

 

Kyle Ballard