A note from 2026: This article was published in 2023. Spartacus is now SAP Composable Storefront, and the version/dependency details discussed here are historical: Angular 14 and Node.js 14/16 are out of support, and SAP Commerce Cloud/Composable Storefront releases have moved on since 5.x.

This article is brought by
Robert Bull
Lead Solution Architect

Contributors & Editors:
Myles Bunbury, P.Eng, Senior Director, Technology Solutions, Global SAP Customer Experience Lead
Rauf Aliev, Chief Software Engineer, Solution Architect

 
Robert Bull

For those who have been following the development progress of Spartacus, the Angular/Node.js front-end to Commerce Cloud, you may have followed the roadmap information on the SAP GitHub Spartacus repository documentation pages. For many months during 2022 the roadmap statements indicated that release 5 would be towards the end of 2022 comprising a number of user experience and feature improvements, architecture improvements including the need to upgrade the underlying technologies such as the Angular framework.

As would be expected, SAP publish disclaimers of forward-looking statements on any release, advising implementors regarding:

… forward-looking statements are subject to various risks and uncertainties that could cause actual results to differ materially from expectations

and that:

… Any information is subject to change for any reason without notice. The information in this document is not a commitment, promise or legal obligation to deliver any material, code or functionality.

However, I was a bit surprised (and I suspect other readers also) when SAP announced:

I will explore each of these areas in more detail below.

Stopping Support on Spartacus V4.x

At time of writing, the latest open release was v4.3.8 on 8 November 2022. That release had amounted to 1,643 accumulated releases which aligns to SAP’s position of publishing a release every week or so.

Spartacus 4.3.8 also comprises a good demonstrable setup with SAP Commerce releases 1905, 2005, 2011, and 2105 and SAP has maintained a good portfolio of sample data for the Spartacus storefronts with clear instructions how to create and build a combined specific recipe of B2C (apparel and electronics) and B2B storefronts (powertools). You can build a working Spartacus/SAP Commerce demo on a laptop within a few hours.

It does make sense to encourage users to upgrade to V5, partly on the basis of the progression of the underlying technology being used:

In summary, SAP supported 4.3.8 until such time that the pre-requisite components were themselves out of support, and it makes sense for V5 to be released and to use newer versions of Angular and Node.js.

Composable Commerce – Angular and Node.js Dependencies

It is logical for SAP to be able to offer any support prospect related to Composable Commerce by ensuring that the key dependent components are themselves within a support prospect. Looking at the key dependencies and the stated V5 requirements:

Why not support Node.js V15 ? This is most probably because odd-numbered releases of Node.js go into End-of-Life as soon as the next even numbered release is made available. In general, Major Releases of Node.js are for incompatible API changes, from version to version. Minor Releases include backward compatible functionality changes. The Even numbered releases go into long term support from the OpenJS Foundation whereas the odd numbered releases do not. Therefore, with availability of V16, it makes sense for SAP to avoid V15.

Even still, with active development support for Node.js 14 and 16 already ended and long term support for both 14 and 16 ending this year, it makes sense for SAP to update Composable Commerce in the future to use a newer version of Node.js (such as version 18) which has a long term support prospect well into 2025 – this is something for implementers to be looking out for.

Composable Commerce – Release Policies

SAP states the release frequency of the Composable Storefront as follows, using the Semantic Versioning approach defined https://semver.org:

“Bug Fix” update release:

“Minor” update release:

“Major” update release:

Composable Commerce – Release Publication

SAP states in its Help Portal that they will publish update releases on a continuous basis to contain bug fixes and/or feature updates. This page I believe: SAP: About the Composable Storefront

Other key policy approaches comprise:

It is therefore important to keep on top of the release management aspects to avoid potential deployments failing due to SAP removing a Composable Storefront release which your system is assuming. At the time of writing, both 5.0.0 and 5.1.0 are designated as “Current” with supported releases of Commerce Cloud 2105, 2205 and 2211. It will be interesting to “watch this space” to see the dynamic of these supported releases in order to gauge an understanding of the timing and frequency in support/maintenance of this combination of SAP products. According to SAP help pages:

Customers are strongly encouraged to regularly schedule upgrades to the latest update release to mitigate risks and potential issues, such as but not limited to the following: 1) Not upgrading to a current update release of composable storefront exposes you to the risk of software defects, as well as performance, availability, functionality, or security issues. 2) Creating a new build of your application using an update release of composable storefront that is not current, may result in build errors — as a result, you will be unable to deploy new code

