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 business to consumer (B2C) / business to business (B2B) storefronts and web services for your SAP Commerce Cloud solution.
Table of Contents
Accelerators have been around in one form or another since SAP Commerce 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
Spartacus is intended to be the strategic way for creating storefronts with SAP Commerce Cloud. The intention is to have releases of Spartacus every 2 weeks. You should ensure you have checked the Spartacus Roadmap to confirm whether or not a feature from the B2C or B2B accelerator exists. It is 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, 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 a project and Spartacus offers the features you need, the recommendation is to start with a Spartacus-based storefront. If there are features missing in Spartacus that are available in the accelerator then you should evaluate the tradeoff. If you decide to move forward with an accelerator-based storefront we recommend to minimize the time you spend on customizing the storefront and have plans to create a Spartacus storefront in the future.
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: