B2B Commerce und SAP: Welche Daten fließen wohin?

Zwischen Salesforce B2B Commerce und SAP fließen Daten in vier Richtungen. Stammdaten wie Accounts, Produkte, Preisbücher und Berechtigungen kommen per Batch nach Salesforce. In Warenkorb und Checkout fragt der Shop über Commerce Extensions live bei SAP nach Preis, Verfügbarkeit und Kredit. Der fertige Auftrag geht an SAP. Auftragsbestätigung, Lieferung und Rechnung kommen zurück, damit Händler den Status im Shop sehen. SAP bleibt führend für Preise, Bestand, Kredit und den Auftrag. Salesforce hält das Einkaufserlebnis und eine Kopie dessen, was es dafür braucht. Die eigentliche Arbeit ist die Entscheidung pro Datum: kopieren oder live abfragen.

Welche Daten fließen zwischen B2B Commerce und SAP?

Am Anfang jeder Schnittstellendiskussion zeichne ich dieselbe Landkarte. Für einen typischen B2B-Shop auf Salesforce hat sie vier Blöcke:

Daten	Richtung	Wann	Typischer Weg
Kundenstämme, Käufer, Produkte, Kategorien, Preisbücher, Käufergruppen, Berechtigungen	SAP nach Salesforce	Batch, nachts oder bei Änderung	Import-APIs, Middleware
Preis, Verfügbarkeit, Kredit, Steuer, Fracht	Shop fragt SAP	Live, in Warenkorb und Checkout	Commerce Extensions
Auftrag mit Bestellnummer, Lieferadresse, Wunschtermin	Salesforce nach SAP	Beim Absenden	Auftragsexport nach dem Checkout
Auftragsnummer, bestätigte Termine, Lieferung, Rechnung	SAP nach Salesforce	Bei Änderung	Update der Order Summary

Die Tabelle sieht einfach aus. Die Entscheidungen stecken in der zweiten Spalte jeder Zeile: Welches System schreibt, und wie alt dürfen die Daten im Shop sein?

Zum Namen: Salesforce vermarktet das Produkt inzwischen auch als “Agentforce Commerce for B2B”. An der Integrationsarchitektur ändert das nichts.

Stammdaten kommen per Batch als Kopie

Alles, was sich seltener ändert, als ein Händler klickt, gehört in eine Kopie. Das sind SAP-Kundenstämme, die in Salesforce zu Accounts und Buyer Accounts werden, Ansprechpartner, die zu Käufern werden, Materialien, die zu Produkten werden, Produkthierarchien, die zu Kategorien werden, und die Preise für den Shop.

Für Produkte bietet Salesforce eine Produktimport-API1. Sie liest eine CSV-Datei, deren Spaltenüberschriften auf Produkt-, Kategorie- und Preisbuchinformationen zeigen, und läuft als asynchroner Job mit abfragbarem Status. Preisbücher werden über die Import-Einstellungen desselben Jobs zugeordnet. Das reicht für die Erstbefüllung und für regelmäßige Updates aus einer Middleware, die die Datei schreibt.

Käufergruppen (Buyer Groups) und Entitlement Policies, also die Regeln, wer welches Produkt sieht, stehen selten so in SAP. Sie müssen abgeleitet werden, zum Beispiel aus Verkaufsorganisation, Kundengruppe oder Marke. Schreiben Sie diese Ableitung als Regel auf. Sonst pflegt jemand die Käufergruppen von Hand in Salesforce, und der Shop läuft SAP innerhalb weniger Monate davon.

Wem welches Objekt gehört, beantwortet meine Object Ownership Matrix. Für einen Shop ergänze ich eine Spalte: kopiert oder live.

Preis, Bestand, Steuer und Fracht live über Extension Points

Salesforce B2B Commerce hat benannte Extension Points, an denen eigener Apex-Code einen Dienst übernimmt. Die Liste der verfügbaren Extensions2 zeigt die für SAP wichtigen:

• Commerce_Domain_Pricing_Service für Preise. Standardmäßig nutzt er Salesforce-Preisbücher.
• Commerce_Domain_Inventory_Service für Bestand. Standardmäßig nutzt er Omnichannel Inventory.
• Commerce_Domain_Tax_CartCalculator und Commerce_Domain_Shipping_CartCalculator für Steuer und Fracht. Ohne Anpassung berechnet der Shop gar keine Fracht.
• Commerce_Domain_Checkout_PlaceOrder mit der Methode validate, der Ort für eine Kredit- oder Liefersperrenprüfung direkt vor dem Absenden.
• Commerce_Domain_Checkout_CreateOrder, der aus dem Warenkorb den Auftrag erzeugt.

Jede Extension kann SAP live aufrufen. Jeder Live-Aufruf bedeutet aber Wartezeit für den Händler, Last auf SAP und eine Frage, die niemand gern beantwortet: Was macht der Shop, wenn SAP nicht antwortet?

Meine Regel: Live abfragen, wo ein falscher Wert Geld oder Vertrauen kostet, alles andere kopieren. Vertragspreise aus der SAP-Konditionslogik gehören oft in die erste Gruppe, das behandle ich in Kundenpreise in B2B Commerce. Bestand ist ein eigener Fall mit eigenem Artikel zu Bestand live oder kopiert. Die Kreditprüfung gehört in validate, bevor der Auftrag existiert, wie in B2B-Checkout mit Bestellnummer beschrieben.

Extensions oder die älteren Integrationen?

