24.09.2020 | Reinhard Klein | Spartacus | Commerce

SAP Spartacus Storefront

SAP Spartacus Storefront

Wer schnell auf Marktanforderungen reagieren möchte, dem stehen mit seiner Commerce-Plattform möglicherweise lange Release-Zyklen im Weg. Dies ist oft durch eine zentralistische Architektur begründet, die einen Rattenschwanz mit sich zieht.

Damit eine monolithisch aufgebaute Commerce-Suite stabil funktioniert, bedarf es einem Build und Deployment des Gesamtsystems. Zudem müssen Testpläne durchgeführt und Freigaben erteilt werden. Dies wird dann zu einem Problem, wenn noch so kleine Änderungen schnell live gestellt werden sollen. Immerzu muss der gesamte Release-Zyklus durchlaufen werden um die Integrität nicht zu gefährden oder man begibt sich in riskante Workarounds.

Der Weg von SAP

Wer SAP Commerce schon länger beobachtet, weiß dass das Produkt initial eher monolithisch aufgebaut war. Seit geraumer Zeit beschreitet die SAP jedoch den Pfad der Modernisierung der Commerce-Plattform zu einer modularen Cloud-Lösung mit dynamischer Skalierung, API-Kontrakten und kontinuierlichen Deployments. Das Hauptziel: Agilität/Flexibilität für Kunden zu ermöglichen.

Wir haben im Artikel Kyma bereits den Weg der SAP in Richtung entkoppelte Features als Microservices/Serverless Functions betrachtet. Jetzt möchten wir auf das Thema entkoppeltes Frontend eingehen. SAP hat auch hierfür eine Lösung.

Spartacus Storefront

Spartacus ist die 2018 ins Leben gerufene Storefront für SAP Commerce (Cloud). Sie ist komplett als Open-Source-Lösung verfügbar und verfolgt den Ansatz in einer Progressive-Web-App auf Basis Angular zu fungieren. Basierten die SAP Commerce Acceleratoren auf JSP und Spring MVC, so wird nun mit JavaScript / TypeScript entwickelt. Dies findet großen Anklang in der Frontend Entwickler-Community, die sich lange nach einer auf JavaScript basierten Storefront gesehnt hat. Besonders hervorzuheben ist der Aspekt der losen Kopplung. Spartacus kommuniziert ausschließlich über die SAP Commerce OCC-API und kann damit unabhängig von der SAP Commerce Plattform betrieben und aktualisiert werden. Die SAP Commerce Plattform fungiert hierbei als “Headless Commerce-API”.

Historische Storefronts

Über die Jahre haben wir miterlebt, dass es zwei Arten von Unternehmen, die SAP Commerce einsetzen, gibt. Die einen setzen auf Acceleratoren, wiederum andere präferieren Eigenentwicklungen. Dies ist zum einen darin begründet, dass der Accelerator-Ansatz nicht durchgängig allen Anforderungen gerecht wird, zum anderen neue Technologien aus dem Boden sprießen und Entwickler unterschiedliche Präferenzen haben.

Historisch war der Ansatz mit JSP/Spring MVC eine eigene Storefront umzusetzen am weitesten verbreitet. Dies lag zum einen darin begründet, dass die Technologien JSP/Spring MVC bei einer Java-Plattform für das Frontend auf der Hand liegen und zum anderen die Acceleratoren auch anfangs nur grundlegende Commerce-Anforderungen abgedeckt hatten.

Unternehmen, die sich komplett von der JSP-Welt trennen wollten, haben Ansätze auf Basis Google-Web-Toolkit, Ruby on Rails und Vue.js verfolgt.

Fest steht, alle Ansätze waren für die Prä-Spartacus-Zeit sicherlich richtig, heutzutage würde man jedoch Spartacus mindestens in Erwägung ziehen.

Spartacus als strategische Storefront von SAP

Stand heute gilt: Spartacus ist die strategische Storefront für SAP Commerce (Cloud). Die Weiterentwicklung der Acceleratoren wurde eingestellt und ein klarer Fokus auf Open Source wurde gesetzt. Viele Unternehmen sehen ein neues Produkt erst einmal als Risiko, da es noch nicht markterprobt und meist noch nicht Feature-Complete ist.

Wir betrachten zuerst, wann es weniger sinnvoll ist, Spartacus einzusetzen.

Welche Gründe sprechen gegen Spartacus?

