Salesforce B2B Commerce: Storefront-Architektur vor der Integration ermitteln

Ein Unternehmen beauftragt eine neue Versandkostenberechnung für Salesforce B2B Commerce, doch der Dienstleister schätzt den Aufwand anhand seiner Erfahrung mit einer anderen Storefront. Nach Projektbeginn zeigt sich: Warenkorbkomponenten, Navigation und Checkout-Mechanismus sind hier anders. Um keine Integration für die falsche Architektur einzukaufen, bestätigen Sie zuerst das Produkt, die Laufzeitumgebung der Storefront und die vorhandenen Erweiterungspunkte. Die folgende Diagnose soll ein verifiziertes Architekturprofil des konkreten Shops liefern.

Dieser Leitfaden richtet sich an E-Commerce-Verantwortliche und technische Eigentümer eines bestehenden Shops: So geben Sie dem Dienstleister korrekte Ausgangsdaten und trennen die Anbindung eines Dienstes vom Umbau der Storefront.

1. Bestimmen Sie das Produkt, nicht den Namen auf der Präsentation

Die Bezeichnung Salesforce oder Commerce Cloud beschreibt noch keine technische Grundlage. Salesforce bietet unterschiedliche Commerce-Lösungen, darunter B2B und B2C; ein gemeinsames Branding macht ihre Entwicklungsmodelle nicht austauschbar. Bitten Sie den Administrator, die erworbenen Produkte mit dem tatsächlich konfigurierten Shop abzugleichen, statt das Produkt aus der Käufergruppe abzuleiten.

Eine eigenständige Website kann Kontakte und Bestellungen an Salesforce CRM übertragen, während Warenkorb und Katalog auf einer anderen Plattform laufen. Das ist eine CRM-Integration, kein Nachweis für Salesforce B2B Commerce. Auch der Verkauf an Händler bestimmt das Produkt nicht: Das B2B-Geschäftsmodell und der Name der Softwarelösung sind verschiedene Dinge. Halten Sie im Profil fest, wo der Warenkorb entsteht, wer den Gesamtbetrag berechnet und welches System die Bestellung annimmt.

Sammeln Sie den Namen der Salesforce-Organisation, die Shop-Kennung, Umgebungsadressen, die Produktbestätigung und den Repository-Link. Nehmen Sie keine Passwörter, Tokens oder Käuferdaten auf. Lassen Sie Widersprüche zwischen Unterlagen und Konfiguration bis zur gemeinsamen Prüfung offen.

2. Ermitteln Sie die Runtime anhand der Konfiguration

Runtime bezeichnet die Umgebung, in der die Shop-Oberfläche ausgeführt wird. Salesforce dokumentiert für B2B-Storefronts Vorlagen auf Lightning Web Runtime (LWR) und Aura. Für neue Shops wird B2B LWR empfohlen. Wurde die Organisation vor Spring ’23 für Commerce aktiviert, kann auch eine B2B-Aura-Vorlage verfügbar sein. Das ist eine Bedingung für die Verfügbarkeit der Vorlage, keine Methode, die Runtime einer bestimmten Website aus ihrem Alter abzuleiten.

Vorlage und Komponenten gemeinsam prüfen

Lassen Sie sich vom Administrator die Vorlage des richtigen Shops in den Website-Verwaltungswerkzeugen und vom Entwickler das zugehörige Projekt mit seinen Komponenten zeigen. LWC steht für Lightning Web Components, also das Komponentenmodell der Oberfläche; LWR ist die Laufzeitumgebung. LWC im Repository allein beweisen kein LWR: Im Migrationsszenario beschreibt Salesforce auch die Wiederverwendung untergeordneter LWC aus einer Aura-Storefront.

Ein Screenshot, eine Domain oder die Ladegeschwindigkeit sind schwache Belege. Dokumentieren Sie für jeden Shop getrennt das Prüfdatum, die Vorlage, die Bestätigungsquelle und die verantwortliche Person.

Eine getrennte Oberfläche benötigt ein zweites Architekturprofil

Nutzt der Käufer ein separates Frontend, klären Sie, welches Commerce-Backend dahintersteht, wo die Oberfläche bereitgestellt wird und wie sie Daten abruft. Headless beschreibt die Trennung von Oberfläche und Handelssystem, keinen Produktnamen und keine Kompatibilitätsgarantie. Prüfen Sie beide Teile sowie einen eventuell vorhandenen Zwischenserver. Als Hintergrund eignet sich der Beitrag dazu, wann eine Headless-Shoparchitektur sinnvoll ist; hier ist die Aufgabe enger gefasst: eine bereits installierte Lösung identifizieren.

