Skip to main content

Explore the B2C Commerce Development Environment

Learning Objectives

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

  • List two tools used for the client portion of a Salesforce B2C Commerce storefront.
  • List the three key B2C Commerce software development tools.
  • Describe the elements of the MVC architecture.
  • List three tasks you can perform with scripts and controllers.

Look at the Tools

Whether you’re a new or an experienced B2C Commerce storefront application developer, you know the landscape. You start by looking at the tools.

A wrench - part of a toolkit

The three key B2C Commerce software development tools are Business Manager, Microsoft Visual Studio Code, and the Commerce Cloud Storefront Reference Architecture (SFRA). Other tools include the following:

  • Templates
  • Form definitions
  • Resource bundles
  • Scripts
  • Controllers

We’ll get into more details in a minute, but first, let’s talk about the architecture.

The MVC Architecture

We use the Model–View–Controller (MVC) architecture, which divides an application into three parts.

  • The model is the business logic, data, and rules underlying the application. Traditionally, models store the data that’s used to populate the view. In B2C Commerce, data is represented by APIs, which provide helper classes instead of storing data.
  • The view is what the shopper sees on the storefront. It’s the landing page, the product details page, QuickView, or the cart page.
  • The controller takes shopper input from entry fields, button clicks, and the like, and converts them into actions or data that’s consumed by the model or view.

The MVC architecture - Model, View, and Controller

While this architecture provides a map of how the elements work together, the code still needs a deployment mechanism. That’s where the cartridge comes in.

B2C Commerce Cartridges

A cartridge is how B2C Commerce packages and deploys program code and data. It delivers generic or application-specific functionality. For example, a merchant sells multiple brands, each with its own site. Because they sell apparel, all sites have similar processes. But the look and feel of the sites differ by brand. Generic cartridges contain standard processes, while application-specific cartridges contain brand-specific code and data.

Let's Start With What We're Building

Let’s start by talking about what we’re building, from the top down.

Storefront pages display on the client, whether it’s a desktop or a mobile device. These are some standard storefront pages:

  • Home
  • Category
  • Product details
  • Search results

These pages are in proprietary ISML, which is based on HTML and uses CSS for formatting—industry standard stuff. Shoppers interact on these pages by clicking buttons and tabs and entering text into fields. The development tools used here are called templates and form definitions.

With these tools you can:

  • Validate shopper input
  • Prompt shoppers for confirmation
  • Show error or informational boxes
  • Conditionalize HTML

There’s an application processing component on both client and server. This is the code that takes the clicks and data entry from the pages and does something with it. The development tools used here are scripts and controllers.

With these tools you can:

  • Add calculations and logic to business processes
  • Call web services
  • Integrate back-end systems
  • Share information across users

Now let’s talk about the processing part.

Coding Storefront Pages

The storefront pages are the visuals—the nifty products, flashy advertisements, and crafty discounts. For these you need templates, form definitions, and resource bundles—client-based only.

Templates

Templates define how data and page information is transformed into HTML-based web pages. These pages are rendered on the browser using CSS for page layout and styling and the B2C Commerce form definitions for data display and verification. Templates are coded in the Internet Store Markup Language (ISML) that dynamically generates HTML. It provides a number of predefined tags (for example, <isif>/<isloop>) and uses script blocks and expressions.

With ISML, you can use a single template to show thousands of products. For example, the search results page shows a list of products in rows and columns of tiles as defined by a template.

Form Definitions

Form definitions let you control how customer-entered values are validated and rendered on the browser. With forms, for example, you can specify that ZIP codes must be entered as a precise series of integers; while name and address information must be entered as strings. Like with ISML, B2C Commerce form definitions use a distinct language and are proprietary.

Example of an address form

Form definitions are stored in the forms folder of a cartridge (cartridge/forms/default). A form schema file identifies allowed elements and attributes. Form definitions interact with both the display and the processing parts of storefront applications.

Resource Bundles

You want to avoid hard-coding text strings in storefront code that are visible to the shopper. Do this by storing titles, labels, messages, button and field names in resource bundles (also called .properties files). Keeping this text separate from display layout makes it easy to change the text for different purposes, especially when supporting different locales.

Process the Storefront Application

The processing part of the application displays, sends, calculates, or retrieves the right details from arrival to checkout—all at the shopper’s initiative. To do this, the application uses scripts and controllers.

To upload code, use the SFRA Upload Tool or an upload utility, such as webdav, a standard protocol. Upload utilities are available from the B2C Commerce community repositories in GitHub. You can also use standard JavaScript tools, including linters and static code analysis tools.

Scripts

You develop your application locally in Visual Studio Code, but run it on the server. A JavaScript interpreter runs on the application server to process each JavaScript class or method. To the JavaScript interpreter, the source of the script call is irrelevant. This gives you flexibility in the tools that you can choose.

B2C Commerce has some serious application program interfaces (APIs) with the B2C Commerce Script APIs and the Open Commerce APIs (OCAPI). OCAPI is a RESTful API, which receives HTTP requests and returns responses. The request construction and response consumption is up to you.

Use the B2C Commerce API to build all parts of a storefront’s user experience. Use OCAPI to integrate third party systems and to unify customer journeys that go beyond the Commerce Cloud hosted experience.

The B2C Commerce Script API supports industry standards. See Script Programming and Compatibility Mode Changes in Salesforce Help for details.

Controllers

Controllers are server-side scripts that handle storefront requests. Controllers orchestrate your storefront’s back-end processing and create instances of models and views to process each storefront request and generate an appropriate response. For example, clicking a category menu item or entering a search term triggers a controller that renders a page.

Controllers are written in JavaScript and B2C Commerce script. The file extension of a controller can be either .ds or .js. Controllers must be located in the controllers folder at the top level of the cartridge.

You can use any IDE with a JavaScript editor to develop controllers.

Getting Started

There are lots of steps when you start out with this environment, but it boils down to these:

  1. Take a look at the Salesforce Developers Center for Commerce Cloud.
  2. Get a sandbox from B2C Commerce Support (or from your LINK partner program manager, if you’re a LINK partner developer).
  3. Download and install and integrated development environment (IDE) such as Microsoft Visual Studio Code.
  4. Open Business Manager, where you:
    • Register your cartridges.
    • Import Storefront Reference Architecture data into your sandbox so you can use it as a starting point or for code examples.
    • Ensure that page caching is disabled so you can see your changes immediately.
    • Generate search indexes so search works properly in your application.
    • View the storefront.

Next Steps

In this unit, we explored the B2C Commerce development environment, gaining a better understanding of the tools we use and why. We also learned about the steps required to build the development environment and some of the available alternatives. In the next unit, we learn about the Commerce Cloud Storefront Reference Architecture.

Formez-vous gratuitement !
Créez un compte pour continuer.
Qu’est-ce que vous y gagnez ?
  • Obtenez des recommandations personnalisées pour vos objectifs de carrière
  • Mettez en pratique vos compétences grâce à des défis pratiques et à des questionnaires
  • Suivez et partagez vos progrès avec des employeurs
  • Découvrez des opportunités de mentorat et de carrière