Headless

Configurable products with SAP Commerce and SAP Spartacus

To meet the heterogeneity of sales requirements, SAP Commerce is adaptable to individual needs through modular extension packages. The Configurator Complex Products (CCP) extension enables the management of configurable, complex products and realizes integration with SAP Variant Configuration and Pricing Services (often abbreviated to CPS), which are responsible for implementing the configuration logic. A suitable abstraction also enables the integration of non-SAP native configuration environments, for example historically grown legacy configurators.

In addition to the functional, logical implementation of the individualizability of configurable products, CCP provides a rudimentary storefront for displaying and interacting with the products in the commerce system's product catalog. The consistent mapping of the product structures - from the configuration engine to the product catalog at the central point of sale (PoS) - creates an end-to-end customer experience and enables the automation of the company's internal production processes based on the centrally managed product data.

SAP Spartacus

SAP Spartacus is an open source project licensed under the Apache License 2.0, primarily managed and developed by the SAP Commerce Cloud team. Based on the Angular framework, Spartacus implements a headless UI that integrates with the SAP Commerce system as a storefront out of the box. The term headless in this context means that SAP Commerce and SAP Spartacus are independent, standalone applications, with the SAP Commerce system responsible for content delivery, while the Spartacus storefront implements design and interaction.

Unlike conventional storefronts, which are usually Java Server Pages (JSP), the Single Page Application (SPA) decouples the front end from the back end. This means that development cycles can be managed and executed independently of each other and the code base can be separated from each other. Communication between the applications takes place exclusively via web-based APIs. In the standard version, Spartacus delivers all the expected functions of an e-shop, including the homepage, the product detail page, the shopping cart and the checkout. 

The development of a configurator storefront begins with the selection of the appropriate technology. A comparison of the decision alternatives helps to create transparency in the basis for deciding on a technology for implementing the individual storefront. Classic accelerator storefronts are annotated as obsolete in current releases of SAP Commerce and are to be completely removed from the system in Q2 2024. SAP justifies the decision with the advantages of decoupling front-end and back-end. As a result of this decision on the part of SAP, the new development of a traditional accelerator storefront is no longer an option from today's perspective.

The remaining alternatives are the individual development of an own storefront from scratch and the use of the prefabricated functionalities of the Spartacus framework. 

Out of the box, Spartacus provides a runnable storefront whose customizability is based on the concepts of configurability and customizability. Configurations change the behavior of Spartacus, for example the backend address to be connected, authentication and layout. In favor of customizability, the Spartacus codebase is also explicitly designed to reuse and customize code elements based on the dependency injection concepts of the Angular SPA framework. By implementing the Spartacus project through SAP Commerce Cloud, development projects based on Spartacus benefit from the deep domain expertise in the commerce environment.

In addition, Spartacus implements a scalable frontend state management. The in-house development of these basic components in an individual project delays the roll-out of the first fully executable storefront and noticeably increases the effort for maintenance and further development. Classic quality criteria of software development are thus also the responsibility of the development team. On the other hand, the development team in the individual project is technologically independent and has custody over every decision and implementation of the logic.

Cross-sectional concepts

Both the SAP Commerce system and SAP Spartacus make use of the software design pattern facade. A facade forms an abstraction layer on top of one or more data sources to prepare data for a specific purpose. SAP Commerce implements a rudimentary Configuration Facade in the backend to obtain, aggregate, and prepare configuration data for use in a configuration storefront. Since the rudimentary functionality is rarely sufficient for individual configuration requirements, developers must be able to extend this facade with specific functionality. The technological basis for development in SAP Commerce is the Java Spring webmvc framework. 

SAP Spartacus also uses the design pattern Facade in the frontend to prepare data obtained from the backend for use in the web frontend. To customize this functionality, it requires know-how in dealing with Angular Dependency Injection and the inherent Injection Tokens. Based on the injection tokens, components can be exchanged and extended to create an individual user experience. As a further concept, both SAP Commerce and SAP Spartacus use the so-called OCC, Omnichannel Commerce. OCC pursues the goal of a seamless customer experience across all customer touchpoints with the company, regardless of the communication medium used.

From a technical point of view, OCC in SAP Commerce means the interface for providing the data prepared in the facade on the basis of web services. SAP Spartacus takes up this concept and obtains the data in its OCC layer before forwarding it to the facade. Both facades and OCC are elementary foundations for being able to develop a robust, scalable and maintainable storefront.

SAP Commerce Skillset

The customizability of the SAP Commerce system is also based on configurations and the extension of the prefabricated code base. For the purpose of configuration, the SAP commerce system comes with the proprietary ImpEx (import and export) engine. The table-like syntax of the ImpEx scripts allows easy-to-understand, reproducible modifications to the behavior of SAP Commerce. Examples include destination and layout customizations. So-called "Consumed Destinations" enable the integration into further back-end systems. By applying an appropriate ImpEx script, the consumed destination can be redirected to the custom engine with specific authentication information. The layout can also be customized with respect to the containers to be displayed in the frontend, which a storefront then uses to display appropriate content.

To prepare the data, SAP Commerce uses the concepts Populator and Mapper in connection with the facades. A populator is responsible for transferring data into an existing object. Several populators can be connected in series to map a holistic data transformation. Mappers are responsible within Populatoren for the generation of a new data object from another data type. Together, populators and mappers form the data transformation that provides the input for the facade.

The consistent use of this type of data transformation has a clearly positive effect on the quality criteria of the written code. At the heart of the Spartacus storefront is its data handling concept, consisting of the implementation of state management with NgRx (Redux), the consistent use of observables, and the concepts of normalization and serialization. The combination of these building blocks makes the storefront data-centric and reactive. NgRx is an open source Angular implementation of the Redux framework. The state of the data stored in NgRx is communicated exclusively through observables, which allows the UI to always react to changes in the data. 

Spartacus Skillset 

Normalization refers to the process of transforming data from the commerce backend in the Spartacus facade to prepare it for display. All incoming data is passed through dedicated normalizers. Conversely, all data modified by user interaction flows from the Spartacus facade toward the commerce backend through serializers responsible for transforming the data back into the OCC model.

Conclusion

CCP and SAP Spartacus offer an executable configuration interface out of the box that integrates seamlessly with existing SAP configurators. However, if an individual customer experience is to be mapped with both systems, companies cannot avoid adapting the existing logic. This requires expertise in the back end, i.e. Java Spring webmvc, as well as in the front end, i.e. Angular. Although the display of the configurators reacts adaptively to the data of the backend, companies will quickly reach their limits with the standard implementation in both systems. Developing your own storefront from the ground up is possible, but it involves a whole different set of risks. To manage these, the development team needs in-depth expertise in various areas of software engineering.