3. Erstellen Sie eine Tabelle mit Belegen und Konsequenzen

Ein Architekturprofil der Storefront verbindet Belege mit Integrationsentscheidungen. Die Aussage „wir haben Lightning“ erklärt nicht, welcher Code die Berechnung auslöst. Die Tabelle ist eine Abnahmevorlage für die Diagnose, kein automatischer Plattformdetektor.

Ergänzen Sie jede Zeile um „bestätigt“, „Hypothese“ oder „nicht ermittelt“ und einen Beleglink. Sind Runtime oder Checkout-Mechanismus unbekannt, folgt als nächster Schritt eine Untersuchung und keine Festpreisschätzung für einen Konnektor.

4. Finden Sie den Berechnungsort vor der Konnektorauswahl

In der Salesforce-Dokumentation unterscheiden sich die Checkout-Integrationsmechanismen für B2B LWR von den Checkout-Subflows von Aura. Außerdem empfiehlt Salesforce Commerce extensions für gezieltere Anpassungen anstelle des älteren, weiterhin unterstützten checkout integrations framework. Das ist keine Aufforderung, einen funktionierenden Shop sofort neu zu schreiben: Klären Sie zuerst, was er verwendet und welche Anforderungen der neue Dienst stellt.

Zeichnen Sie eine Anfrage auf: Käuferaktion → Storefront-Komponente → serverseitige Berechnung → externer Dienst → Ergebnis im Warenkorb. Notieren Sie an jedem Pfeil den Verantwortlichen, übertragene Daten und das Fehlerverhalten. Klären Sie, ob Versandkosten nach einer Adressänderung neu berechnet werden, wann ein Ergebnis veraltet und ob eine verspätete Antwort eine neuere Auswahl überschreiben kann. Das sind Prüffragen für Ihre Implementierung, keine universellen Salesforce-Eigenschaften.

Beschreiben Sie den Austauschvertrag: Produktkennungen, Maßeinheiten, Währung, Adresse, Unternehmenskontext und Anfrageversion. Bestimmen Sie die Quelle jedes Werts. Wenn ERP und Commerce Verpackungen unterschiedlich interpretieren, korrigiert eine geänderte Schaltfläche die Berechnung nicht.

5. Tarnen Sie eine Aura-→-LWR-Migration nicht als Integration

Der offizielle Plan für die Migration eines B2B-Shops von Aura zu LWR sieht einen neuen Shop mit passender Vorlage, den Ersatz von Aura-Komponenten durch LWC, die Übertragung der Konfiguration und eine Prüfung vor der Veröffentlichung vor. Insbesondere wechselt der Warenkorb von einer record page zu einer named page; Links und Navigationskomponenten benötigen daher Aufmerksamkeit. Diese konkrete Abhängigkeit wird bei einer Schätzung für „nur die Versandanbindung“ leicht übersehen.

Salesforce beschreibt außerdem einen separaten Projektbereich, um die bestehende Aura-Storefront während der Arbeiten zu erhalten. Machen Sie daraus Ihren eigenen Plan für parallele Prüfungen: Was bleibt verfügbar, wo wird der neue Shop getestet und wer genehmigt die Umschaltung? Eine erhaltene alte Storefront bedeutet noch keinen vorbereiteten Bestellungs-Rollback: Die Datenbewegungen nach der Umschaltung müssen separat geplant werden.

Hypothetisches Beispiel: Rabatt vorhanden, Versand fehlt

Ein fiktiver Distributor hat eine Aura-Storefront und eine eigene Lagerauswahl im Warenkorb. Das Team wechselt gleichzeitig zu LWR und bindet einen Versanddienstleister an. Die neue Seite zeigt weiterhin den vereinbarten Preis, doch die Schaltfläche „zum Warenkorb“ führt über die alte Route und das gewählte Lager fehlt in der Versandanfrage. Das ist ein erfundenes Schulungsszenario, kein GL.ua-Projekt und keine Aussage über einen standardmäßigen Plattformfehler.

Zuerst werden Navigation und Lagerübertragung geprüft, dann die Antwort des Versanddienstleisters und deren Darstellung. Adresse, Lager, Produkte und Käuferkontext müssen zu derselben Anfrage gehören. Ein korrekter Preis beweist nicht, dass der übrige Checkout korrekt ist.

6. Prüfen Sie vor dem Start einen vollständigen Ablauf

Ein Integrationstest vor dem Start muss das identifizierte Produkt und dessen Runtime abbilden, nicht den Demoshop des Dienstleisters. Bereiten Sie Testunternehmen mit unterschiedlichen Berechtigungen und einen Referenzproduktsatz ohne echte personenbezogene Daten vor. Halten Sie für jeden Test Soll-Ergebnis, Ist-Ergebnis und die für Abweichungen verantwortliche Person fest.

1. Gleichen Sie das Profil mit der Testumgebung ab: Produkt, Vorlage, Versionen des eigenen Codes und Integrationskonfiguration. Nicht vergleichbare Umgebungen belegen keine Startbereitschaft.
2. Melden Sie sich als Käufer verschiedener Unternehmen an. Prüfen Sie verfügbaren Katalog und Preis, danach den entsprechenden Kontext in der serverseitigen Berechnung; fremde Konditionen dürfen nicht zwischen Sitzungen übertragen werden.
3. Durchlaufen Sie Produkt → Warenkorb → Checkout. Ändern Sie Menge, Adresse und gegebenenfalls Lager. Bestätigen Sie die Neuberechnung für den aktuellen Datensatz.
4. Simulieren Sie in einer kontrollierten Umgebung Verzögerung, Ausfall und ungültige Antwort des externen Dienstes. Prüfen Sie Käufermeldung, Supportdiagnose und zulässige Folgeaktion.
5. Testen Sie wiederholtes Klicken und erneutes Senden nach einem Fehler. Bestätigen Sie anhand der Protokolle, dass die Integration keine doppelte Bestellung oder falsche Bestätigung erzeugt hat.
6. Prüfen Sie den Ablauf auf Desktop und Mobilgerät, einschließlich direktem Warenkorb-Link und Rückkehr aus dem Checkout. Prüfen Sie bei einer Migration geänderte Routen gesondert.
7. Gleichen Sie die Bestellsumme in Commerce und im Buchführungssystem ab, proben Sie Umschaltung und Stoppverfahren. Geben Sie den Start erst nach Behebung kritischer Abweichungen frei.

Den umfassenderen Prozess beschreibt der Beitrag über Abnahme und Rollback eines Onlineshops. Hier zählt vor allem der Bezug des Tests zur tatsächlichen Architektur.

7. Bewerten Sie Abhängigkeiten, Kosten und Zuständigkeiten

Die Dauer hängt vom Zugriff auf Konfiguration und Code, der Testumgebung, der Dienstdokumentation, eigenen Komponenten und einer gegebenenfalls nötigen Runtime-Migration ab. Schätzen Sie bis zum Abschluss der Diagnose einzelne Phasen mit ausdrücklich benannten Unbekannten. Vereinbaren Sie den Starttermin erst nach Prüfung des risikoreichsten Szenarios.

Trennen Sie im Budget Bestandsaufnahme, Prototyp der kritischen Berechnung, Oberflächenänderungen, serverseitige Erweiterung, Datenzuordnung, Tests, Umschaltung und Support. Prüfen Sie Lizenzen, Bedingungen externer Dienste, Umgebungen und Betriebskosten gesondert. Eine gegebenenfalls nötige Aura-→-LWR-Migration hat ihren eigenen Umfang; verstecken Sie ihn nicht in den Konnektorkosten. Ohne diese Angaben gibt es weder einen Universalpreis noch eine garantierte Frist.

Die Hauptrisiken sind ein falsch bestimmtes Produkt, eine unvollständige Codeinventur, die Weitergabe von Unternehmenskontext zwischen Firmen und veraltete Berechnungsdaten. Benennen Sie für jedes Risiko einen Verantwortlichen und ein Stoppkriterium. Ohne Implementierungszugriff und reproduzierbaren Test-Checkout erhöht ein weiterer Dienst nur die Unsicherheit.

Das Diagnoseergebnis verlangt keinen Plattformwechsel, sondern liefert eine ausreichende Grundlage für die Wahl zwischen lokaler Anpassung, separater Storefront-Migration und umfassenderer Neuplanung. Zur Besprechung der Webarchitektur und einer möglichen Drupal-orientierten Alternative übermitteln Sie das Shop-Profil und den Referenzablauf über die Seite für Website-Entwicklung von GL.ua (Glyanec). Das ist ein konkreter Einstieg in eine Beratung, kein Versprechen einer Salesforce-Implementierung oder automatischen Migration.