SAP Sales Cloud V2 mit eigenen Cloud Foundry Apps auf SAP BTP erweitern

SAP Sales Cloud V2 ist ein leistungsfähiges CRM ab Werk. Leadmanagement, Opportunity-Tracking, Kontohierarchien, Aktivitätsprotokollierung: alles dabei. Doch wenn Sie SSCV2 für ein reales Unternehmen konfiguriert haben, kennen Sie die Grenze, an der die Standardkonfiguration aufhört und die individuellen Anforderungen beginnen.

Vielleicht ist es ein Aussendienst-Team, das eine KI-gestützte Besuchsplanung braucht. Ein Lebensmittelvertrieb, bei dem die Rechnungsadresse die Verkaufsorganisation bestimmt. Ein Callcenter, das Twilio-basierte Browsertelefonie direkt in SSCV2-Interaktionen protokollieren muss. Das sind keine Sonderfälle. Das ist Alltag.

Genau hier kommen eigene Cloud Foundry-Applikationen auf SAP BTP ins Spiel. Genau dort haben wir in den letzten drei Jahren produktive Erweiterungen für mehrere Mandanten und Branchen gebaut.

Kurzfassung: Wenn die Konfiguration von SAP Sales Cloud V2 an ihre Grenzen stösst, erweitern Sie Side-by-Side auf SAP BTP, statt den Kern zu verändern. Wir nutzen vier Muster: HTML-Mashups, Custom OData Services, ereignisgesteuerte Webhooks und API-Integration, alle auf einer Cloud-Foundry-Architektur mit drei Apps (AppRouter, Node.js-Backend, statische Oberfläche). Dieser Beitrag erklärt, wie jedes Muster funktioniert und auf welche Stolpersteine wir in der Produktion gestossen sind.

Warum stösst die Standardkonfiguration von SSCV2 an ihre Grenzen?

CRM-Projekte bleiben oft hinter den Erwartungen zurück, wenn zwischen dem, was das Produkt mitliefert, und dem, was Anwender tatsächlich brauchen, eine Lücke klafft. Das Konfigurationswerkzeug von SSCV2 (Adaptation Mode, Autoflows, Key-User-Einstellungen) deckt die Grundlagen solide ab. Doch es hat harte Grenzen.

Sie können keine individuelle Oberfläche bauen, die gleichzeitig Daten aus drei Systemen abruft. Sie können keine komplexe Geschäftslogik ausführen, die S/4HANA abfragt, Scoring-Algorithmen anwendet und Ergebnisse zurückschreibt. Sie können kein Echtzeit-Telefonie-Widget mit WebSocket-Event-Streaming einbetten. Und Sie können keine vollständig neuen Business Objects mit eigenen Listenansichten und Detailseiten registrieren.

Das ist keine Kritik; das liegt in der Natur jedes SaaS-Produkts. Die Frage ist nicht, ob Sie Erweiterungen brauchen, sondern wie Sie sie bauen, ohne eine Wartungslast zu schaffen. Genau deshalb hat SAP in das Side-by-Side Extension Model investiert: um Ihnen einen sauberen Weg zu bieten, wenn die Konfiguration an ihre Grenzen stösst.

Was ist das Side-by-Side Extension Model auf BTP?

55 % der ASUG-Mitglieder nutzen inzwischen SAP BTP, gegenüber 40 % im Jahr 2023, und 35 % dieser Nutzer setzen BTP gezielt ein, um SAP-Anwendungen zu erweitern und gleichzeitig einen Clean Core zu bewahren (ASUG Pulse of the SAP Customer, 2025). Der Adoptionstrend ist eindeutig: Unternehmen bewegen sich weg von In-App-Modifikationen hin zu unabhängigen, upgradesicheren Erweiterungen.

Statt den SSCV2-Kern zu verändern (wovon SAP in seinen Clean-Core-Empfehlungen ausdrücklich abrät), deployen Sie unabhängige Cloud-Foundry-Applikationen, die über APIs, Events und UI-Einbettung mit SSCV2 kommunizieren.

Jede produktive Erweiterung, die wir gebaut haben, folgt einer Drei-App-Cloud-Foundry-Architektur:

Komponente	Technologie	Zweck
AppRouter	@sap/approuter	XSUAA-Authentifizierung, CORS, Routing, iframe-Embedding; der einzige Einstiegspunkt, den SSCV2 aufruft
Express Backend	Node.js + Express	REST API, Geschäftslogik, OData-Proxying, WebSocket-Unterstützung, externe Integrationen
Static UI Server	HTML/CSS/JS	Mashup-Seiten, eingebettet in SSCV2-Bildschirmen

