This is Jerry’s 86th article in 2020, and Wang Zixi’s 268th original article in total.

The video version of this article is as follows:

https://v.qq.com/x/page/b3212…

This is part of SAP TechEd 2020, the ultimate experience in the era of “customer autonomy” :

This article is mainly divided into the following four aspects to introduce Spartacus.

First of all, through the introduction of the four features of Spartacus, we will have an intuitive understanding of Storefront, the e-commerce front store application as the new generation of SAP Commerce Cloud. The front page of Spartacus is shown below, and its logo is a shopping bag with lightning bolts printed on it, symbolizing the smooth and fast online shopping experience that Spartacus can bring to users.

Secondly, by comparing with Commerce Cloud’s original Accelerator based Storefront, we can understand the reason why SAP launched Spartacus.

This is followed by a brief introduction to the Spartacus technology architecture.

Finally, SAP Commerce practitioners may be more concerned about a topic, that is, Spartacus release mode and update frequency, because this topic is also closely related to whether the majority of Commerce practitioners decide to choose Spartacus.

SAP Commerce Cloud is an e-commerce solution of SAP, and the term Storefront refers to the front store interface of the solution. In a word, Spartacus is a new SAP Commerce Cloud Storefront based on modern Web development technologies and frameworks.

So what is modern? Spartacus 1.0 was released in July 2019, so Spartacus has the unique advantage of taking a more mature and modern front-end technology to develop compared to the previous generation of Accelerator based Storefront.

One of the features of Spartacus: Single Page Application

That’s how Spartacus got its name. A single-page application consists of an HTML page called a shell and multiple page fragments that contain specific business logic.

Commerce’s traditional Storefront is implemented based on JSP, a server-side rendering technology in which page code is generated on the Commerce server-side. The single-page application is a rich client technology. The rendering of page fragments and page routing are done on the client side, which reduces the load of Commerce server. When the interface content of a single-page application changes, it does not need to reload the entire shell HTML page, but only needs to update the relevant page fragments that have changed. In this way, the switching between pages is more smooth and the user experience is better than that of multi-page applications.

Spartacus feature two: responsive design and adaptive design

These are two confusing concepts in the field of user experience for Web applications, as they both address the problem of web pages being displayed on devices of different screen sizes. From a programming perspective, responsive design, through a variety of front-end technologies, gives page elements the ability to automatically adjust their display behavior according to changes in screen resolution for optimal display.

For example, the list control in Spartacus reduces the number of list fields displayed as the screen width decreases. The adaptive design implements different pages for different types of devices, and calls the corresponding web pages when the device resolution is detected. Spartacus’s page design is mostly responsive layout, but it also supports adaptive layout features.

Commerce’s CMS module divided the Storefront UI into zones based on logical functional dependencies, and Spartacus allowed users to configure which UI components should be displayed in different zones based on different screen sizes.

Spartacus Feature # 3:100% API-driven

The Commerce Cloud provides a set of RESTful APIs called Omni Commerce Connect(OCC).

Spartacus uses the standard HTTP protocol to call this set of APIs for the purpose of interacting with the Commerce Cloud. On a programmatic level, the 100% API driver ensures Spartacus’s front-end separation so that secondary Spartacus developers don’t need to understand the implementation details of the Commerce platform’s Java layer. Previous secondary development of Storefront, based on Commerce Accelerator technology, required full-stack developers who knew how to use JSP and Java.

On a deeper level, the 100% API drive also decouples Spartacus from the Commerce platform, greatly improving Spartacus’ upgradability. And we’ll see that a little bit more in the comparison between Accelerator and Spartacus.

Spartacus Feature # 4: Open Source, Free

Spartacus’s code is completely open source and hosted on GitHub. If you look at the list of code contributors on the GitHub repository, you’ll see that some of these contributors are SAP employees like Jerry, others are from Partner companies, and some are freelancers. SAP chose to open source Spartacus, hoping to build a thriving ecosystem and continue to innovate in Commerce Storefront with other contributors in the open source community.

So why did SAP launch Spartacus? It starts with Accelerator, SAP Commerce’s traditional Storefront implementation technology before Spartacus.

Accelerator is the Storefront implementation technology used in the SAP Commerce Cloud before Spartacus was released.

Accelerator is an out-of-the-box Web implementation template that is part of the Commerce platform and delivered to customers as source code. Customers generate their own Storefront implementation based on the Accelerator template code through a tool called the Module Generator, and then proceed with secondary development based on this generated code. This type of source code generation really speeds up secondary development of a customer’s Storefront, hence the name Accelerator.

