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 — und genau dort haben wir in den letzten drei Jahren produktive Erweiterungen für mehrere Mandanten und Branchen gebaut.

TL;DR: 35 % der SAP-BTP-Nutzer setzen die Plattform ein, um SAP-Anwendungen zu erweitern und gleichzeitig einen Clean Core zu bewahren (ASUG, 2025). Wir haben SSCV2-Erweiterungen in 4 Patterns produktiv ausgeliefert — HTML Mashups, Custom OData Services, Event-Driven Webhooks und API-Integration — basierend auf einer Drei-App-Cloud-Foundry-Architektur, die in Wochen deployed wird. Hier erfahren Sie im Detail, wie jedes Pattern funktioniert — inklusive Stolpersteine aus der Produktion.

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

Schätzungen zufolge verfehlen 20–70 % der CRM-Projekte die Erwartungen — hauptsächlich wegen mangelnder Benutzerakzeptanz und der Lücke zwischen dem, was ein CRM mitliefert, und dem, was Anwender tatsächlich brauchen (CRM.org, 2026). 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. Warum ist das relevant? Weil die Frage nicht lautet, ob Sie Erweiterungen brauchen. Die Frage ist, 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-Core zu verändern (was SAP im Rahmen der Clean Core-Strategie ausdrücklich davon abrät), deployen Sie unabhängige Cloud Foundry-Applikationen, die über APIs, Events und UI-Embedding mit SSCV2 kommunizieren.

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

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, ohne das System zu wechseln.

Weiteres Beispiel: Unser Besuchsplaner für OPO Oeschger bettet eine vollständige Drag-and-Drop-Wochenplanungsoberfläche in SSCV2 ein. Ein KI-Scoring-Algorithmus bewertet über 100 Konten pro Vertriebsmitarbeiter, gewichtet nach überfälligen Besuchen (40 %), ABC-Klassifikation (30 %), Besuchskadenz (20 %) und geografischer Clusterung (10 %). Der Mitarbeiter zieht vorgeschlagene Besuche auf 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 eintauchen — 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 — es handelt sich um Server-zu-Server-Kommunikation ohne Benutzerkontext. SSCV2 wiederholt fehlgeschlagene Webhooks mit exponentiellem Backoff, daher muss Ihr Handler idempotent sein.

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?

Unternehmen, die CRM effektiv einsetzen, verzeichnen eine 29%ige Steigerung des Umsatzes und eine 34%ige Verbesserung der Vertriebsproduktivität (CRM.org, 2026). Doch diese Gewinne hängen davon ab, dass Ihr CRM die richtigen Daten 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:

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?

Die grösste Hürde für die BTP-Adoption bleibt die Kompetenzlücke — 46 % der Organisationen nennen sie als grösste Herausforderung, gefolgt von Entwicklungskomplexität mit 43 % (Precisely 2026 SAP Trends Survey). Authentifizierung und Mandantenfähigkeit sind genau dort, wo sich diese Komplexität bündelt. Hier ist, worauf wir uns nach dem Deployment über mehrere Mandanten hinweg festgelegt haben:

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 nahtloses 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 — wir liefern Produktivcode.

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 Sales Cloud V2 interagieren kann. So automatisieren wir Tenant-Setup, testen API-Verhalten und prototypisieren neue Erweiterungsideen schneller als jeder mit einer Postman Collection.

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 über 100 Konten pro Vertriebsmitarbeiter und Woche zu priorisieren, 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-Core anzufassen. 35 % der BTP-Nutzer verwenden diesen Clean Core Extension-Ansatz (ASUG, 2025).

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?

Ein einfaches HTML Mashup: 1–2 Wochen. Custom OData Service mit CRUD: 3–6 Wochen. Komplexe Multi-Pattern-Erweiterungen wie CTI oder Besuchsplanung: 2–4 Monate je nach Umfang.

Unterstützt Spadoom mandantenfähige Deployments?

Jede Erweiterung, die wir bauen, unterstützt mandantenfähiges Deployment mit isolierten BTP-Subaccounts pro Kunde. Dieselbe Codebasis, umgebungsbasierte Konfiguration, unabhängige Infrastruktur.

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 — Lebensmittelvertrieb, Baumaterialien, Finanzdienstleistungen — und die Patterns zu einer wiederholbaren Architektur destilliert, die in Wochen statt Monaten deployed wird. Ob Sie von C4C migrieren oder eine frische SSCV2-Instanz erweitern — der Ansatz ist derselbe.

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