Alle drei werden im selben CF Space deployed. Der AppRouter authentifiziert den Benutzer über XSUAA JWT Tokens und routet Anfragen an das Backend oder den UI Server. SSCV2-API-Aufrufe laufen über den BTP Destination Service, niemals direkt per HTTP. Dieser übernimmt automatisch den OAuth2 Token Exchange, die Zertifikatsverwaltung und das Connection Pooling.

Aus unserer Erfahrung: Dieses Drei-App-Pattern ist nicht theoretisch. Es läuft produktiv in unserem Engage CTI-System, Kundenportal, der WhatsApp-Integration, dem Aussendienst-Besuchsplaner und den Produkttracking-Mashups, alles deployed auf BTP Cloud Foundry.

Wie erweitern HTML Mashups SSCV2?

HTML Mashups sind das einfachste Extension-Pattern und der schnellste Weg in die Produktion. Sie registrieren eine URL, SSCV2 lädt sie als iframe in das gewählte Seitenlayout, und fertig. Keine Metadaten-Registrierung. Keine OData-Endpoints. Einfach eine Webseite, die innerhalb Ihres CRM erscheint.

Doch «einfach» heisst nicht «limitiert». Die wahre Stärke liegt im Kontext, den SSCV2 über URL-Query-Parameter an Ihr Mashup übergibt: accountId, contactId, opportunityId und jeden weiteren Parameter, den Sie konfigurieren. Ihr Mashup empfängt diese, ruft die benötigten APIs auf und rendert eine Oberfläche, die mit der Standardkonfiguration unmöglich wäre.

Praxisbeispiel: Für einen Schweizer Lebensmittelvertrieb haben wir ein Mashup gebaut, das S/4HANA-Geschäftspartnerdaten neben den SSCV2-Kontodetails anzeigt. Der Vertriebsmitarbeiter sieht Lieferadressen, Zahlungsbedingungen und offene Aufträge aus S/4, alles innerhalb der SSCV2-Kontoseite und ohne Systemwechsel.

Weiteres Beispiel: Unser Besuchsplaner für OPO Oeschger bettet eine vollständige Drag-and-Drop-Wochenplanung in SSCV2 ein. Ein KI-Scoring-Modell ordnet die Accounts im Gebiet jedes Verkäufers nach Faktoren wie überfälligen Besuchen, ABC-Klassifikation, Besuchsrhythmus und Geografie, wie in der Erfolgsgeschichte von OPO Oeschger beschrieben. Der Verkäufer zieht vorgeschlagene Besuche in seinen Kalender, alles innerhalb eines Mashups.

Eine Einschränkung, die Sie kennen sollten: SSCV2 begrenzt die iframe-Höhe von Mashups auf ungefähr 800 Pixel (SAP Note 0003704111). Planen Sie Ihre Oberfläche entsprechend.

Wie ermöglichen Custom OData Services tiefe Integration?

Wenn ein Mashup nicht reicht und Sie möchten, dass SSCV2 Ihre Daten als vollwertiges Objekt behandelt, registrieren Sie einen Custom Service. Dies gibt Ihnen vollständige OData V4-Entitäten mit CRUD-Operationen, Listenansichten, Detailseiten und Quick Views, alles gerendert vom nativen SSCV2-UI-Framework.

Der Registrierungsablauf umfasst sechs Schritte:

1. POST Ihrer OData V4-Metadaten an den SSCV2 repository-service
2. Data Connector im DIRECT-Modus erstellen, der auf Ihre CF AppRouter-URL zeigt
3. UI Views (Worklist, Detail, Quick View) im SSCV2 UI Designer konfigurieren
4. Den Service über den IAM Service einer Rolle zuweisen
5. Bei Bedarf Extension Fields auf verwandten Entitäten erstellen
6. OData-Endpoint auf Ihrem Express Backend registrieren

Nach der Registrierung ruft SSCV2 Ihre CF-App auf, als wäre sie eine native Datenquelle. Benutzer sehen Ihre Custom Entities in der Navigation, können suchen und filtern und in Detailseiten wechseln, alles innerhalb der Standard-SSCV2-Oberfläche.

Wir haben dieses Pattern für die Integration eines Payment Gateways (Wallee) und für Produkttracking-Services eingesetzt. Der Hauptvorteil gegenüber Mashups: Ihre Daten nehmen am Beziehungsmodell von SSCV2 teil. Sie können Custom Entities über Extension Fields mit Konten, Kontakten und Opportunities verknüpfen.

Wie ermöglichen Webhooks Event-Driven Extensions?

SSCV2-Autoflows können Webhooks auslösen: HTTP-POST-Aufrufe an Ihre CF-App, wenn bestimmte Events eintreten. So bauen Sie reaktive Erweiterungen, die in Echtzeit auf CRM-Aktivitäten reagieren, ohne Polling oder manuellen Eingriff.

