SAP Composable Storefront: Architektur, Vor- und Nachteile und wann Sie ihn brauchen

Der SAP Composable Storefront (früher Spartacus) ist das Angular-Frontend von SAP für Commerce Cloud und die Empfehlung von SAP für neue Projekte. Eine gute Standardwahl, aber keine automatische: Er verlangt Angular-Know-how, verändert die Arbeitsweise Ihres Teams und bringt eine zusätzliche Schicht für serverseitiges Rendering mit, die betrieben werden will. Für viele Unternehmen lohnt sich das; für manche passt ein eigenes Headless-Frontend oder ein anderer Weg besser.

Dieser Leitfaden erklärt, was der Storefront ist, wie die Architektur funktioniert, was ein Projekt vor dem Start braucht, welche Vor- und Nachteile es wirklich gibt und wie Sie entscheiden.

Kurzfassung: Der Composable Storefront ist eine Angular-Anwendung, die mit SAP Commerce Cloud ausschliesslich über die OCC-REST-APIs spricht, mit serverseitigem Rendering, CMS-gesteuerten Seiten aus SmartEdit sowie B2B- und B2C-Komponenten. Er ist in der Commerce-Cloud-Lizenz enthalten. Wählen Sie ihn, wenn Sie die Komponenten und den Upgrade-Pfad von SAP wollen und Angular-Kompetenz haben oder aufbauen; wählen Sie ein eigenes React- oder Next.js-Frontend, wenn Designfreiheit oder ein bestehender Frontend-Stack wichtiger sind. Der alte JSP-basierte Accelerator ist abgekündigt und soll im September 2027 entfernt werden.

Was ist der SAP Composable Storefront?

Der Composable Storefront ist das Headless-Frontend für SAP Commerce Cloud. Viele Entwickler nennen ihn noch Spartacus, nach dem Open-Source-Projekt, aus dem er stammt. Seit Release 5.0 liefert SAP die offiziellen Bibliotheken als «SAP Commerce Cloud, composable storefront» aus, und seit Version 2211.19 folgen die Versionsnummern denen von Commerce Cloud (SAP Help: About Composable Storefront).

Was ihn ausmacht:

• Angular, mit NgRx für das State Management. SAP hebt den Storefront einmal pro Jahr, im Februar, auf eine neue Angular-Hauptversion.
• Headless: Die Kommunikation mit Commerce Cloud läuft ausschliesslich über die OCC-REST-APIs.
• CMS-gesteuert: Seitenlayouts kommen aus SmartEdit statt aus fest programmierten Templates.
• Serverseitiges Rendering (SSR) für Suchmaschinen und schnelle erste Ladezeiten, dazu Funktionen einer Progressive Web App.
• Lizenz: in der Commerce-Cloud-Lizenz enthalten. Cloud-Kunden installieren die Bibliotheken aus dem Repository von SAP; der Quellcode bleibt offen auf GitHub.

Er ersetzt den Accelerator-Storefront, also die JSP-Templates, die auf den Applikationsservern von Commerce Cloud gerendert werden und eng mit dem Backend verbunden sind. SAP hat die Accelerator-UI-Templates abgekündigt und ihre Entfernung sowie das Ende der Mainstream-Wartung für September 2027 geplant, mit einer erweiterten Übergangsfrist bis September 2028 (SAP Help: Deprecation of Accelerator UIs).

Wie funktioniert die Architektur?

Drei Schichten mit klarer Arbeitsteilung:

1. Commerce-Cloud-Backend: Warenkorb, Checkout, Preise, Aufträge, Produktverwaltung und Suche, alles über APIs bereitgestellt. (Die Schichten des Backends selbst beschreibt unser Überblick zu SAP Commerce Cloud.)
2. OCC-API-Schicht: die REST-Endpunkte, die der Storefront für Produktsuche, Warenkorb, Checkout und Kontoverwaltung aufruft. Der Storefront greift nie direkt auf die Datenbank zu.
3. Composable Storefront: die Angular-Anwendung im Browser oder, für SSR, auf einem Node.js-Server. Sie rendert die Oberfläche, hält den Zustand im Client und ruft die OCC-APIs auf.

Diese Trennung erlaubt es, das Frontend unabhängig vom Backend zu releasen, mehrere Frontends (Web, App, Kiosk) aus einem Backend zu bedienen und das Frontend bei Bedarf ganz auszutauschen.

So funktioniert die CMS-Integration

1. Content-Verantwortliche legen in SmartEdit Seiten mit Content Slots an (Kopfbereich, Inhalt, Fussbereich, Seitenleiste).
2. Jeder Slot enthält CMS-Komponenten: Banner, Produktkarussells, Textblöcke, Navigation.
3. Der Storefront lädt die Seitenstruktur über die CMS-API.
4. Jeder CMS-Komponententyp ist einer Angular-Komponente zugeordnet, die ihn rendert.
5. Änderungen in SmartEdit erscheinen ohne Deployment im Storefront.

