Integrationsarchitektur: SAP Sales Cloud V2 mit S/4HANA Public Cloud verbinden

SAP Sales Cloud V2 und S/4HANA Public Cloud verbinden sich über vorgefertigte Integrationspakete auf der SAP Integration Suite (Cloud Integration) auf BTP. Kein Selbstbau. SAP liefert die iFlows — für Business-Partner-Replikation, Produktkatalog, Preisbedingungen, Auftragsübertragung und Rechnungsstatus. Ihr Team konfiguriert, deployt und betreibt. Das ist der Rahmen. Der Teufel steckt in den Details.

Dieser Beitrag beschreibt die Architektur konkret: welche Standardinhalte SAP liefert, welche Datenflüsse wie funktionieren, wo auf BTP benutzerdefinierte Logik hingehört — und welche Fehler wir immer wieder sehen, obwohl sie vermeidbar wären. Einen breiteren Überblick zur gesamten Stack-Architektur bietet unser Überblick zum integrierten Stack.

Zusammenfassung: SAP liefert Standard-iFlows für Sales Cloud V2 ↔ S/4HANA Public Cloud. Die Plattform ist SAP BTP, die Integration Suite ist zwingend. Benutzerdefinierte Logik gehört als Side-by-Side-Erweiterung auf BTP — nicht in die Systeme selbst. In unseren Projekten erreichen wir den Go-live im Median nach 14 Wochen. Die Datenqualität und das Mapping sind fast immer das eigentliche Projekt.

Wie verbindet sich Sales Cloud V2 mit S/4HANA Public Cloud?

Sales Cloud V2 und S/4HANA Public Cloud sind beide Cloud-native SaaS-Systeme von SAP — aber sie teilen keine Datenbank und keinen gemeinsamen Kern. Die Verbindung läuft ausschliesslich über APIs und die SAP Integration Suite. Sales Cloud V2 spricht OData V4, S/4HANA Public Cloud spricht OData. Die Integration Suite auf BTP fungiert als Mittler: Sie übersetzt, routet und orchestriert.

Das Grundprinzip ist einfach. In der Praxis wird es komplex, sobald Sie reale Datenmodelle, Mandantenstrukturen und Geschäftsregeln einbeziehen. Aus diesem Grund gibt SAP Standard-Integrationspakete mit vorgefertigten iFlows heraus — damit nicht jede Implementierung wieder bei null anfängt. Mehr dazu, wie SAP S/4HANA Public Cloud in den Gesamtstack passt, finden Sie auf unserer Lösungsseite.

Die Integration Suite muss auf Ihrem BTP-Tenant provisioniert sein, bevor Sie die ersten iFlows deployen. Das ist keine grosse Hürde, aber ein Schritt, der in der Planung oft zu spät auftaucht. Wer damit wartet bis die Go-live-Termindiskussion beginnt, verliert zwei Wochen.

Die Standard-Integrationsinhalte

SAP liefert vorgefertigte Integrationspakete für die Sales Cloud V2 / S/4HANA Public Cloud-Kombination über den SAP Business Accelerator Hub. Diese Pakete enthalten iFlows für alle wesentlichen Flüsse. Sie laden sie in Ihren Integration Suite-Tenant, konfigurieren Credentials und Systemverbindungen, passen Feldmappings an Ihr Datenmodell an — und deployen.

In unseren mehr als zwölf Implementierungen haben wir keinen einzigen Fall gehabt, wo der Standard komplett ohne Anpassung ausgereicht hätte. Jedes Unternehmen hat Eigenheiten: zusätzliche Felder, andere Nummernkreise, abweichende Organisationsstrukturen. Aber der Standard deckt 70–80 % des Weges ab. Das ist erheblich. Sie passen die restlichen 20 % an, anstatt alles zu bauen.

Die Standard-iFlows decken folgende Flüsse ab:

• Business-Partner-Replikation: S/4HANA ist die führende Quelle für Kunden- und Kontaktdaten. Neue und geänderte Business Partner werden in Sales Cloud V2 repliziert.
• Produktkatalog-Synchronisation: Materialstammdaten aus S/4HANA stehen im Vertrieb zur Verfügung — für Angebote und Opportunities.
• Preisbedingungen: Preislisten und kundenspezifische Konditionen aus S/4HANA fliessen in Sales Cloud V2, damit Ihr Vertrieb mit validen Preisen arbeitet.
• Verkaufsauftragsübertragung: Ein bestätigtes Angebot in Sales Cloud V2 wird als Verkaufsauftrag in S/4HANA angelegt.
• Rechnungs- und Zahlungsstatus: Der Fakturastatus aus S/4HANA wird zurück in Sales Cloud V2 gespiegelt, damit Vertriebsmitarbeitende ohne ERP-Zugriff den Zahlungsstand sehen.

Das ist der Kern. Für weitergehende Flüsse — Live-Lagerverfügbarkeit, Rahmenverträge, komplexe Bonusabwicklung — braucht es entweder ergänzende iFlows oder benutzerdefinierte Erweiterungen.

Stammdatenreplikation