Aus unserem Produktiv-Deployment: Für Intelligentfood haben wir einen Webhook-Handler gebaut, der ausgelöst wird, wenn ein neues Konto in SSCV2 erstellt wird. Der Handler liest die Rechnungsadresse, ermittelt die korrekte Verkaufsorganisation (Schweiz, Österreich, Frankreich oder Niederlande basierend auf dem Ländercode) und aktualisiert das Konto mit dem passenden salesArrangements-Eintrag. Was sonst eine manuelle Zuweisung durch einen Administrator erfordern würde, geschieht automatisch in unter einer Sekunde.

Das Webhook-Pattern verwendet Basic Auth statt XSUAA, denn es handelt sich um Server-zu-Server-Kommunikation ohne Benutzerkontext. Machen Sie Ihren Handler idempotent, damit ein mehrfach zugestelltes Ereignis keinen Schaden anrichtet.

Ein Fallstrick, den wir früh gelernt haben: Die $batch-API von SSCV2 wird über den Destination Service nicht unterstützt (liefert HTTP 405). Wenn Ihr Webhook-Handler mehrere Entitäten aktualisieren muss, verwenden Sie parallele Einzelaufrufe; wir haben bis zu 30 gleichzeitige Requests ohne Probleme mit Promise.all() getestet.

Welche Patterns eignen sich am besten für API-Integration und Datensynchronisation?

Ein CRM ist nur so nützlich wie die Daten, die es enthält. Viele Erweiterungen drehen sich rein darum, diese Lücke zu schliessen: SSCV2 mit ERP-Systemen zu synchronisieren, Datensätze aus externen Quellen anzureichern oder CRM-Daten für andere Plattformen bereitzustellen.

Jeder SSCV2-REST-API-Zugriff von CF-Apps läuft über den BTP Destination Service mit einem von zwei Authentifizierungsmustern:

Auth-Pattern	Anwendungsfall	Wann einsetzen
OAuth2SAMLBearerAssertion	Propagierte Benutzeridentität	Operationen, die die rollenbasierte Zugriffskontrolle von SSCV2 respektieren sollen
Basic Auth (technischer Benutzer)	Server-zu-Server	Hintergrundjobs, Integrationen, Webhooks ohne Benutzerkontext

Extension Fields sind die Methode, um benutzerdefinierte Daten auf Standard-SSCV2-Entitäten zu speichern. Sie erstellen sie über die repository-service-API und greifen über das extensions-Objekt in jeder Entity-Response darauf zu. Wir nutzen sie intensiv für Besuchssperr-Flags, Kundengruppencodes und Synchronisationszeitstempel.

Ein Wort der Vorsicht: Das Löschen von Extension Fields ist endgültig. Es entfernt alle gespeicherten Werte über alle Datensätze hinweg, ohne Rollback-Möglichkeit. Testen Sie immer zuerst im QAS-Tenant.

Für die S/4HANA-Integration übernimmt die SAP Integration Suite die Datenreplikation über iFlows. Unser Intelligentfood-Projekt nutzt dies für die bidirektionale Synchronisation zwischen S/4-Geschäftspartnern und SSCV2-Konten, ein gängiges Pattern für Unternehmen, die beide Systeme betreiben.

Wie funktionieren Authentifizierung und Mandantenfähigkeit in der Praxis?

Authentifizierung und Mandantenfähigkeit sind die Stellen, an denen sich der grösste Teil der Komplexität von BTP-Erweiterungen bündelt. Darauf haben wir uns nach dem Deployment über mehrere Mandanten hinweg festgelegt:

XSUAA ist nicht verhandelbar. Jede CF-App erhält eine XSUAA-Service-Instanz. Der AppRouter validiert JWT Tokens und leitet sie an das Backend weiter. Ihr Express Server nutzt @sap/xssec, um die Benutzeridentität zu extrahieren und Scopes zu prüfen.

Custom IDP für SSO. Wenn Ihre Erweiterung in einem SSCV2-Mashup-iframe geladen wird, ist der Benutzer bereits authentifiziert. Ohne Custom IDP würde der iframe ihn erneut zur Anmeldung auffordern. Durch die Konfiguration von SAP IAS als vertrauenswürdigem Identity Provider und das Setzen von identityProvider: "sap.custom" im AppRouter erreichen Sie durchgängiges Single Sign-On.

Mandantenfähigkeit über Environment Files. Jeder Kunde erhält seinen eigenen BTP-Subaccount mit einer dedizierten XSUAA-Instanz. Wir verwalten die mandantenspezifische Konfiguration über .env.<tenantId>-Dateien, die bei Deploy-Zeit in die manifest.yml-Variablensubstitution einfliessen. Dieselbe Codebasis, isolierte Infrastruktur.

Was zeichnet Spadoom aus?

SAPs Partnerökosystem umfasst über 25’000 Unternehmen (SAP News Center, 2025). Warum also mit uns arbeiten? Weil wir nicht bloss zur SSCV2-Erweiterbarkeit beraten, sondern Produktivcode liefern.

