B2B-Webshop auf SAP Commerce Cloud mit S/4HANA Public Cloud im Rücken: welche Daten wohin?

Wer einen B2B-Webshop auf SAP Commerce Cloud baut und dahinter ein S/4HANA Public Cloud betreibt, beantwortet im Kern immer dieselbe Frage, nur in vier Varianten: Wandern die Daten in den Shop, oder holt sie der Shop im Moment der Wahrheit live aus dem ERP? Wer diese Frage pauschal beantwortet, baut entweder einen trägen Shop oder ein überlastetes ERP. Die richtige Antwort fällt pro Datenklasse unterschiedlich aus, und genau darum geht es in diesem Beitrag.

Die Grundfrage: replizieren oder live abrufen?

Vier Datenklassen, vier Entscheidungen. Aus unserer Projekterfahrung sieht die Verteilung so aus:

Produkte und Katalog: replizieren. Der Produktstamm wandert per Replikation nach Commerce Cloud und wird dort angereichert: Verkaufstexte, Bilder, Attribute für Facettensuche, Kategoriebaum, SEO-Daten. All das gehört nicht ins ERP, sondern in den Shop, wo Content-Teams damit arbeiten. Das ERP bleibt strukturell führend: Materialnummer, Einheiten, Klassifikation kommen aus S/4HANA und werden im Shop nie überschrieben. Kataloge ändern sich selten genug, dass eine Replikation hier völlig ausreicht.

Kundenspezifische Preise: live abrufen. Im B2B hat fast jeder Kunde eigene Konditionen: Kontraktpreise, Staffeln, Rabattschemata. Diese Logik lebt in S/4HANA, und dort soll sie bleiben. Der Shop ruft den Preis im Moment der Anzeige über einen Pricing-Call ab, mit einem kurzen Cache von wenigen Minuten. Eine Preiswahrheit, keine nächtlichen Preisexporte, keine zweite Preislogik, die jahrelang synchron gehalten werden müsste.

Bestand und ATP: live abrufen, kurz gecacht. Verfügbarkeit ist im B2B eine Zusage, keine Deko. Der Shop fragt die Verfügbarkeit gegen S/4HANA ab und cacht das Ergebnis für Minuten, nicht für Stunden. Wer Bestände nur nachts repliziert, verspricht tagsüber Ware, die es nicht mehr gibt.

Aufträge: asynchron einspeisen. Die Bestellung wird im Shop bestätigt und dann über eine Queue ins ERP gebracht, mit sauberer Fehlerbehandlung: Scheitert die Anlage in S/4HANA, landet der Auftrag in einer Fehlerwarteschlange mit Alarm, nicht im Nirwana. Die Auftragshistorie im My-Account-Bereich liest der Shop dagegen live aus den S/4HANA-APIs. So sieht der Kunde auch Aufträge, die per Telefon oder EDI hereingekommen sind, nicht nur die aus dem Shop.

Warum B2B anders tickt als B2C

Die B2C-Rezepte aus dem Handbuch greifen im B2B zu kurz, und zwar aus vier Gründen.

Erstens die Preise: Im B2C gilt ein Preis für alle, den kann man bedenkenlos replizieren. Im B2B ist der Preis eine Funktion aus Kunde, Menge, Kontrakt und Tagesform der Konditionstabellen. Deshalb der Live-Call.

Zweitens das Bestellverhalten: B2B-Kunden stöbern nicht, sie beschaffen. Bestellvorlagen, Wiederbestellung aus der Historie, Schnellerfassung per Artikelnummer sind wichtiger als jede Produktinszenierung.

Drittens das Kreditlimit: Vor dem Checkout gehört eine Prüfung gegen das Credit Management in S/4HANA. Ein Auftrag, der im ERP sofort auf Kreditsperre läuft, hilft niemandem, am wenigsten dem Vertriebsinnendienst, der ihn dann von Hand ausgraben muss.

Viertens die Bestellwege: Grosse Kunden bestellen per Punch-out direkt aus ihrem Einkaufssystem, mittlere laden CSV-Dateien mit fünfzig Positionen hoch. Beides muss dieselbe Auftragsschnittstelle bedienen wie der Warenkorb.

Was in Projekten schiefgeht, und wie man es vermeidet

