Sana Commerce Frontend für SAP/Dynamics: Storefront ohne Custom-React-Build

Sana Commerce löst ein Problem, an dem viele SAP- und Dynamics-Projekte jahrelang scheitern: den Bruch zwischen ERP-Daten und Storefront. Preise, Lagerbestand, Kundenkonditionen und Bestellhistorie kommen direkt aus SAP S/4HANA oder Microsoft Dynamics 365, ohne Zwischenschicht, ohne separate Datenbank, ohne Synchronisationsverzug. Das ist der Kern des Sana-Versprechens, und daran ändert dieser Artikel nichts. Die Frage, die wir hier stellen, betrifft ausschließlich die Ebene darüber: das Frontend, mit dem Kundinnen und Kunden diese Daten tatsächlich sehen.

Warum Teams bei Sana Commerce einen eigenen React-Frontend bauen

Sana liefert Storefront-Templates und REST-APIs, über die sich die Oberfläche erweitern lässt. Für Teams mit hohem Design-Anspruch oder ungewöhnlichen B2B-Anforderungen, individuelle Konfiguratoren, spezielle Freigabe-Workflows, eigene Preislogik-Darstellung, reicht die Template-Ebene oft nicht aus. Die naheliegende Lösung: ein komplett eigener React-Frontend, der direkt gegen die Sana-API spricht und volle Gestaltungsfreiheit erlaubt. Technisch ist das machbar, die APIs sind dafür gebaut, und der erste Release läuft meist beeindruckend gut.

Der Haken: Update-Kompatibilität zum Sana-Release-Zyklus

Der Punkt, der in der Projektplanung selten genug Raum bekommt: Sana Commerce Cloud entwickelt sich kontinuierlich weiter, neue API-Versionen, veränderte Checkout-Flows, neue Plattform-Features, alles nach Sanas eigenem Release-Takt. Ein custom gebauter React-Frontend sitzt außerhalb dieses Zyklus. Er bekommt nichts automatisch, jede Sana-Änderung muss manuell nachgezogen werden, sonst driftet die eigene Storefront-Logik von der offiziellen API-Struktur weg.

In der Praxis bedeutet das:

• API-Versionssprünge von Sana lösen Breaking-Change-Reviews im eigenen React-Code aus
• Neue Checkout- oder Freigabe-Features aus der Sana-Roadmap müssen händisch nachgebaut werden, statt automatisch verfügbar zu sein
• Jede neue Kampagnen- oder Produktwelt-Seite braucht einen Entwickler-Sprint, kein Marketing-Self-Service
• React-, Node- und Dependency-Updates landen im eigenen Backlog, nicht bei Sana
• Mit jedem Monat ohne Nachpflege wächst der Abstand zwischen custom Frontend und Sanas aktuellem API-Stand

Das ist kein Sana-spezifisches Problem, es betrifft jeden Custom-Build auf einer ERP-integrierten Commerce-Plattform mit eigenem Release-Rhythmus. Es lohnt sich trotzdem, diesen Wartungsaufwand von Anfang an ehrlich einzupreisen.

Was am ERP-Layer unverändert bleibt

Wichtig für die Einordnung: Sana bleibt in diesem Bild die Quelle der Wahrheit für Preise, Bestand, Kundenkonditionen und Bestelldaten, direkt aus SAP S/4HANA oder Dynamics 365 gelesen. An dieser Anbindung ändert sich nichts, unabhängig davon, welches Frontend am Ende die Daten anzeigt. Das Update-Kompatibilitätsproblem entsteht ausschließlich auf der Präsentationsebene, dort, wo die React-Komponenten sitzen, nicht in der Datenintegration zwischen Sana und dem ERP.

Laioutr als Managed-Antwort: FMP-Layer über die Sana-API

Laioutr setzt genau an dieser Präsentationsebene an, ohne die Sana-ERP-Anbindung zu berühren. Unser Composable Headless Frontend verbindet sich über den Orchestr-Datenlayer mit der Sana-API und bildet Produkt-, Preis-, Bestands- und Kundendaten auf unser einheitliches Component-Schema ab, dieselben Datenpunkte, die auch der custom Frontend abfragen würde, nur zentral gepflegt statt im eigenen Repository. Weil die Anbindung als Plattform-Bestandteil betrieben wird, zieht Laioutr Sana-API-Änderungen zentral nach, statt dass jedes einzelne Kundenprojekt sie separat nachbauen muss.