However, the tight coupling relationship between Accelerator and Commerce platform and the secondary development approach based on source code level pose great challenges to the scalability of Commerce project implementation. For example, when a customer finds a new version of Accelerator that meets their new business needs, they want to upgrade Accelerator. However, as Accelerator is part of the Commerce platform, the entire Commerce system must be upgraded first, and then the Module Generator is used to regenerate the custom implementation based on the higher version of Accelerator code. The secondary development based on the lower version of Accelerator template is then manually migrated one by one into the custom implementation generated by the higher version of Accelerator.

When the secondary development of Commerce reaches a certain scale, this manual upgrade approach is challenging.

The shortcomings of Accelerator were solved by Spartacus.

Accelerator provides a Storefront development template as source code, while Spartacus provides a lightweight Storefront development framework as a library. We create a new Angular app and import the Spartacus library dependency. When we need to update Spartacus, we simply update the Spartacus library version number in the Angular app’s package.json file. So Spartacus is a huge leap forward in scalability.

Spartacus uses an API to interact with Commerce, which allows Spartacus to be deployed separately from Commerce and upgraded separately, such as Spartacus 3.0, which has been released to support all Commerce releases since 1905 and later. Spartacus is developed with Angular and compiled to generate JavaScript code as its runtime language. As a result, secondary developers using Spartacus no longer need to master the full-stack development technology stack of front-end JSPs and back-end Java as they did with Accelerator in the past.

Accelerator extensibility is achieved at the expense of upgradability. Spartacus has a much more diverse approach to scalability than Accelerator, which has a single extension with source-level modifications.

(1) One of the modules of Spartacus, ConfigurModule, exposes the business logic, page layout and style through configuration. Secondary developers can change the default behavior and page layout and style of Spartacus by tweaking the configuration.

(2) Spartacus’s page layout consists of different Angular components that correspond one-to-one to Commerce’s CMS components. Spartacus allows secondary developers to enhance and even develop new Angular components that replace the default components Spartacus was released with to meet customers’ page customization requirements.

(3) With Angular’s powerful dependency injection mechanism, Spartacus allows developers to develop their own Service implementations in the same way that Commerce back-end developers use the Java Spring framework. Customize Spartacus’s workflow and logic by injecting a self-developed service through Angular’s Dependency Injection mechanism.

Let’s take a brief look at some of the technology stacks Spartacus uses and the fundamentals of Spartacus’ interaction with Commerce.

As mentioned earlier, Spartacus is a Storefront development framework built on modern Web development techniques. Therefore, the technology stack involved is the current front-end development generally used some of the more mature technology.

Angular: A web front-end development framework maintained by Google that draws on a number of decades-old backend development concepts, such as dependency injection, interfaces, annotations, etc., that are particularly useful when developing large-scale enterprise front-end applications that require constant iteration and maintenance. Angular is also a Progressive framework, with support for TypeScript, deep integration with RxJS, and immediate support for Progressive Web Application (Progressive Web Application concept).

Spartacus 1.0 is based on Angular 9, and the latest Spartacus 3.0 is based on Angular 10. Google released the latest Angular 11 last month, and currently the architects on our team are evaluating the technical feasibility of Spartacus supporting Angular 11.

TypeScript: Angular is developed with TypeScript, ES5, and ES6 as versions of JavaScript, and TypeScript is not only a superset of ES6, but also a statically typed programming language. In 2018, there was a statistical report on the top 10 types of errors that occurred most frequently in front-end projects, and the top 7 were all related to type errors:

TypeScript’s compiler static type checking prevents many type errors. Strong typed interfaces create a contract between service implementors and service invokers that reduces coupling between Spartacus components and services, helping open source projects like Spartacus, whose developers come from all over the world, develop more efficiently.

RxJS: Reactive Extension JavaScript is a Reactive programming practice and Angular is a heavy user of the RxJS library. At the heart of RxJS is an Observable, and Spartacus’s implementation, using RxJS observables, encapsulates the asynchronous operation of reading business data from Commerce. Spartacus can flexibly control the timing of the asynchronous reading of Commerce business data and aggregate or split the data flow between Spartacus and Commerce through the various operators that RxJS provides on observables.

Ngrx: A library used by Angular applications to gracefully manage application state. Angular, like other major front-end frameworks, follows componentization development standards. Component communication is basically a one-way data flow: a parent passes data to a child via property binding, and the child must communicate with the parent via event callbacks if it wants to modify the incoming data. As a third party in the communication scenario, NGRX can uniformly manage the state of components, which reduces the complexity and error possibility of state management among complex front-end application components such as Spartacus.

Sass: Syntactically Awesome Stylesheets abbreviation, is a kind of CSS extension language, on the basis of CSS to add the definition of variables, support code block nested, inheritance, namespace, parent reference and other features, greatly improve the development efficiency of CSS. Sass is credited with Spartacus’s ability to support fine-grained fine-tuning of everything from the overall color style of a page to the appearance of controls.

Jasmine: A front-end unit testing framework. Cypress: An end-to-end automated testing framework.