Der häufigste Fehler, den wir in bestehenden Architekturen antreffen, ist die nächtliche Vollreplikation der Preise. Sie wirkt harmlos, bis der erste Kontrakt untertags angepasst wird. Dann zeigt der Shop bis am nächsten Morgen den alten Preis, der Kunde bestellt, die Auftragsbestätigung aus dem ERP weicht ab, und der Innendienst darf telefonieren. Die Abhilfe ist keine schnellere Replikation, sondern der Wechsel auf Echtzeit-Pricing mit kurzem Cache. Danach gibt es genau eine Stelle, an der Preise entstehen.

Der zweite Klassiker: synchrones Buchen der Bestellung. Der Checkout wartet, bis S/4HANA den Auftrag angelegt hat. Das funktioniert, bis das ERP im Wartungsfenster steht oder ein Release einspielt. Dann bricht der Checkout ab, und zwar genau bei den Kunden, die abends um zehn ihre Bestellung erfassen wollten. Aufträge gehören immer in eine Queue: Der Shop bestätigt sofort, das ERP verarbeitet, sobald es kann, und Fehler landen in einer überwachten Warteschlange statt beim Kunden.

Und der dritte Punkt ist weniger technisch als menschlich: der Feature-Zoo. Konfiguratoren, Marktplatz-Anbindung, Loyalty, alles in Phase eins. Unser Rat ist ein Buy-Side-MVP: Katalog, kundenspezifische Preise, Bestellung, Auftragshistorie. Das ist der Kern, mit dem ein B2B-Kunde produktiv arbeiten kann, und er ist in Monaten live, nicht in Jahren. Alles Weitere kommt danach, priorisiert nach dem, was echte Kunden im echten Shop vermissen.

Einmal gebaut, mehrfach genutzt

Die Schnittstellenschicht, die hier entsteht, ist kein Shop-Zubehör, sondern ein Baustein. Pricing-Call, ATP-Abfrage, Auftrags-Queue und Historie-API sind sauber vom Frontend getrennt. Heute bedient diese Schicht SAP Commerce Cloud. Morgen bedient sie genauso eine Aussendienst-App, ein Kundenportal oder einen weiteren Vertriebskanal, ohne dass am ERP etwas Neues gebaut werden muss. Composable heisst am Ende nur: Die Investition in die API-Schicht zahlt bei jedem weiteren Frontend erneut aus.

Häufige Fragen

Hat S/4HANA Public Cloud überhaupt die APIs für dieses Muster?

Ja. Für Preise, Verfügbarkeit, Aufträge und Geschäftspartner stehen freigegebene OData- und SOAP-APIs bereit, dokumentiert im SAP Business Accelerator Hub. Die Orchestrierung, also Mapping, Queue und Fehlerbehandlung, übernimmt die SAP Integration Suite. Man arbeitet im Standard der Public Cloud, ohne Modifikationen, und bleibt damit release-fest.

Funktioniert Gast-Checkout im B2B?

In der Regel nein, und das ist kein Mangel. B2B-Konten hängen am Debitor im ERP: Konditionen, Kreditlimit, Lieferadressen, Zahlungsbedingungen sind dort verankert. Ein anonymer Warenkorb kann davon nichts nutzen. Sinnvoller ist eine schlanke Registrierungsstrecke, hinter der der Innendienst den Shop-Account mit dem richtigen Debitor verknüpft.

Wo lebt der Produktcontent, im ERP oder im Shop?

Beides, mit klarer Arbeitsteilung. Das ERP bleibt struktureller Master für Materialnummer, Einheiten und Klassifikation. Commerce Cloud übernimmt die Rolle eines leichtgewichtigen PIM: Texte, Bilder, Attribute, Kategorien. Ein separates PIM-System braucht es erst, wenn mehrere Kanäle denselben Content in mehreren Sprachen konsumieren; vorher wäre es ein System zu viel.

Wie aktuell muss der Bestand im Shop sein?

So aktuell, dass die Zusage hält. Ein Cache von zwei bis fünf Minuten auf die ATP-Abfrage ist in den meisten B2B-Szenarien der richtige Kompromiss: Er schützt das ERP vor Lastspitzen und hält die Anzeige nah genug an der Wahrheit. Nächtliche Bestandsreplikation ist dagegen de facto eine Einladung zu Lieferkonflikten.

Sie planen einen B2B-Shop auf SAP Commerce Cloud, oder Ihr bestehender Shop kämpft mit veralteten Preisen und hängenden Bestellungen? Wir zeigen Ihnen die Architektur gern anhand Ihrer Datenklassen. Sprechen Sie mit uns.