Stammdaten sind in unseren Projekten der aufwändigste Teil der Integration — nicht die Technik, sondern die Datenqualität. In über zwei Dritteln der Projekte, die wir begleitet haben, gab es nennenswerte Qualitätsprobleme in den Quelldaten: doppelte Business Partner, inkonsistente Adressformate, fehlende Felder, die im Standard-iFlow erwartet werden.

Die Business-Partner-Replikation läuft ereignisgesteuert. S/4HANA sendet ein Event, wenn ein Business Partner angelegt oder geändert wird. Die Integration Suite empfängt das Event, transformiert die Daten und schreibt sie in Sales Cloud V2. Kein Batch-Job, kein Polling — das ist der saubere Ansatz.

Was das in der Praxis bedeutet: Ihre S/4HANA-Stammdaten müssen vor dem Go-live bereinigt sein. Ein schmutziger Datensatz wird zuverlässig repliziert — bloss als schmutziger Datensatz in Sales Cloud V2. Die Integration Suite ist kein Datenqualitätswerkzeug.

Gleiches gilt für Produktdaten. Materialstammdaten aus S/4HANA haben oft Pflichtfelder, die im Vertrieb nie befüllt wurden — weil die Logistik sie nicht brauchte. Plötzlich sind sie relevant. Klären Sie das frühzeitig mit dem S/4HANA-Team.

Bei der Preisreplikation gibt es eine häufige Falle: Preislisten in S/4HANA sind oft komplex — Staffeln, Kundengruppen, Gültigkeitszeiträume. Der Standard-iFlow bildet die gängigen Szenarien ab. Sonderkonditionen brauchen Mapping-Arbeit. Planen Sie dafür Zeit ein.

Transaktionsflüsse

Der zentrale Transaktionsfluss ist der Weg vom Angebot zum Auftrag. Ein Vertriebsmitarbeiter erstellt ein Angebot in Sales Cloud V2. Der Kunde akzeptiert. Sales Cloud V2 überträgt das Angebot als Verkaufsauftrag in S/4HANA — vollautomatisch über einen iFlow.

S/4HANA bestätigt den Auftrag, vergibt eine Auftragsnummer und sendet die Bestätigung zurück. Der Vertriebsmitarbeiter sieht die S/4HANA-Auftragsnummer in Sales Cloud V2. Die Auftragsabwicklung läuft in S/4HANA. Der Vertrieb verbleibt in Sales Cloud V2.

Dieser Fluss funktioniert gut — wenn das Datenmodell zwischen den Systemen sauber gemappt ist. Die häufigste Reibungsstelle: Produkte, Mengeneinheiten und Preise müssen in beiden Systemen konsistent sein. Wenn ein Produkt in S/4HANA mit einer anderen Materialart oder Einheit geführt wird als in Sales Cloud V2, schlägt die Auftragsübertragung fehl. Das klingt trivial. In der Praxis ist es das, was die meisten frühen Integrationstests zum Absturz bringt.

Der Rechnungsstatus-Fluss geht in die andere Richtung. S/4HANA fakturiert und sendet den Status zurück. Vertriebsmitarbeitende sehen ohne ERP-Zugriff, ob ein Kunde eine offene Rechnung hat. Das ist ein echter Nutzen — und eine Funktion, die oft unterschätzt wird, bis jemand aus dem Vertrieb fragt, warum er keine Debitorenauskunft bekommt.

Die Service-Cloud-V2-Seite der gleichen Integration beschreibt, wie Service-Tickets und installierte Basis in das S/4HANA-Ökosystem eingebunden werden: SAP Service Cloud V2 und S/4HANA Public Cloud.

Wo benutzerdefinierte Logik hingehört: BTP Side-by-Side

Wenn der Standard nicht reicht, gehört benutzerdefinierte Logik weder in Sales Cloud V2 noch in S/4HANA. Sie lebt auf BTP — als Side-by-Side-Erweiterung. Das ist keine Einschränkung, das ist Architekturprinzip. SAP nennt es Clean Core, und es ist der einzige Ansatz, der langfristig wartbar bleibt.

Wir beobachten, dass Teams, die vorher mit SAP C4C gearbeitet haben, den Reflex haben, Geschäftslogik direkt in das CRM-System zu schreiben. In Sales Cloud V2 geht das nicht mehr — jedenfalls nicht auf die alte Weise. Das ist anfangs ein Kulturwechsel, zahlt sich aber schnell aus: keine Upgrade-Abhängigkeiten, saubere Trennung, unabhängiges Deployment.

Integration Suite, Event Mesh, Build

Auf BTP stehen drei Services für unterschiedliche Szenarien bereit:

SAP Integration Suite (Cloud Integration) ist die Hauptplattform für alle systemübergreifenden Flüsse. Hier laufen die SAP-Standard-iFlows. Hier passen Sie Feldmappings an. Hier konfigurieren Sie Fehlerbehandlung und Wiederholungslogik. Die Integration Suite bietet auch eingebautes Message-Monitoring — ein wichtiger Punkt, auf den wir im nächsten Abschnitt zurückkommen.

SAP Event Mesh auf BTP eignet sich für ereignisgesteuerte Muster, bei denen Sie nicht auf polling-basierte Ausführung angewiesen sein wollen. Wenn S/4HANA eine Statusänderung veröffentlicht, landet das Event im Event Mesh und löst downstream-Verarbeitung aus — ohne dass ein Scheduler in einem bestimmten Intervall prüfen muss. Für Business-Partner-Änderungen ist das der sauberere Ansatz gegenüber regelmässigem Bulk-Transfer.

SAP Build auf BTP kann Genehmigungsschritte orchestrieren, die menschliche Interaktion erfordern. Ein Beispiel: Ein Angebot über einem bestimmten Betrag braucht eine Freigabe, bevor es als Auftrag in S/4HANA übertragen wird. Build stellt den Approval-Workflow bereit. Die Integration Suite überträgt danach den Auftrag. Kein Custom-Code im CRM oder ERP.

Für komplexere benutzerdefinierte Logik — eigene Validierungsregeln, Datenanreicherung aus Drittsystemen, Prozesse die keiner der Standardflüsse abdeckt — setzen wir SAP CAP (Cloud Application Programming Model) auf Cloud Foundry ein. CAP-Services greifen auf die OData V4-APIs von Sales Cloud V2 und die OData-APIs von S/4HANA Public Cloud zu. Sie können auf Events reagieren, Daten transformieren und in beide Systeme schreiben. Alles ausserhalb des Kerns.

Häufige Fallstricke und wie Sie sie vermeiden

In 14 Wochen Median bis Go-live — das ist unser Erfahrungswert aus mehr als zwölf Sales-Cloud-V2-Projekten — steckt die meiste Zeit nicht in der technischen Konfiguration der iFlows. Sie steckt in diesen vier Bereichen.

Annahme: «SAP integriert» heisst «läuft sofort»

Die Standard-iFlows sind kein Plug-and-play. Sie müssen provisioniert, konfiguriert, mit Ihren Systemverbindungen verdrahtet und gegen Ihre echten Daten getestet werden. Der SAP Business Accelerator Hub liefert das Paket. Ihr Team deployt und betreibt. Wer das unterschätzt, staunt in der ersten Projektwoche.

Konkrete Gegenmassnahme: Nehmen Sie sich in der Projektplanung explizit zwei bis drei Wochen für Integration-Kickoff und initiale iFlow-Konfiguration. Behandeln Sie die Integration Suite-Provisionierung als eigenen Meilenstein, nicht als Nebenprodukt der System-Installation.

iFlows direkt modifizieren

SAP pflegt und aktualisiert seine Standard-iFlows. Wer sie direkt modifiziert, kann SAP-Updates nicht mehr sauber einspielen — oder verliert bei einem Update die eigenen Anpassungen. Das ist eine Zwickmühle, die sich vermeiden lässt.

Der richtige Weg: iFlow kopieren, Änderungen in der Kopie vornehmen, Delta zwischen Standard und Kopie dokumentieren. So bleiben Sie nah am Standard und können SAP-Updates trotzdem selektiv übernehmen. Bei grösseren Versionssprüngen vergleichen Sie Ihren Fork mit dem neuen Standard und führen die Anpassungen über.

Fehler-Monitoring überspringen

Die Integration Suite hat eingebautes Message-Monitoring. Es zeigt fehlgeschlagene Messages, Fehlermeldungen und Retry-Status. Ohne aktives Monitoring werden Integrationsfehler erst sichtbar, wenn jemand bemerkt, dass ein Auftrag in S/4HANA nicht angekommen ist. Das kann Tage dauern.

Richten Sie von Tag eins Alerting für fehlgeschlagene Messages ein. Definieren Sie, wer für welchen Fluss zuständig ist. Das ist kein Nice-to-have — das ist Teil des Go-live-Kriteriums.

Mapping-Aufwand unterschätzen

92 % Adoption sechs Monate nach Go-live — das ist unsere Messgrösse aus mehreren Projekten. Niedrige Adoption hat fast nie einen technischen Grund. Sie hat einen Datengrund: Vertriebsmitarbeitende vertrauen den Daten nicht, weil Preise falsch sind, Produkte fehlen oder Kundendaten nicht stimmen.

Das Mapping zwischen S/4HANA- und Sales-Cloud-V2-Datenmodellen ist ein eigenes Workpaket. Planen Sie es als solches. Bringen Sie frühzeitig sowohl das CRM-Team als auch das ERP-Team an einen Tisch. Die Fragen, die dort entstehen — welches Feld aus S/4HANA entspricht welchem Feld in Sales Cloud V2? — können nur diese beiden Teams gemeinsam beantworten.

Die Integration von SAP Sales Cloud V2 mit S/4HANA Public Cloud ist lösbar. SAP liefert den technischen Rahmen. Ihr Erfolg hängt davon ab, wie sorgfältig Sie Datenqualität, Mapping und Betrieb planen.

Wir sind Mitglied des DSAG CX-Arbeitskreises und haben diese Architektur in mehr als zwölf Projekten umgesetzt. Wenn Sie konkrete Fragen zu Ihrer Integrationsplanung haben, sprechen Sie mit uns.