Was ist das SAP BTP Cockpit? Navigation, Konfiguration und Kostenkontrolle

Das SAP BTP Cockpit ist die browserbasierte Verwaltungsoberfläche der SAP Business Technology Platform. Hier verwalten Sie globale Konten, Verzeichnisse, Subaccounts, Entitlements, Benutzer und Kosten. Wer für eine BTP-Landschaft verantwortlich ist, erledigt den grössten Teil der Administration hier, und die Struktur, die Sie in den ersten Wochen wählen, begleitet Sie über Jahre. Als SAP BTP Partner in der Schweiz nutzen wir die Plattform, um S/4HANA Public Cloud mit Sales und Service Cloud V2 zu verbinden und Erweiterungen aus dem Kern herauszuhalten.

Dieser Leitfaden zeigt, wie das Cockpit aufgebaut ist, was die einzelnen Bereiche tun und mit welchen Konfigurationsmustern Sie die Fehler vermeiden, die wir in BTP-Projekten am häufigsten sehen.

Kurzfassung: Das SAP BTP Cockpit ist die Weboberfläche zur Administration von SAP BTP. Die Hierarchie besteht aus globalem Konto, optionalen Verzeichnissen und Subaccounts; Cloud-Foundry-Orgs und -Spaces liegen innerhalb der Umgebung eines Subaccounts. Drei Dinge entscheiden, ob das Cockpit übersichtlich bleibt: eine Namenskonvention und Verzeichnisstruktur ab dem ersten Tag, Trust zum Unternehmens-Identity-Provider mit eng gefassten Rollensammlungen und eine monatliche Prüfung von Entitlements und Verbrauch. Wiederkehrende Aufgaben erledigt die btp CLI als Skript.

Was ist das BTP Cockpit und wie ist es aufgebaut?

Das Cockpit bildet das Kontenmodell von SAP BTP ab. Wenn Sie neu auf der Plattform sind, beginnen Sie mit was SAP BTP ist und wo es hingehört; dieser Beitrag setzt voraus, dass bereits ein Konto besteht.

Globales Konto. Die oberste Ebene, sie steht für Ihren SAP-Vertrag. Hier verwalten Sie Entitlements, Verbrauchsdaten und die Mitglieder des globalen Kontos. Sie erreichen es unter cockpit.btp.cloud.sap, das Sie zum regionalen Cockpit weiterleitet (für Europa emea.cockpit.btp.cloud.sap). SAP beschreibt die Anmeldung in der BTP-Dokumentation.

Verzeichnisse. Eine optionale Gruppierungsebene für Subaccounts, nach Geschäftsbereich, Projekt oder Region. Verzeichnisse lohnen sich ab etwa einem halben Dutzend Subaccounts. Ohne sie wird der Account Explorer zur langen, flachen Liste.

Subaccounts. Die eigentliche Arbeitseinheit. Jeder Subaccount hat seine eigene Region, eigene Entitlements und Benutzerzuordnungen sowie eine oder mehrere Laufzeitumgebungen: Cloud Foundry, Kyma oder ABAP. Die meisten Unternehmen legen getrennte Subaccounts für Entwicklung, Test und Produktion an.

Innerhalb der Umgebung. In einem Cloud-Foundry-Subaccount ist die Org in Spaces unterteilt, die Anwendungen oder Teams voneinander trennen. Spaces sind keine vierte Ebene der Cockpit-Hierarchie; sie gehören zur Cloud-Foundry-Umgebung eines Subaccounts.

Die Hierarchie lässt sich später nur mit Aufwand ändern: Anwendungen und Service-Instanzen zwischen Subaccounts zu verschieben heisst, sie neu zu deployen und zu konfigurieren. Es lohnt sich, die Struktur vor dem ersten Projekt festzulegen.

Wie navigieren Sie im Account Explorer?

Wenn Sie ein globales Konto öffnen, erscheint zuerst der Account Explorer. Er zeigt Verzeichnisse und Subaccounts mit ihrem Status. Von hier aus können Sie:

• Subaccounts anlegen und löschen und dabei Region, Umgebung und Beschreibung wählen
• Subaccounts in Verzeichnissen ordnen
• Details eines Subaccounts einsehen: Region, Infrastrukturanbieter (AWS, Azure oder Google Cloud), Subdomain und Tenant-ID
• erkennen, welche Subaccounts aktiv sind, gerade bereitgestellt werden oder gesperrt sind

Die Seitennavigation hängt davon ab, wo Sie sich befinden. Auf Ebene des globalen Kontos sehen Sie Entitlements, Verbrauchs- und Kosteninformationen sowie die Mitglieder des Kontos. In einem Subaccount finden Sie die Umgebung (Cloud Foundry oder Kyma), den Service Marketplace, Instanzen und Abonnements und die Sicherheitseinstellungen des Subaccounts.