Genau das macht den Storefront in der Praxis «composable»: Seiten werden aus Komponenten zusammengesetzt, die das Marketing selbst steuert.

Funktionen, die in Projekten zählen

• SSR: Der Server rendert die erste Seite, danach übernimmt der Browser. Crawler erhalten vollständiges HTML, Nutzer einen schnellen ersten Seitenaufbau.
• Lazy Loading: Module werden bei Bedarf geladen, die Produktliste zieht also nicht den Checkout-Code mit.
• Internationalisierung: Übersetzungsdateien je Sprache, Sprachwechsel über URL oder Benutzereinstellung.
• Erweiterbarkeit: Sie ersetzen SAP-Komponenten über Angular Dependency Injection durch eigene, statt den SAP-Quellcode zu ändern. Das wirkt zunächst einschränkend und ist genau das, was Upgrades beherrschbar hält.

Was braucht ein Projekt vor dem Start?

Technische Voraussetzungen

• Eine Commerce-Cloud-Umgebung mit aktivierten OCC-Endpunkten für Produkte, Warenkorb, Checkout, CMS und Benutzer.
• Node.js- und Angular-CLI-Versionen, die zu Ihrem Storefront-Release passen (SAP dokumentiert die Kompatibilität; prüfen Sie sie, bevor Sie Code schreiben).
• Zugang zum Repository von SAP für die Storefront-Bibliotheken.

Voraussetzungen im Team

• Erfahrung mit Angular, TypeScript und RxJS. Das ist nicht verhandelbar: Teams mit React-Erfahrung, die Angular für ähnlich genug hielten, haben allein bei RxJS und Dependency Injection Wochen verloren.
• Verständnis der OCC-Authentifizierung (OAuth 2.0).
• Zugang zu Backoffice und SmartEdit für die CMS-Konfiguration.

Einrichtung in fünf Schritten: Anwendung mit den Schematics von SAP aufsetzen; Backend-URL, Base Site, Sprache und Währung konfigurieren; CMS-Komponententypen Angular-Komponenten zuordnen (die Standardzuordnungen liefert SAP, eigene Komponenten brauchen eigene); SSR einrichten; danach gestalten und erweitern. In der SAP Community gibt es eine Schritt-für-Schritt-Anleitung zur Installation der aktuellen 2211-Releases.

Die häufigsten Fehler

• Versionskonflikte zwischen Storefront-Bibliotheken und Backend. Prüfen Sie zuerst die Kompatibilität; sonst kann ein ganzer Sprint verloren gehen.
• SSR zu spät. SSR beeinflusst Performance, Vorschauen in sozialen Medien und Ladeverhalten. Richten Sie es von Anfang an ein; nachträglich ist es mühsam.
• Fest programmierte Inhalte statt CMS-Komponenten, was für einfache Inhaltsänderungen Deployments erzwingt.
• Alles wird sofort geladen. Prüfen Sie, welche Module vorab geladen werden; auf Mobilgeräten summiert sich das.
• Desktop zuerst. Testen Sie eigene Komponenten von Beginn an auf Mobilgeräten.

Halten Sie eigenen Code in Feature-Modulen, Komponenten-Overrides per Dependency Injection, gemeinsamen Modulen und Style-Overrides über CSS Custom Properties. SAP aktualisiert den Storefront regelmässig, und Code, der mit dem von SAP verflochten ist, macht jedes Upgrade zum Projekt.

Was sind die echten Vorteile?

Unabhängige Releases. Ein Aktionsbanner, eine Änderung im Checkout oder eine Rendering-Korrektur geht ohne vollständiges Plattform-Release live; das Frontend bekommt seinen eigenen Release-Rhythmus, während das Backend stabil bleibt.

Flexibilität im Frontend. Weil der Storefront nur über APIs mit Commerce Cloud spricht, lassen sich Komponenten von anderswo einbinden: Produktkonfiguratoren, 3D-Ansichten, Chat.

SEO. Mit SSR sind Produkt- und Kategorieseiten indexierbar, ohne auf clientseitiges JavaScript angewiesen zu sein.

Selbstständigkeit bei Inhalten. Das Marketing verwaltet Seitenlayouts in SmartEdit, ohne Tickets für die Entwicklung.

Roadmap von SAP. Die Storefront-Entwicklung von SAP fliesst in den Composable Storefront, während die Accelerator-Templates auslaufen.

Was sind die echten Nachteile?

Abhängigkeit von Angular. Ihr Frontend-Team braucht Angular, TypeScript und RxJS. Die meisten SAP-Commerce-Teams sind Java-lastig, planen Sie also Rekrutierung oder Schulung ein. Ein Java-Entwickler braucht meist mehrere Monate, bis er mit dem Storefront voll produktiv ist; das Komponentenmodell und die reaktiven Muster von Angular haben mit JSP-Entwicklung wenig gemein.

Höherer Anfangsaufwand. SSR, Build-Pipeline, Deployment und CMS-Mapping kosten mehr Arbeit als der Start mit Accelerator-Templates. Planen Sie einige Wochen zusätzlich ein.