We ensure the code quality of open source projects like Spartacus through sophisticated unit testing and end-to-end automated testing.

Finally, we developed Spartacus, which was packaged and published as a library on npmjs.com.

Here is a schematic of Spartacus interacting with Commerce. Let’s look at the far right of the picture first. The communication between Spartacus and Commerce system is completed by calling OCC API through HTTP protocol. The Connector is the initiator of the HTTP call and maintains static configuration information, the API’s endpoint.

For example, the product master data is read from the Commerce system, and the list of fields read appears in the API Endpoint as URL parameters. The list of fields can be configured in the Connector’s static configuration point. Connector does not interact with Commerce directly. Instead, it forwards requests to Adapter. The communication is done by Adapter, and the Connector is only responsible for scheduling Adapter. This is the Commerce standard OCC RESTful API, but customers can also implement their own Adapters to connect to backend systems other than Commerce.

The Connector delivers the data retrieved from the Adapter to the NGRX Store structure for unified management. The complexity of the store structure is hidden by the Facade layer, while the Spartacus UI component only interacts with the Facade layer for data binding and page presentation. This demonstrates the design principle of separation of concerns. Finally, due to the differences in the data model between the UI component and the Commerce backend component, it is required to convert the data to a structure suitable for the UI presentation by the Converter before the data is retrieved from Commerce and ready to be displayed in the UI. Conversely, before Spartacus submits data for writing back to Commerce, it must first convert the data to the data format accepted by the OCC API through Converter.

So how can the source code in Spartacus GitHub repository be released to customers?

As mentioned earlier, Spartacus is packaged and published as a library on npmjs.com. This is a screenshot of one of the Spartacus library files that Spartacus Storefront hosted on the NPMJS website. The library version number is 2.1.3, and we’ll cover the versioning mechanism later.

The Spartacus library consists of three main entities: core, storefront, and styles. Storefront includes UI components that make up the appearance of an eStore application visible to the user. Customers can reuse and enhance the components contained in this library. The Core library contains Spartacus’s control logic. Users can develop their own service classes and inject them into the Core framework through Angular dependency injection. Styles include Spartacus’s interface style implementations. Customers can customize these Styles or overwrite standard Styles with custom Styles.

As mentioned in the previous upgradability comparison between Accelerator and Storefront, the customer does secondary development of Storefront based on the Spartacus library files and does not directly modify the source code published by Spartacus. The client’s secondary code is loosely coupled to the Spartacus library files. When customers upgrade the Spartacus version, they will, in the vast majority of cases, not affect their existing redevelopment code. So what do I mean by “the vast majority of the time”? This starts with Spartacus’s versioning mechanism.

Like most popular open source frameworks and libraries, Spartacus uses a so-called semantic version management mechanism, where the version number consists of a major, minor, and revision number separated by a decimal point.

An increase in the major version number used to introduce backwards-incompatible changes or disruptive updates. Changes that are not backward compatible are redevelopment code that was previously written on a lower version after Spartacus was upgraded and that needs to be manually tweaked to continue working. An example of a disruptive update is Spartacus, which supports B2B e-commerce for the first time after it was upgraded to version 3.0.

Subversion number increases: Used to introduce new functionality and allow existing secondary development code to continue to work without any adjustments after a version update. Source code refactorings, performance optimizations, and other changes that are not part of a bug fix are also introduced by increasing the number of minor releases. Revision number: Mainly used to release bug fixes.

Revised versions of Spartacus are released on a weekly basis to ensure that bugs found during use are addressed as early as possible. Subreleases are released on a monthly basis, and the frequency of these updates helps customers quickly make continuous improvements and innovations. For major updates, please refer to the announcement on SAP’s official roadmap website.

From the dependencies defined in package.json in the screenshot above, we can find the core, storefront, and styles libraries mentioned earlier, plus the assets library that mainly contains documentation and translation.

The symbol ^, before version 2.1.0, has a term called hat, which is one of the semantic versioning scope identifiers, indicating that the Storefront redevelopment project supports all Spartacus versions with major version 2 and minor version greater than 1. However, Spartacus with major version number 3 is not supported. In other words, the secondary development project in the figure only supports SAP Commerce B2C functionality, since B2B functionality was introduced in Spartacus 3.0.

Finally, let’s summarize today’s sharing with a few keywords. SAP Spartacus was born in July 2019. It is a modern Storefront application and development framework that meets the responsive and adaptive characteristics. Compared to Accelerator Storefront, Spartacus retains its original customizable features, has a smoother user experience and good upgradability, and is open source without the need to purchase additional licenses. If you’re interested in learning more about Spartacus, you can go to the Open SAP website and take the Spartacus open course.

Thanks for reading.

More of Jerry’s original articles can be found on “Wang Zixi “: