Headless, aber nicht kopflos

Konfigurierbare Produkte mit SAP Commerce und SAP Spartacus

Um der Heterogenität der Vertriebsanforderungen gerecht zu werden, ist SAP Commerce durch modulare Erweiterungspakete entsprechend den individuellen Anforderungen adaptierbar. Die Erweiterung Configurator Complex Products (CCP) ermöglicht die Verwaltung konfigurierbarer, komplexer Produkte und realisiert die Integration mit SAP Variant Configuration and Pricing Services (häufig mit CPS abgekürzt), die für die Umsetzung der Konfigurationslogik verantwortlich sind. Eine geeignete Abstraktion ermöglicht auch die Einbindung nicht SAP-nativer Konfigurationsumgebungen, zum Beispiel historisch gewachsener Legacy-Konfiguratoren.

Neben der funktionalen, logischen Umsetzung der Individualisierbarkeit konfigurierbarer Produkte liefert CCP eine rudimentäre Storefront zur Anzeige und Interaktion der Produkte im Produktkatalog des Commerce-Systems. Durch die durchgängige Abbildung der Produktstrukturen – von Konfigurations-Engine bis Produktkatalog am zentralen Point of Sale (PoS) – wird ein durchgängiges Kundenerlebnis gestaltet und die Automatisierung der unternehmensinternen Produktionsprozesse auf Basis der zentral verwalteten Produktdaten ermöglicht.

SAP Spartacus

SAP Spartacus ist ein unter der Apache License 2.0 lizenziertes Open-Source-Projekt, das primär vom SAP-Commerce-Cloud-Team verwaltet und weiterentwickelt wird. Basierend auf dem Angular-Framework implementiert Spartacus eine Headless UI, die sich als Storefront out of the box mit dem SAP-Commerce-System integriert. Der Begriff Headless bedeutet in diesem Kontext, dass SAP Commerce und SAP Spartacus eigenständige, autarke Applikationen sind, wobei die Verantwortung für die Auslieferung von Inhalten dem SAP-Commerce-System obliegt, während die Spartacus-Storefront Design und Interaktion umsetzt.

Im Gegensatz zu herkömmlichen Storefronts, bei denen es sich meist um Java Server Pages (JSP) handelt, entkoppelt die Single Page Application (SPA) das Frontend vom Backend. Dadurch können Entwicklungszyklen unabhängig voneinander gemanagt und durchgeführt sowie die Codebasis voneinander getrennt werden. Die Kommunikation zwischen den Applikationen geschieht dabei ausschließlich über webbasierte APIs. Im Standard liefert Spartacus alle erwarteten Funktionen eines E-Shops aus, zu denen unter anderem die Homepage, die Produktdetailseite, der Warenkorb und der Check-out zählen. 

Zu Beginn der Entwicklung einer Konfigurator-Storefront steht die Wahl der geeigneten Technologie. Um Transparenz in den Entscheidungsgrundlagen für eine Technologie zur Umsetzung der individuellen Storefront zu schaffen, hilft eine Gegenüberstellung der Entscheidungsalternativen. Klassische Accelerator Storefronts sind in aktuellen Releases von SAP Commerce als veraltet annotiert und sollen im Q2 2024 vollständig aus dem System entfernt werden. SAP begründet die Entscheidung mit den Vorteilen der Entkopplung von Front- und Backend. Durch diese Entscheidung seitens SAP stellt die Neu-Entwicklung einer traditionellen Accelerator Storefront aus heutiger Sicht keine Option mehr dar.

Als verbleibende Alternativen stehen sich die individuelle Entwicklung einer eigenen Storefront von Grund auf sowie die Verwendung der vorgefertigten Funktionalitäten des Spartacus-Frameworks gegenüber. 

Spartacus bietet out of the box eine lauffähige Storefront, deren Individualisierbarkeit auf den Konzepten der Konfigurier- und Anpassbarkeit basiert. Konfigurationen verändern das Verhalten des Spartacus, zum Beispiel die zu verbindende Backend-Adresse, Authentifizierung und Layout. Zugunsten der Anpassbarkeit ist die Codebasis des Spartacus außerdem explizit auf die Wiederverwendung und Anpassung der Codeelemente auf der Grundlage der Dependency-Injection-Konzepte des SPA-Frameworks Angular ausgelegt. Durch die Implementierung des Spartacus-Projekts durch SAP Commerce Cloud profitieren Entwicklungsprojekte auf Basis von Spartacus von der tiefgreifenden fachlichen Expertise im Commerce-Umfeld.

Zusätzlich implementiert Spartacus ein skalierbares Frontend State Management. Die Eigenentwicklung dieser grundlegenden Komponenten in einem Individualprojekt verzögert das Ausrollen der ersten vollständig lauffähigen Storefront und erhöht den Aufwand zur Wartung und Weiterentwicklung merkbar. Klassische Qualitätskriterien der Softwareentwicklung liegen damit außerdem im Verantwortungsbereich des Entwicklungsteams. Auf der anderen Seite ist das Entwicklerteam im Individualprojekt technologisch unabhängig und hat die Obhut über jede Entscheidung und Implementierung der Logik.

Querschnittliche Konzepte

Sowohl das SAP-Commerce-System als auch der SAP Spartacus machen sich das Software-Entwurfsmuster Fassade zunutze. Eine Fassade bildet eine Abstraktionsschicht auf einer oder mehreren Datenquellen zur Aufbereitung der Daten zu einem bestimmten Zweck. Der SAP Commerce implementiert im Backend eine rudimentäre Configuration Facade, um die Konfigurationsdaten zu beziehen, aggregieren und für die Nutzung in einer Konfigurationsstorefront aufzubereiten. Da die rudimentären Funktionalitäten nur in den seltensten Fällen ausreichend für individuelle Konfigurationsanforderungen sind, müssen Entwickler in der Lage sein, diese Fassade um spezifische Funktionalitäten zu erweitern. Technologische Grundlage für die Entwicklung im SAP Commerce ist das Java-Spring-webmvc-Framework. 

Auch der SAP Spartacus nutzt im Frontend das Entwurfsmuster Fassade, um die vom Backend bezogenen Daten für die Nutzung im Web-Frontend aufzubereiten. Um diese Funktionalität zu individualisieren, benötigt es Know-how im Umgang mit der Angular Dependency Injection und den damit inhärenten Injection Tokens. Auf Basis der Injection Tokens können Komponenten ausgetauscht und erweitert werden, damit eine individuelle User Experience geschaffen wird. Als weiteres Konzept nutzen sowohl SAP Commerce als auch der SAP Spartacus den sogenannten OCC, Omnichannel-Commerce. OCC verfolgt das Ziel einer nahtlosen Customer Experience über alle Touchpoints des Kunden mit dem Unternehmen, unabhängig vom genutzten Kommunikationsmedium.

Technisch betrachtet bedeutet OCC im SAP Commerce die Schnittstelle zur Bereitstellung der in der Fassade aufbereiteten Daten auf Basis von Webservices. Der SAP Spartacus greift dieses Konzept auf und bezieht die Daten in seiner OCC-Schicht, bevor er sie an die Fassade weiterleitet. Sowohl Fassaden als auch OCC sind elementare Grundlagen, um eine robuste, skalierbare und wartbare Storefront entwickeln zu können.

SAP Commerce Skillset

Auch die Individualisierbarkeit des SAP-Commerce-Systems basiert auf Konfigurationen und der Erweiterung der vorgefertigten Code-Basis. Zum Zweck der Konfiguration wird das SAP-Commerce-System mit der proprietären ImpEx (Import und Export) Engine ausgeliefert. Durch die tabellenartige Syntax der ImpEx-Scripte lassen sich leicht verständliche, reproduzierbare Modifikationen am Verhalten des SAP Commerce vornehmen. Beispielhaft seien die Destination und Layout Customizings genannt. Sogenannte „Verwendete Destinationen“ (englisch „Consumed Destinations“) ermöglichen die Integration in weitere Back-end-Systeme. Durch die Anwendung eines entsprechenden ImpEx Scripts kann die verwendete Destination auf die kundenspezifische Engine mit spezifischen Authentifizierungs-Informationen umgelenkt werden. Das Layout kann außerdem hinsichtlich der im Frontend anzuzeigenden Container angepasst werden, die eine Storefront daraufhin zum Anzeigen entsprechender Inhalte verwendet.

Zur Aufbereitung der Daten verwendet der SAP Commerce die Konzepte Populator und Mapper in Verbindung mit den Fassaden. Ein Populator ist dafür zuständig, Daten in ein bestehendes Objekt zu überführen. Mehrere Populatoren können dabei hintereinandergeschaltet werden, um eine ganzheitliche Datentransformation abzubilden. Mapper sind innerhalb von Populatoren für die Generierung eines neuen Datenobjekts aus einem anderen Datentyp verantwortlich. Zusammen bilden Populatoren und Mapper die Datentransformation, die den Input für die Fassade liefert.

Die konsequente Nutzung dieser Art der Datentransformation wirkt sich deutlich positiv auf die Qualitätskriterien des geschriebenen Codes aus. Im Zentrum der Spartacus-Storefront steht ihr Konzept zum Datenhandling, bestehend aus der Implementierung des State Management mit NgRx (Redux), der konsequenten Nutzung von Observables sowie der Konzepte Normalisierung und Serialisierung. Die Kombination dieser Bausteine macht die Storefront datenzentriert und reaktiv. Bei NgRx handelt es sich um eine Open-Source-Angular-Implementierung des Redux-Frameworks. Der Zustand der in NgRx gespeicherten Daten wird ausschließlich über Observables kommuniziert, wodurch die UI stets auf Änderungen der Daten reagieren kann. 

Spartacus Skillset 

Normalisierung bezeichnet den Vorgang der Transformation von Daten aus dem Commerce-Backend in der Spartacus-Fassade, um sie für die Anzeige aufzubereiten. Alle eingehenden Daten werden durch dedizierte Normalizer geleitet. Umgekehrt fließen alle durch Nutzerinteraktion modifizierten Daten aus der Spartacus-Fassade in Richtung des Commerce-Backend durch Serializer, die für die Überführung der Daten zurück in das OCC-Modell verantwortlich sind.

Fazit

CCP und SAP Spartacus bieten out of the box eine lauffähige Konfigurationsoberfläche, die sich nahtlos mit vorhandenen SAP-Konfiguratoren integriert. Soll eine individuelle Customer Experience mit beiden Systemen abgebildet werden, kommen Unternehmen allerdings nicht um die Adaption der vorhandenen Logik herum. Dafür bedarf es Expertise im Backend, sprich Java Spring webmvc, genauso wie im Frontend, sprich Angular. Obgleich die Anzeige der Konfiguratoren adaptiv auf die Daten des Backends reagiert, werden Unternehmen mit der Standardimplementierung in beiden Systemen schnell an ihre Grenzen stoßen. Die Entwicklung einer eigenen Storefront von Grund auf ist möglich, birgt dabei aber ganz andere Risiken. Um die zu beherrschen, bedarf es eines tiefgreifenden Know-how des Entwicklerteams in verschiedenen Bereichen des Softwareengineering.