Spartacus 5

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



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:

  • stopping support on the previous Spartcus versions (4.x);
  • that Version 5 would be only available within an authenticated policy to SAP partners / customers; and
  • Spartacus is renamed to Composable Commerce.

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:

  • 4.3.8 specified use of Angular CLI version 12.x (but earlier than Angular CLI version 13). Angular 12 was released May 2021 and its development activity ended in November 2021 and long term support ended November 2022. Therefore, the cessation of support from SAP on Spartacus 4.3.8 coincided with the cessation of support on Angular 12 itself.
  • 4.3.8 also required Node.js version 14.15, and SAP stated that the previously supported Node.js version 12.x had reached end of life in April 2022 (this page: ) . There are many Node.js releases (see ) and releases of node.js 14.15.x were between October 2020 and February 2021, and active support ended October 2021 although security support ends in April 2023 (see );
  • 4.3.8 required use of the Yarn package manager version 1.15 or later and although there is a Yarn 2, the version 1.15 still runs the installation.

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:

  • V5 requires Angular 14.x, (the latest 14.x is advised), and Angular 14 was released in June 2022 with its development activity ending in December 2022 and its support ending December 2023. This therefore suggests a stable but non-changing release of Angular is being used in V5 which has support in place from the Angular team at Google for critical fixes and security patches. Angular 15 was released in November 2022 and therefore maybe within the next 12 months SAP will mandate a future release of Composable Commerce to use Angular 15 – my guess is that it is already in the SAP labs.
  • V5 requires Node.js Version 14.15 or newer (but less than version 15), or Node 16.10 or newer. However, Node.js V14 long term support ends in April 2023 and for V16 long term support ends in September 2023.
  • There are multiple subsequent releases of Yarn, but SAP still cite 1.15 is suitable for setup of Composable Commerce 5

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

“Bug Fix” update release:

  • Contains backwards-compatible bug fixes.
  • Published approximately every week, as needed.
  • Called patch in the semantic versioning.

“Minor” update release:

  • Contains new functionality that is backwards-compatible.
  • Published approximately eight times per year.
  • Called minor in the semantic versioning.

“Major” update release:

  • Contain bug fixes and new functionality, some of which are not compatible with a previous update release.
  • Published approximately two to three times per year.
  • Called major in the semantic versioning.


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:

  • That update releases will remain current for a minimum of 3 months (unless otherwise stated);
  • A roll-forward approach is used whereby only the latest update release of the libraries will have bug fixes and new features;
  • Building the Composable Storefront in the SAP Commerce Cloud Portal (CCV2) will only allow builds against the designated storefront releases.

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

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:

  • An S-user with administrative credentials accesses the SAP Repositories Management portal at and logs in;
  • The S-user uses the “Add New User” wizard to create a technical user, giving their name (a unique string);
    • The Portal creates the technical user and prefixes the organisation to the specified name;
  • The portal generates a number of authentication tokens for the technical user, and the token called “NPM Base64 Credentials” should be noted as it is needed for accessing the Composable Storefront libraries. It is of the order 70 characters in length, and in my case it had a 6 month validity period.
  • A text editable file called .npmrc should be created in the root of the Composable Storefront project folder with the following content:

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


What is happening here?

  • Yarn version 1.x is able to read registry settings in the .npmrc file;
  • A registry setting for @Spartacus defines the location and the NPM credentials provided for the technical user;
  • The URL is most probably an authenticating proxy at SAP which will proxy the Yarn installation process to the location of the Composable Storefront libraries;
  • The yarn installation will then read and download the libraries in the same way as we used to in Spartacus 4.x from the npm Git repositories.

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:

Does Spartacus fit our composable criteria?

  • It is clearly a headless approach, there is a separation of presentation and business logic (presentation in Spartacus, business in SAP Commerce) although there is perhaps a principal to watch out for whether any business logic finds its way into any customised node.js code that is developed;
  • Regarding it being cloud-native, although SAP want customers to use their CCV2 cloud environment the product is not really cloud-native – that would be the case if you could only access the product in a cloud environment, even if that were for development purposes. SAP has in this case retained the approach whereby developers have their own local instances of the software – both SAP Commerce Cloud and the Composable Storefront.

It could be said that our modularity principles are met:

  • SAP Commerce itself has historically been used in headless operations for many years with third-party content management systems from a number of providers, whether that typically reduces application development time and effort though is probably debateable;
  • SAP Commerce (although regarded as a monolithic product) certainly does find its way into multiple scenarios for service consumption, and SAP state that the Composable Storefront can potentially be used in other scenarios and systems.

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.



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:

  • You have to locate the release information in the SAP help pages at the moment – it would benefit implementers if this information were either published in the SAP Commerce Portal or via an alerting process; this would give customers chance to evaluate a new release with their system and plan for updates;
  • Some customers quite often have code freezes of major changes during busy trading periods, and if SAP are continuing to issue new releases and to decommission older versions that might have significant impacts on customer release cycles including need for comprehensive regression tests; clients need the timing flexibility for when they do releases and not be constrained by releases that SAP are issuing, especially if there is nothing in the release of benefit to the customer;
  • SAP should be much more open about when they plan to migrate to newer releases of the key dependencies of Angular and Node.js to give plenty of time for customers to test their own customizations;
  • SAP should look to extend the functionality of the CCV2 portal and deployment process so that Composable Storefront core components can be pulled from their own repository rather than all be uploaded as part of the build;
  • It would be really helpful if SAP created 2 more installation recipes – one for just Composable Storefront B2C and one for just Composable Storefront B2B – the combined recipe which includes both B2B and B2C and also both Composable and conventional storefront really does take ages to compile, initialize and startup.

Leave a Reply