Das Ergebnis ist ein Frontend as a Service: Framework-Updates, Sicherheits-Patches, CI/CD und die laufende Anpassung an Sanas Release-Zyklus sind Plattform-Aufgabe, keine Sprint-Aufgabe im eigenen Team. Entwicklerinnen und Entwickler behalten vollen Zugriff auf die Komponenten-Ebene für individuelle B2B-Logik, nur ohne die dauerhafte Kompatibilitätspflege im Nacken.

Wie die technische Anbindung aussieht

Der Orchestr-Layer spricht die Sana-Commerce-API an, holt Produktdaten, kundenspezifische Preise, Verfügbarkeiten und Bestellstatus und normalisiert sie auf unser Component-Schema. PDP-, PLP- und Checkout-Components im Frontend erwarten dieselbe Datenstruktur, unabhängig davon, ob dahinter Sana, SAP Commerce Cloud oder ein anderes ERP-integriertes Backend steht. Für B2B-spezifische Sana-Felder, individuelle Preisstaffeln, Freigabe-Workflows, Kundengruppen-Kataloge, bindet ein Entwicklerteam einmalig einen Custom-Resolver im Orchestr-Layer an, statt sie in einem eigenen React-Fork nachzubauen.

Wer macht was: Entwicklung und Marketing

Entwicklerteams definieren Components und erweitern die Bibliothek um sana-spezifische Datenpunkte, B2B-Preislogik, Kundengruppen, Freigabeprozesse. Marketing arbeitet parallel im Studio-Editor, komponiert Produktwelten, tauscht Kampagnen-Seiten aus, ohne Pull-Request und ohne auf ein Deployment-Fenster zu warten. Bei einem komplett eigenen React-Build fehlt diese Trennung, jede Änderung läuft über Code, egal ob sie inhaltlich oder strukturell ist.

Entscheidungsraster: Custom-Build, Sana-Templates oder Managed FMP

Drei Situationen, drei sinnvolle Antworten. Ihr habt ein großes, dauerhaft besetztes Frontend-Team und wollt volle Kontrolle über jede Komponente, ohne Plattform-Layer dazwischen: Der custom React-Build bleibt eine gültige Option, mit der Update-Pflege als bewusst eingegangenem Trade-off. Die Sana-Standardtemplates reichen euch aus, und Design-Individualität ist zweitrangig: Dann bleibt die Template-Ebene die schnellste Lösung. Ihr wollt individuelle B2B-Frontend-Logik, aber ohne dauerhafte Kompatibilitätsarbeit gegen Sanas Release-Zyklus: Dann ist ein Managed-Frontend-Layer wie Laioutr über der Sana-API der direkte Weg. Mehr zur Anbindung im Detail auf unserer Sana-Commerce-Seite.

Ein verwandtes Muster zeigt sich auch bei anderen ERP-integrierten Plattformen, etwa in SAP Commerce Cloud OCC API und Laioutr: Wie sich das Frontend anbindet, wo dieselbe Trennung zwischen ERP-Anbindung und Frontend-Betrieb sichtbar wird. Wer allgemein über die Kosten eines Custom-Frontends nachdenkt, findet eine breitere Einordnung in Die versteckten Kosten von Custom-Frontends in der Enterprise-Ecommerce.

Fazit

Sana Commerce löst das ERP-Frontend-Problem auf der Datenseite, zuverlässig und ohne Zwischenschicht. Wer darüber einen komplett eigenen React-Frontend baut, übernimmt automatisch die Pflicht, diesen Frontend dauerhaft mit Sanas Release-Zyklus synchron zu halten. Laioutr übernimmt genau diese Pflicht als Plattform-Aufgabe: SAP- oder Dynamics-Anbindung über Sana bleibt unangetastet, der Frontend-Layer läuft als Frontend Management Platform, gepflegt, aktuell, jederzeit erweiterbar. Der erste Schritt ist meist ein technischer Discovery-Call, in dem wir klären, welche Sana-Datenpunkte euer Storefront heute konkret braucht.