Eine zusätzliche Laufzeitumgebung. Der SSR-Server muss zusätzlich deployt, überwacht und unter Last stabil gehalten werden.

Mehr Code für kleine Änderungen. Angular-Komponenten zu überschreiben und mit NgRx zu arbeiten, braucht mehr Code als die Anpassung eines JSP-Templates.

Komponenten sind ein Ausgangspunkt. Die Komponenten von SAP decken die Standardabläufe ab, passen aber selten unverändert zu Ihrer Marke. Für ein eigenständiges Design werden Sie einen grossen Teil davon überschreiben.

Wie entscheiden Sie?

Kriterium	Composable Storefront	Eigenes Headless-Frontend (React, Next.js)	Accelerator
Framework	Angular	Frei wählbar	JSP (Altbestand)
Zeit bis zum Standard-Storefront	Vier bis acht Wochen	Länger: Checkout, Konto und CMS-Rendering selbst gebaut	Nur bestehende Installationen
CMS	SmartEdit, integriert	SmartEdit-Inhalte oder externes CMS selbst anbinden	SmartEdit
Support von SAP	Storefront und APIs	Nur APIs	Abgekündigt, Entfernung für September 2027 geplant
Designfreiheit	Mittel	Voll	Begrenzt

Wählen Sie den Composable Storefront, wenn Sie neu starten, Angular-Entwickler haben oder diese Kompetenz aufbauen wollen, SmartEdit ohne Zusatzaufwand nutzen möchten und Wert auf den Upgrade-Pfad von SAP legen.

Wählen Sie ein eigenes Headless-Frontend, wenn Ihr Team in React oder Next.js stark ist, Ihre Marke ein vollständig eigenes Design braucht oder Sie sich bereits für ein externes CMS entschieden haben. Unser ausführlicher Vergleich von Composable Storefront und React/Next.js geht diese Abwägung im Detail durch. Bei Distrelec hat die Entkopplung des Frontends von SAP Commerce über eine saubere API-Schicht die Time-to-Market um 70 % verkürzt.

Bleiben Sie beim Accelerator nur als Übergang, und planen Sie den Wechsel jetzt. Unser Leitfaden zur Migration vom Accelerator auf den Composable Storefront beschreibt ein schrittweises Vorgehen. Ist die Storefront-Entscheidung Teil eines grösseren Plattformwechsels, lesen Sie, was in einer Commerce-Cloud-Implementierung wirklich passiert, oder sprechen Sie mit unserem SAP-Commerce-Cloud-Team.

Häufige Fragen

Was ist der Unterschied zwischen Spartacus und dem SAP Composable Storefront?

Es ist dasselbe Produkt unter neuem Namen. Seit Release 5.0 veröffentlicht SAP die offiziellen Spartacus-Bibliotheken als «SAP Commerce Cloud, composable storefront». Die Architektur ist dieselbe, und seit Version 2211.19 folgen die Versionsnummern denen von SAP Commerce Cloud.

Kostet der Composable Storefront extra?

Nein. Er ist ohne Zusatzkosten in der Lizenz von SAP Commerce Cloud enthalten. Cloud-Kunden beziehen die Bibliotheken über das Repository von SAP; der Quellcode bleibt als Open Source auf GitHub verfügbar. Kosten verursacht das Frontend-Team, das Ihren Storefront baut und pflegt.

Kann ich React oder Next.js statt Angular verwenden?

Ja. Die OCC-REST-APIs sind technologieneutral, Sie können also ein eigenes Headless-Frontend mit React, Vue oder Next.js bauen. Sie verzichten dabei auf die vorgefertigten Storefront-Komponenten von SAP, das fertige CMS-Rendering und den Upgrade-Pfad von SAP und gewinnen volle Freiheit bei Design und Technologie.

Können Accelerator und Composable Storefront parallel laufen?

Ja. Während einer Migration können beide Storefronts gegen dasselbe Commerce-Cloud-Backend laufen, der Verkehr wird über URL oder Domain gesteuert. Planen Sie die Umstellung: SAP hat die Accelerator-UI-Templates abgekündigt und ihre Entfernung für September 2027 vorgesehen.

Wie lange dauert der Aufbau eines Composable Storefront?

Ein Basis-Storefront läuft nach wenigen Tagen. Ein produktionsreifer Standard-B2C-Storefront aus SAP-Komponenten braucht typischerweise vier bis acht Wochen, mit umfangreichen Anpassungen acht bis zwölf Wochen, und B2B-Funktionen kosten zwei bis vier Wochen zusätzlich. Diese Werte setzen ein Team voraus, das Angular bereits beherrscht.

Unterstützt der Composable Storefront B2B-Commerce?

Ja. Die B2B-Funktionen umfassen Organisations- und Budgetverwaltung, Freigabeprozesse, Checkout mit Bestellnummer, Schnellerfassung und gespeicherte Warenkörbe. B2B- und B2C-Module können in einem Build liegen oder in getrennten Builds, wenn sich die Erlebnisse stark unterscheiden.