Engage ist unsere Flaggschiff-Extension-Suite: CTI mit Twilio-Browsertelefonie, ein Self-Service-Kundenportal, WhatsApp-Messaging mit Interaktionsprotokollierung, SharePoint-Dokumentenintegration und ein produktübergreifender Admin Hub. Sechs separate Applikationen, deployed als mandantenfähiges SaaS auf BTP.

MCP-SSCV2 kapselt über 65 SSCV2-REST-APIs als KI-zugängliche Tools, sodass Claude programmatisch mit SAP Sales Cloud V2 interagieren kann. So automatisieren wir das Tenant-Setup, testen API-Verhalten und prototypisieren neue Erweiterungsideen deutlich schneller als von Hand.

Intelligentfood übernimmt die vollständige S/4HANA-zu-SSCV2-Integration für ein Schweizer Lebensmittelunternehmen: Webhook-gesteuerte Kontozuweisung, Besuchsplanung und bidirektionale Datensynchronisation über zwei BTP Destinations.

Der Besuchsplaner von OPO Oeschger nutzt KI-Scoring, um zu priorisieren, welche Kunden jeder Verkäufer besucht, mit Drag-and-Drop-Planung direkt eingebettet in SSCV2.

Das sind keine Konferenzdemos. Das sind Produktivsysteme, die täglich echte Daten für echte Vertriebsteams verarbeiten.

Häufig gestellte Fragen

Kann man SAP Sales Cloud V2 erweitern, ohne den Core zu verändern?

Ja. SAPs Side-by-Side-Modell auf BTP erlaubt es, CF-Apps zu deployen, die über APIs, Mashups und Webhooks integrieren, ohne den SSCV2-Kern anzufassen. Das ist der Clean-Core-Ansatz, den SAP für neue Erweiterungen empfiehlt.

Was ist der Unterschied zwischen einem HTML Mashup und einem Custom Service?

Mashups betten Ihre Webapplikation als iframe ein, ideal für Dashboards und schnelle Integrationen. Custom Services registrieren vollständige OData V4-Entitäten, die SSCV2 wie native Daten behandelt, mit Standard-Listenansichten, Detailseiten und CRUD-Operationen. In unserem SAP BTP-Überblick erfahren Sie, wie beide Patterns in die Plattformarchitektur passen.

Wie funktioniert die Authentifizierung für Erweiterungen auf BTP?

XSUAA übernimmt die JWT-basierte Authentifizierung, während der Destination Service den Token Exchange verwaltet. Für SSO in Mashup-iframes konfigurieren Sie SAP IAS als Custom Identity Provider, damit sich Benutzer nur einmal anmelden.

Wie lange dauert es, eine SSCV2-Erweiterung zu entwickeln?

In unseren Projekten ist ein einfaches HTML-Mashup typischerweise in ein bis zwei Wochen live, ein Custom OData Service mit vollem CRUD in drei bis sechs Wochen. Erweiterungen, die mehrere Muster kombinieren, etwa CTI-Integration oder Besuchsplanung, dauern je nach Umfang zwei bis vier Monate.

Unterstützt Spadoom mandantenfähige Deployments?

Ja. Unsere Erweiterungen sind für mandantenfähiges Deployment mit einem eigenen BTP-Subaccount pro Kunde gebaut. Dieselbe Codebasis bedient alle Mandanten über umgebungsbasierte Konfiguration, während jeder Kunde eine isolierte Infrastruktur behält.

Jetzt loslegen

Wenn Ihre SSCV2-Instanz an die Grenzen der Standardkonfiguration stösst, müssen Sie keine Kompromisse eingehen. Eigene Cloud Foundry-Applikationen auf BTP geben Ihnen die volle Leistungsfähigkeit einer modernen Entwicklungsplattform, während Ihr CRM-Core sauber und upgradefähig bleibt.

Wir haben diese Erweiterungen branchenübergreifend gebaut (Lebensmittel, Baumaterialien, Verpackung) und die Muster zu einer wiederholbaren Architektur verdichtet, die in Wochen statt Monaten deployed wird. Ob Sie von C4C migrieren oder eine frische SSCV2-Instanz erweitern: Der Ansatz ist derselbe. Dasselbe Side-by-Side-Muster erweitert auch S/4HANA Public Cloud; deshalb setzen wir für beides ein Team ein, wie unser Leitfaden zur Wahl eines SAP-Partners für Cloud-ERP und CRM in der Schweiz erklärt. Einen Vergleich von BTP-Entwicklungspartnern finden Sie in Die besten SAP-BTP-Entwicklungspartner in der Schweiz.

Bereit, Ihre SAP Sales Cloud V2 zu erweitern? Sprechen Sie mit unserem SSCV2-Extension-Team. Wir definieren gemeinsam, was möglich ist.