Das häufigste Problem in bestehenden Landschaften ist kein technisches: Subaccounts ohne Namenskonvention. Sobald zehn davon «test», «dev2» und «project-x» heissen, weiss niemand mehr, was wo läuft. Eine Konvention wie {projekt}-{umgebung}-{region} kostet am ersten Tag nichts und erspart später viel Detektivarbeit.

Wie funktionieren Entitlements und der Service Marketplace?

Entitlements legen fest, welche Services und Pläne ein Subaccount nutzen darf und in welchem Umfang. Ihr globales Konto hält einen Pool an Entitlements gemäss Vertrag, und Sie verteilen diesen Pool auf die Subaccounts, ähnlich wie ein Budget.

Bewährte Muster:

• Service-Pläne: Die meisten Services bieten mehrere Pläne. Verwenden Sie für Entwicklung und Test den kleinsten passenden Plan und den produktionstauglichen Plan nur dort, wo er nötig ist.
• Kontingente: Manche Pläne haben zahlenmässige Kontingente, etwa den Laufzeitspeicher in Cloud Foundry. Behalten Sie diese im Blick, damit ein Deployment nicht an einem Limit scheitert.
• Automatische Zuweisung: Verzeichnisse können neuen Subaccounts Entitlements automatisch zuweisen. Das erspart die manuelle Einrichtung jeder neuen Umgebung.

Der Service Marketplace ist der Katalog innerhalb eines Subaccounts. Er listet die Services, die Ihre Entitlements erlauben, und lässt Sie Instanzen oder Abonnements anlegen. Typische Einträge sind SAP HANA Cloud, SAP Integration Suite, SAP Build, der Destination- und der Connectivity-Service sowie Authorization and Trust Management (XSUAA). Wie diese Services zusammenspielen, erklären wir in den fünf Säulen von SAP BTP.

Wie verwalten Sie Sicherheit und Benutzerzugriffe?

Sicherheit ist der Teil des Cockpits, der am häufigsten in Eile eingerichtet und danach nicht mehr angefasst wird. Sie wirkt auf zwei Ebenen, beide beschreibt SAP im Leitfaden zur Sicherheitsadministration.

Trust-Konfiguration. Verbindet einen Identity Provider mit BTP. Voreingestellt ist der SAP ID Service. Für alles, was über einen ersten Test hinausgeht, empfiehlt SAP, SAP Cloud Identity Services (Identity Authentication) anzubinden und darüber Ihren Unternehmens-Identity-Provider wie Microsoft Entra ID oder Okta weiterzuleiten. So erhalten Sie Single Sign-on und verwalten den Benutzerlebenszyklus an einem Ort.

Rollensammlungen. Gruppen von Rollen, die Sie Benutzern oder Gruppen aus dem Identity Provider zuweisen. BTP liefert vordefinierte Rollensammlungen wie Subaccount Administrator, und Sie können eigene anlegen. Bewährt hat sich: Rollensammlungen, die Teamrollen abbilden, nicht einzelne Berechtigungen für einzelne Personen.

Fehler, die wir regelmässig sehen:

• Alle erhalten Subaccount Administrator statt einer eingeschränkten Rollensammlung. Das erschwert Audits und die Analyse von Vorfällen erheblich.
• Die Produktion läuft auf dem voreingestellten SAP ID Service statt auf dem Unternehmens-Identity-Provider.
• Trust wird in einem Subaccount konfiguriert und dann stillschweigend für alle angenommen. Die Trust-Konfiguration gilt pro Subaccount, jeder braucht seine eigene.

Wie überwachen Sie Kosten im Cockpit?

Auf Ebene des globalen Kontos zeigt das Cockpit Verbrauch und Kosten über das ganze Konto. SAP erklärt die Ansichten unter Monitoring von Nutzung und Verbrauchskosten. Sie sehen:

• den Verbrauch gegenüber Ihrem Vertrag, zum Beispiel Cloud Credits
• eine Aufschlüsselung pro Service und pro Subaccount
• den Verlauf über die Zeit; die Daten werden täglich aktualisiert, nicht in Echtzeit

Praktische Muster:

1. Monatlich prüfen. Eine feste monatliche Durchsicht erkennt Trends, bevor sie zum Budgetproblem werden.
2. Sprüngen nachgehen. Eine brauchbare Faustregel: Steigen die Kosten eines Services von einem Monat zum nächsten um rund ein Fünftel oder mehr, klären Sie die Ursache. Typisch sind vergessene Testinstanzen, eine überdimensionierte SAP-HANA-Cloud-Instanz oder Entwicklungsumgebungen, die niemand abgeschaltet hat.
3. Umgebungen richtig dimensionieren. Entwicklung und Test brauchen selten produktionstaugliche Pläne.
4. Ungenutzte Services aufräumen. Instanzen, die niemand nutzt, binden trotzdem Kontingent und kosten unter Umständen Geld. Für die meisten Landschaften genügt ein Audit pro Quartal.

Was ist der Unterschied zwischen Cockpit und btp CLI?

Das Cockpit ist die grafische Oberfläche: gut zum Erkunden, für einmalige Konfigurationen und die visuelle Kostenüberwachung. Die btp CLI (Befehl btp) deckt dieselbe Kontenverwaltung über die Kommandozeile ab; SAP pflegt eine vollständige Befehlsreferenz.

Aufgabe	Cockpit	btp CLI
Ersteinrichtung und Erkundung	Erste Wahl	Steilere Lernkurve
Wiederkehrende Konfiguration	Langsam, viele Klicks	Einmal skripten, beliebig oft ausführen
CI/CD-Pipelines	Nicht geeignet	Dafür gemacht
Kostenüberwachung	Visuelle Ansichten	Ausgabe für eigenes Reporting
Benutzer- und Rollenverwaltung	Am einfachsten für kleine Teams	Besser für Massenänderungen
Nachvollziehbarkeit	Begrenzt	Skripte lassen sich versionieren und prüfen

Für die meisten Teams gilt beides: das Cockpit für Überwachung und gelegentliche Aufgaben, die CLI für alles, was sich wiederholt oder automatisiert werden soll. In unseren BTP-Projekten skripten wir Subaccount-Einrichtung und Entitlements von Beginn an, denn die zweite und dritte Umgebung dauern dann Minuten statt eines Nachmittags voller Klicks.

Wer sollte Ihre BTP-Landschaft betreuen?

Das Cockpit ist nur die Verwaltungsoberfläche; entscheidend ist die Landschaft dahinter: die Erweiterungen, Integrationen und Datenflüsse zwischen Ihrem ERP und Ihren CX-Anwendungen. Bei Spadoom betreut ein Team S/4HANA Public Cloud, die SAP-CX-Anwendungen und die BTP-Schicht dazwischen. Deshalb richten wir Kontenstruktur, Trust und Kostenkontrolle als Teil der Architektur ein und nicht im Nachhinein. Warum das wichtig ist, lesen Sie unter ein Partner für Cloud ERP und CRM; wie sich BTP-Entwicklungspartner in der Schweiz unterscheiden, zeigt unsere Übersicht der SAP-BTP-Entwicklungspartner.

Wenn Ihr Cockpit schneller gewachsen ist als seine Struktur, sprechen Sie mit uns: Eine Prüfung von Hierarchie, Trust und Entitlements ist meist eine Sache von Tagen.

FAQ

Wie greife ich auf das SAP BTP Cockpit zu?

Öffnen Sie cockpit.btp.cloud.sap und melden Sie sich an; Sie werden zum regionalen Cockpit weitergeleitet, für Europa etwa emea.cockpit.btp.cloud.sap. Danach sehen Sie alle globalen Konten, in denen Sie Mitglied sind. Benutzer ohne Mitgliedschaft in einem globalen Konto sehen diese Auswahl nicht.

Kann ich mehrere Umgebungen über ein Cockpit verwalten?

Ja. Jeder Subaccount kann Cloud Foundry, Kyma oder die ABAP-Umgebung aktivieren, und das Cockpit verwaltet alle davon. Die Navigation passt sich der Umgebung des geöffneten Subaccounts an: Ein Cloud-Foundry-Subaccount zeigt Orgs und Spaces, ein Kyma-Subaccount das Kyma-Dashboard.

Wie oft werden die Verbrauchsdaten aktualisiert?

Verbrauchs- und Kostendaten im globalen Konto werden täglich aktualisiert, es ist also keine Echtzeitansicht. Den aktuellen Stand eines Deployments prüfen Sie direkt bei den Service-Instanzen und Anwendungen im Subaccount.

Was passiert, wenn die Entitlements aufgebraucht sind?

Sie können für diesen Plan keine weiteren Service-Instanzen anlegen, bis Sie Kontingent freigeben (etwa durch Löschen ungenutzter Instanzen oder Umverteilen zwischen Subaccounts) oder bei SAP zusätzliche Kapazität kaufen. Kontingente werden pro Subaccount zugewiesen; prüfen Sie deshalb die Verteilung, bevor Sie nachbestellen.

Soll ich den SAP ID Service oder unseren eigenen Identity Provider verwenden?

Der SAP ID Service ist die Voreinstellung und genügt für eine erste Einrichtung oder einen persönlichen Test. Für gemeinsam genutzte Entwicklungs-, Test- und Produktions-Subaccounts binden Sie SAP Cloud Identity Services (Identity Authentication) an und lassen es Ihren Unternehmens-Identity-Provider wie Microsoft Entra ID oder Okta weiterleiten. So erhalten Sie Single Sign-on und verwalten den Benutzerlebenszyklus an einem Ort.