We do see similarities of this in conventional SAAS platforms where the vendor has responsibility of maintaining the service, its feature development and backward compatibility. For those using the SAP Commerce platform and the Composable Storefront, this is a gentle introduction towards a more conventional SAAS approach and I suspect SAP are keeping a careful observation on feedback and acceptance of this approach.

Access to the V5 Libraries

There is a key change from SAP regarding access control to the V5.x libraries. As a reminder, the Spartacus 4.x libraries are available from the node package manager npm Registry (which hosts a multitude of packages and version control management based on Git). However, the Composable Storefront libraries are now only available via SAP’s Repository Based Shipment Channel (RBSC), and this uses an authenticated approach to allow the Yarn utility to retrieve the libraries. Yarn is capable of installing packages from a specified cache location (something that I understand the conventional node package manager cannot do).

What is RBSC? it is a software delivery channel that serves commercial software deliveries to SAP customers comprising dedicated product repositories that provide an authenticated download capability. Access is granted based on a license validation and is attached to an authorised SAP S-user. However, the S-user needs to create a technical user in the RBSC Repository Management Portal, and the portal will generate some access key credentials for the technical user.

Fig. 1 – Creating the Technical User in the SAP Repositories Management Portal

Creating the Technical User in the SAP Repositories Management Portal

The implementer now has to create a file in the folder where the Composable Storefront is installed and the file contains both the SAP RBSC download location for the Composable Storefront libraries and the technical user NPM token. When the Yarn installation process is invoked, the authentication credentials are used by Yarn to download the Composable Storefront libraries. To summarise:

@spartacus:registry=https://73554900100900004337.npmsrv.base.repositories.cloud.sap/
//73554900100900004337.npmsrv.base.repositories.cloud.sap/:_auth=<npmcredentialsfromrbsc>
always-auth=true

The leading // are required. The Technical User NPM Credentials are substituted for the npmcredentialsfromrbsc

What is happening here?

I noted that for EPAM being a SAP partner, the S-User had capability to create 20 technical users. I don’t know if more can be created on request or if that number is different for SAP customers or other partners. Note, if you are doing this installation on behalf of a SAP licencee, then the technical user must be created by an S-User in that licencee name.

Once the libraries are obtained, in theory, if your Technical User NPM code were to expire then that would not matter if you do not need any libraries updated. However, as stated above that these libraries are being frequently updated, please do check or put in place a method to ensure the technical user credentials remain valid.

Building Composable Storefront for your Application in CCV2

As per this page, SAP: Using Composable Storefront with SAP Commerce Cloud in the Public Cloud , the hosting service of SAP Commerce Cloud cannot be built for building the composable storefront application. It has to be built locally and uploaded as a compiled application.

Renaming to Spartacus to Composable Commerce

I suppose that it was inevitable that SAP would want to somehow name something with the term composable – a Google search on composable architecture will find virtually every other supplier somehow involving this terminology. It seems to follow on from headless and MACH. In the technical consultancy team I am part of, we spent quite some time last year defining (arguing) a definition of composable architecture as one which:

extends modularity principles to use independently sourced component services to reduce application development time and effort. Component services should be designed and operated for autonomous consumption in multiple scenarios. Such architectures frequently follow modern design and implementation principles:

  • A headless approach, providing clear separation between presentation and business logic;
  • Uses cloud native solutions and approaches such as infrastructure as code for deployment; and,
  • Takes advantage of loosely coupled sync/async integrations.

We can depict these different architectural approaches:

Different architectural approaches

Does Spartacus fit our composable criteria?

It could be said that our modularity principles are met:

However, we tend to see composability meaning that there are not just two components (front-end and back-end) but multiple components such as micro-services, SAAS components, BFF etc. and in this sense I would see a point of view that this is not really a composable architecture. However, if you look at many SAP Commerce systems in a larger scale, there is often an ERP system, a CRM system, and an order management system so maybe in the larger scale we could envisage the storefront and SAP Commerce as composable components.

However, back to the name itself, I suspect many will still call it Spartacus, the code and SAP Help pages are full of that name in the same way that SAP Commerce is still referred to as Hybris by many, and the code is full of the hybris terminology.

Conclusions

I haven’t focussed in this article on the functionality or the look and feel of the Composable Storefront, the build process is more or less the same as V4.3.8 only the access to the libraries has changed. I can see some concerns and possible improvements in the logistics:

Composable Storefront screenshot