Es gibt Unternehmen, die bereits eine Storefront-Technologie (Accelerator oder andere) im Einsatz haben und diesen Weg weiter gehen möchten. In diesem Fall wird man sich wohl im ersten Schritt gegen Spartacus entscheiden. Insbesondere, wenn man schon einen hauseigenen Storefront-Core aufgebaut hat. Möchte man mit einem Spezial-Sortiment technologisch ausbrechen, so könnte Spartacus dafür natürlich trotzdem in Frage kommen. Eine Betrachtung der Anforderungen kann dies beantworten.

Es gibt noch weitere Szenarien, wann man sich vermutlich gegen den Einsatz von Spartacus entscheiden würde:

  • Passen die Features von Spartacus nicht zu den Projektanforderungen, so gibt es andere Lösungen. Beispiele hierfür sind Branchenanforderungen, die mit einem Branchen-Accelerator besser gelöst werden könnten oder B2B Funktionalitäten, die erst vollumfänglich 2021 laut Spartacus Roadmap angeboten werden. Bei letzterem könnte man sich noch für den B2B Accelerator entscheiden.
  • Sind inhouse andere Frontend-Technologien als Angular präferiert wie bspw. Ruby, dann wird man sich weniger dafür aussprechen.
  • Ist SAP Commerce (Cloud) nicht das führende System für die Storefront, sondern lediglich als Commerce-API in einem Portal oder in einem CMS-gesteuerten Webauftritt eingesetzt, dann wird eine standalone Lösung wie Spartacus weniger interessant sein. Insbesondere wenn das SAP Commerce WCMS/SmartEdit nicht benutzt wird, kommen viele Spartacus-Features nicht zum tragen.

Fallen die oben genannten Punkte nicht so stark ins Gewicht, ist es interessant, Spartacus genauer unter die Lupe zu nehmen.

Welche Gründe sprechen für Spartacus?

  • Entkoppelte Architektur: Storefront Änderungen können ohne einen Komplett-Build live gestellt werden.
  • Progressive-Web-App: Die Vorteile einer PWA können genutzt werden.
  • Open Source: Durch eine von SAP unterstützte und geleitete Community werden neue Funktionalitäten kostenfrei auf Spartacus GitHub zur Verfügung gestellt.
  • Updatefähigkeit: Durch die Einbindung von Spartacus als Angular Bibliothek bleibt die Storefront updatefähig.
  • Erweiterbarkeit: Spartacus kann durch eigene Angular Komponenten und Services erweitert werden ohne die Updatefähigkeit zu gefährden.
  • WCMS-Driven: Spartacus nutzt das SAP Commerce WCMS/SmartEdit nativ.
  • Server-Side-Rendering: SSR kann bei Bedarf aus Performance- und SEO-Gründen aktiviert werden.
  • Support durch SAP Commerce Cloud Automation: Spartacus kann nativ in der SAP Commerce Cloud deployt werden.

Fazit

Wir sehen Spartacus als den richtigen Schritt von SAP. Mit Angular kommt eine moderne, gut strukturierte und markterprobte Frontend-Technologie für internationale Commerce Auftritte zum Einsatz. Das Feedback der Frontend-Community wurde angenommen. SAP möchte sich künftig noch weiteren Frontend-Technologien wie React öffnen und diese mit Spartacus verheiraten.

Entgegen der ursprünglichen Intention eine herstellerunabhängige Commerce Storefront anzubieten, ist Spartacus nun speziell für den Einsatz mit SAP Commerce (Cloud) konzipiert. Man erkennt dies an der recht engen Kopplung mit dem SAP Commerce WCMS/SmartEdit. Dieser Aspekt hat jedoch wiederum den Vorteil, dass nicht alle Eventualitäten jeglicher Commerce-APIs von der Open-Source Community umgesetzt werden müssen und man schneller mit SAP Commerce (Cloud) Feature-Complete wird.

Auch die ergänzende Nutzung von Headless Content in Spartacus ist durch die Erweiterbarkeit kein Problem. Für das Grundgerüst der Seiten werden die SAP Commerce Content-Elemente benutzt. Für die Anreicherung von Seiten mit Zusatzinhalten kann jede andere Headless Content-API angesprochen werden. Hier existieren bereits Lösungsansätze auf dem Markt wie bspw. Spartacus in Zusammenspiel mit CoreMedia.

Wir können Sie unterstützen.