Anurag Gupta
Demandware is now Salesforce Commerce Cloud (SFCC). It’s part of the Salesforce product portfolio which is in line with the upcoming technologies in the e-commerce market. The platform’s capabilities have been extended to include Customer Relationship Management (CRM), marketing and customer service for both existing and new clients.
Most enterprise-level merchants go for Salesforce Commerce Cloud. Why? It supports both tailored content to groups of customers based on their purchase behaviour and personalisation via Salesforce’s Einstein, the AI-driven CRM engine. It’s a win-win situation for both the e-commerce merchants and their customers.
So, how Salesforce Commerce Cloud has transformed?
When Salesforce Commerce Cloud was Demandware
Initially, the Demandware platform was based on pipelines method. Pipelines are constructed with different nodes and each of the nodes performs different actions. For example, there is a list of node including start node, assign node, script node, decision node, call node, jump node etc. The executable logic is created using these nodes.
The drawbacks of pipelines in Demandware
In the pipeline method, it’s difficult to understand the logic as the developer needs to open the properties of each node to understand it.
It’s not possible to merge the pipeline changes in the repository as the entire structure is in diagrammatic representation.
Adding to it, the backend of the system converted the pipeline diagram into an XML.
Now! The Salesforce Commerce Cloud (SFCC)
Its a cloud-based SaaS e-commerce solution. The software-as-a-service (SaaS) solution is highly scalable for an optimised e-commerce experience.
SFCC transformed the architecture in accordance to new and upcoming technologies. SFCC changed its pipeline structure to controllers-based structure. The concept of creating the logic with node is now changed to pure code base. All the logic is written using the demandware APIs which increases the visibility of the code. It has largely rectified all the setbacks of pipelines structure by introducing the controllers approach.
How SFRA transformed SFCC?
The constantly evolving e-commerce market is now dominated by the usage of mobile devices and mobile e-commerce sites. As a result, SFCC introduced the Mobile First Reference Architecture(MFRA) or Storefront Reference Architecture(SFRA). It provides the best-in-class experience for e-commerce site visitors from mobile devices. The latest SFCC architecture also has pre-configured default templates which can be refined to meet e-commerce site requirements at a later stage.
This article is a high level overview of what’s new with SFRA in SFCC. It will help you understand the basic development strategies of this architecture in a more detailed manner.
How SFRA works?
The base cartridge from SFCC has the codes for the standard storefront. Generally, when a developer develops the client site they will modify the base code. However, in SFRA a developer shouldn’t make any changes to the base cartridge. They create a client cartridge which has the same structure as that of base and override the changes from base cartridge. This is the major change which has been introduced in SFCC’s latest SFRA.
Node Config Changes
We create two folders sfra and client. The base cartridge goes to the sfra folder and the client cartridge is placed on the client folder. In client folder, we need to set up the node configurations. Then, copy the webpack.config and package.json files from sfra folder and place it in client folder.
Make the following changes in the files
In client webpack.configs replace the path
‘path.resolve(‘./cartridges/app_storefront_base/cartridge/static’)’ with ‘path.resolve(‘./cartridges/app_storefront_client/cartridge/static’)’ in all the places.
In client package.json change the packageName and path with the client cartridge values.
“packageName”: “app_storefront_client”,
“paths”: {
“base”: “../sfra/cartridges/app_storefront_client/”
}
Then the js and css compilation is done on the client folder.
CSS Changes
In SFRA, the bootstrap framework helps in the responsive mobile-first front-end development. The SFCC uses the scss format for the css. Its compiled using nodes to generate the css file. All the scss files are placed in the directory structure
..\cartridges\app_storefront_base\cartridge\client\default\scss
These files are compiled a placed in the folder
./cartridges/app_storefront_base/cartridge/static
If a css file needs to be updated, we have to create a new file in the client cartridge and we have to import the base file in it. Then this client cartridge is compiled to form the css file.
@import “cart_base”;
JS Changes
The SFCC uses the jQuery library for the javascript front-end changes. The js files are placed in the directory structure.
.\cartridges\app_storefront_base\cartridge\client\default\js
These files are compiled using the node to generate the main js file. The generated js files are placed in the directory structure.
.\cartridges\app_storefront_base\cartridge\static\default\js
If a js file needs to be updated we have to create the same file in client cartridge and should require the base js file.
var base = require(‘../base/search/search’);
This will include the search.js base code into the client search.js file.
Controllers changes
MFRA defines Commerce Cloud endpoints (URIs) with a Controller-RouteName syntax. Defining an endpoint depends on the filename of your controller and the routes defined in the controller.
The controller file Home.js defines the route function ‘Show’ then in the storefront the generated URL will be like
http://www.mystore.com/on/demandware.store/Sites-YourShopHere-Site/EN_US/Home-Show
var server = require(‘server’);
server.get(‘Show’, locale, function (req, res, next) {
res.render(‘/home/homepage’);
next();
});
module.exports = server.exports();
This code will render the homepage.isml template. This is how a sample controller code works in SFCC.
A developer can extend the functionality of this controller by creating the same file in client cartridge. The ‘module.superModule’ global property provides access to the most recent module on the cartridge path.
Using ‘server.extend’, a developer can extend the specific controller server.append or server.prep and server.replace are the three functions used to update the controller functions. Please refer the sample code below.
var home= module.superModule;
var server = require(‘server’);
server.extend(home);
server.append(‘Show’, function(req, res, next) {
res.setViewData({ value: ‘Hello Commerce Cloud’ });
next();
});
module.exports = server.exports();
This blog explains the basic SFRA configuration and how to render a page using new SRFA architecture. You will also get an idea about how to make the CSS and JS changes in the base cartridge. It’s a high level overview of the SFRA architecture. It gives an overall idea about the structure and coding for the better understanding of the e-commerce site developers worldwide.
According to Zorang’s technical point of view, we recommend using SFRA in SFCC as an extensible baseline application. It helps your e-commerce site to be up to date on par with global standards.