Die Seite zur Integrationsarchitektur3 ist eindeutig: Seit Winter ’24 bietet Salesforce Commerce Extensions für Preise, Bestand, Fracht, Steuer und weitere Dienste an und empfiehlt sie gegenüber dem älteren Checkout-Integrations-Framework. Das alte Framework wird weiter unterstützt, ein Abschaltdatum nennt die Seite nicht.

Eine Ausnahme gibt es. Laut Extensions-Leitfaden4 lassen sich Zahlungen noch nicht per Extension anpassen, dafür bleiben die Integrationen der Weg. Mit SAP hat das selten zu tun, weil Händler meist auf Rechnung mit Bestellnummer kaufen.

Für neue Shops würde ich jeden SAP-Aufruf als Extension bauen. Registrierung und Zuordnung zum Store laufen über die Salesforce CLI und können damit im Repository und in der Pipeline liegen. Mehr dazu in Commerce Extensions: Eigenentwicklung, die Updates übersteht.

Wie kommt der Auftrag zu SAP, und was kommt zurück?

Sendet der Händler die Bestellung ab, legt B2B Commerce in Salesforce einen Auftrag und eine Order Summary an. Die Order Summary hat ein Feld OrderLifeCycleType. Laut Developer Guide5 kennzeichnet “unmanaged” eine von B2B Commerce angelegte Summary, deren Lebenszyklus in einem externen System läuft, und Änderungen dort “must be reflected in Salesforce”.

Mit SAP ist das der Normalfall. Der Auftrag geht raus, SAP legt den Kundenauftrag an, und die Schnittstelle schreibt den Status zurück:

Nutzer mit der Berechtigung B2B Commerce Integrator User oder Edit Unmanaged Order Summaries dürfen diese Summaries aktualisieren. Wem der Auftrag gehören sollte und wann Salesforce Order Management stattdessen sinnvoll ist, steht in Shop-Bestellungen ins ERP.

Planen Sie den Rückweg so sorgfältig wie den Hinweg. Ein Händler, der drei Tage lang “Bestellung eingegangen” sieht, ruft im Innendienst an, und der Shop hat nichts gespart.

Middleware oder direkte Callouts?

MuleSoft bietet einen Accelerator for SAP6 für SAP ECC, S/4HANA und Salesforce. Sein Quote-to-Cash-Anwendungsfall synchronisiert Auftrags-, Bestands- und Kundendaten zwischen Sales Cloud und S/4HANA, ein zweiter Anwendungsfall deckt B2B-EDI ab. Sie bekommen damit API-Vorlagen als Startpunkt. Eine fertige Anbindung für einen B2B-Commerce-Store enthält er nicht, die Shop-Seite bleibt Ihre Arbeit.

Direkte Apex-Callouts mit Named Credentials reichen für einen Shop mit zwei oder drei Live-Abfragen und einem Auftragsexport. Eine Middleware lohnt sich, wenn dieselben SAP-Daten auch Field Service, Manufacturing Cloud oder Agentforce-Agenten versorgen. Dann bedient eine Auftragsstatus-API den Shop, den Auftragsstatus-Agenten und den Service. Warum Agenten solche APIs mitnutzen sollten, statt eigene zu bekommen, erklärt die KI-Masterclass im Kapitel MCP und Schnittstellen.

Rechenbeispiel: S/4HANA und 300 Händler in Europa

Ein Maschinenbauer arbeitet mit SAP S/4HANA und will einen Shop für 300 Händler in Europa mit 15.000 Ersatzteilen. Die Schnittstellenliste nach dem ersten Workshop könnte so aussehen:

1. Kundenstamm zu Accounts und Buyer Accounts, nachts.
2. Materialien und Produkthierarchie zu Produkten und Kategorien, nachts, über den Produktimport.
3. Listen- und Händlerstaffelpreise in Preisbücher, nachts.
4. Vertragspreise der 40 größten Händler live über die Pricing-Extension.
5. Bestandsstatus stündlich kopiert, bestätigter Termin live im Checkout.
6. Kredit und Liefersperre live in validate.
7. Auftrag an SAP, Auftragsnummer und Status binnen Minuten zurück, Lieferungen und Rechnungen bei Änderung.

Sieben Schnittstellen, drei davon live. Das ist ein realistischer Umfang für ein erstes Release, und jede davon braucht einen Verantwortlichen auf Kundenseite.

Erster Schritt: Object Ownership Matrix und Schnittstellenliste

Schreiben Sie Object Ownership Matrix und Schnittstellenliste, bevor jemand die Shopseiten entwirft. Notieren Sie für jedes Datum das führende System, Kopie oder live, das maximale Alter und was passiert, wenn SAP nicht erreichbar ist. Das Kapitel zur ERP-Anbindung der Masterclass B2B Commerce bringt diese Entscheidungen in eine Reihenfolge, und eine unabhängige Prüfung von Schnittstellen gehört zu meiner Arbeit bei Salesforce-Schnittstellen.

Quellen6

1. 1Produktimport-API (öffnet in einem neuen Tab)developer.salesforce.com
2. 2Liste der verfügbaren Extensions (öffnet in einem neuen Tab)developer.salesforce.com
3. 3Seite zur Integrationsarchitektur (öffnet in einem neuen Tab)developer.salesforce.com
4. 4Extensions-Leitfaden (öffnet in einem neuen Tab)developer.salesforce.com
5. 5Developer Guide (öffnet in einem neuen Tab)developer.salesforce.com
6. 6Accelerator for SAP (öffnet in einem neuen Tab)anypoint.mulesoft.com