Choosing Which Storefront to Use for Your SAP Commerce Cloud Solution
With many options for creating storefronts with SAP Commerce Cloud, it may seem daunting to decide which options to pursue. In this article, we cover the available options, provide recommendations on how to potentially choose which option is best, as well as covering how you configure B2C/B2B storefronts and web services for your SAP Commerce Cloud solution.
Table of Contents
Accelerators have been around in one form or another since version 4.4 and are intended as a starting template for storefronts. The current B2C responsive storefront accelerator was introduced in version 5.4 and has had additional improvements through successive versions, including the addition of a B2B add-on to add B2B capabilities. The templates provide pre-built example storefronts with examples in fashion, electronics and powertools, to provide a starting point for the features and functionality included as part of SAP Commerce Cloud. They can then be customized as needed to meet your requirements. Below are some introductory videos that show off both B2C and B2B accelerators:
There are also additional industry-specific accelerators, such as the Travel, Telco & Media, Financial Services and Citizen Engagement Accelerators, which have separate development cycles but are still dependent on specific versions of SAP Commerce. If you are using SAP Commerce Cloud you need to ensure you have consulted the Compatibility Matrix to ensure it is supported. Below is a video showing an example of the features included in the Telco accelerator.
Spartacus JS Storefront
Long term, the intention is for Spartacus to become the defacto way of creating storefronts for SAP Commerce Cloud. It will be supported by SmartEdit to ensure business users can modify page templates while also leaving developers many options to extend and customize the storefronts to meet requirements. As an open-source project, you will be able to pull down the latest changes at any time and incorporate them into your solution.
For more info see:
There are some cases where none of the solutions mentioned above will work. Typical examples we've seen include:
- The implementation team is more comfortable with a programming language the storefronts don't use (for example, Ruby).
- Significant portion of requirements do not align with the template storefronts and the amount of time to customize may be more than building a custom solution from scratch.
In both these situations, the onus for supporting all aspects of the storefront will be your responsibility. If you are looking to build a custom storefront on top of SAP Commerce Cloud, your best option is to leverage the OCC, similar to what the Spartacus JS Storefront is doing. If a web service you require does not exist, then you will need to create it yourself.
How To Choose
With so many options, it can be tough to decide which storefront to choose. The answer will depend on a few factors such as whether you already have an existing storefront and your level of confidence with using Alpha/Beta code (Spartacus does not yet have a release candidate) versus creating a storefront from scratch. We have outlined the options in the following decision tree. If you are already on the accelerator or considering using it, it is best to continue monitoring the Roadmap to understand the progress of the Spartacus JS Storefront and when it may have the features you need. Because the accelerators and Spartacus JS Storefront are built on completely different technology stacks, there will not be a migration tool. A full rewrite will be necessary. If you are just starting with the accelerator and you plan to move to Spartacus JS Storefront (that is, when it is officially released), we recommend to minimize the time you spend on customizing the storefront to minimize rework.
Deployment of B2C and B2B Storefronts
If you are using the accelerators, you may want to deploy and run your B2C and B2B storefronts in one SAP Commerce Cloud instance. This section describes implementation steps and possible limitations around the proposed solution.
Though this installation example is based on the out-of-the-box (OOTB) recipe scenario, it can be applied to other custom installations. Typically, when the b2c_b2b_acc or b2c_b2b_acc_plus recipe is executed, it creates a B2B storefront extension named yb2bacceleratorstorefront in /custom folder. This B2B storefront extension is based on the yacceleratorstorefront extension plus b2bacceleratoraddon.
The following fragments below demonstrate important sections of the manifest.json necessary to run the CCV2 build and deployment of the B2C and B2B storefronts.
Make sure the “storefrontAddons” section contains the B2B-related addons with their corresponding extensions the addons are being installed into. As per a paragraph above, the addons should be installed into both yacceleratorstorefront and yb2bacceleratorstorefront.
Specify separate context root for both B2B and B2C storefronts as per JSON fragment provided below:
Each storefront should have its own JSESSIONID cookie specified as well as the cookie path.
Another important setting is a ContextPath for each storefront. The ContextPath goes for each storefront application specified in the “webapps” section. The JSON fragment that demonstrates this setting is provided below: