Spartacus 5

 

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

 

Composable Commerce – Angular and Node.js Dependencies

 

Composable Commerce – Release Policies

“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

---

 

Access to the V5 Libraries

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 https://ui.repositories.cloud.sap/ 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:

  @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?

• 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.

 

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:

• 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.