SAP BTP Cockpit: Konfiguration und Administration

Das SAP BTP Cockpit ist die zentrale Administrationsoberfläche der SAP Business Technology Platform. Eine sauber angelegte Struktur aus Global Account, Directories, Subaccounts, Entitlements, Rollen und Destinations reduziert späteren Umbauaufwand erheblich. Dieser Guide beschreibt die Konfiguration in der Reihenfolge, in der sie in regulierten Umgebungen umgesetzt wird.

Funktionsumfang des Cockpits

Im Cockpit administrierbar:

• Account-Struktur: Global Account, Directories, Subaccounts
• Entitlements und Quotas: welcher Subaccount welchen Service in welchem Plan nutzen darf
• Service-Instanzen und Subscriptions, etwa SAP Build, Integration Suite, SAP Analytics Cloud
• Umgebungen: Cloud Foundry Spaces, Kyma, ABAP Environment
• Security: Trust Configuration über SAML oder OIDC, Role Collections, Rollenzuweisungen
• Connectivity: Destinations und Cloud Connector-Anbindung
• Monitoring, Audit Logs, Kosten- und Nutzungsberichte

Nicht Aufgabe des Cockpits: wiederholbare Automatisierung. Dafür gelten btp CLI, cf CLI und Terraform. Das Cockpit dient der Analyse, der Prüfung und Einmal-Einstellungen.

1. Account-Modell festlegen

Die Hierarchie lautet: Global Account, optional Directory, Subaccount, Environment als Cloud Foundry Space, Kyma oder ABAP.

Ebene	Zweck
Global Account	Vertrag, Gesamt-Quota, Kostenstelle
Directory	Fachbereich oder Produktlinie, Entitlement-Vererbung
Subaccount	genau eine Stage einer Anwendung (DEV, QA, PROD)
CF Space	technische Trennung von Deployments innerhalb der Stage

Zwei Festlegungen mit langfristiger Wirkung:

1. Ein Subaccount pro Stage, keine Mischung. Der Subaccount ist die Grenze für Region, Entitlements und Trust. Eine geteilte DEV/PROD-Umgebung lässt sich später nur per Migration trennen.
2. Region bewusst wählen. Die Region wird beim Anlegen fixiert und ist danach nicht änderbar. Bei Datenresidenz-Anforderungen ist das eine Compliance-Entscheidung.

Pfad im Cockpit: Global Account, Account Explorer, Create, Subaccount. Zu setzen sind Name, Subdomain, Region und Provider (Azure, AWS, GCP). Die Subdomain wird Teil aller Anwendungs-URLs und ist nach dem Anlegen fix.

2. Entitlements und Quotas verteilen

Ein Entitlement ist die Berechtigung, einen Service in einem bestimmten Service Plan zu nutzen. Ohne Entitlement ist der Service im Subaccount nicht sichtbar. Das ist die häufigste Ursache für einen fehlenden Service im Marketplace.

Pfad: Account Explorer, Subaccount, Entitlements, Configure Entitlements, Add Service Plans.

• Quotas knapp vergeben und bei Bedarf erhöhen. Unbegrenzte Quotas in DEV erzeugen unkontrollierte Kosten.
• Directories mit Entitlement Distribution nutzen, wenn mehrere Subaccounts denselben Service benötigen. Die Verteilung erfolgt dann einmalig auf Directory-Ebene.
• Vor Projektstart prüfen, ob der Plan im Vertrag (CPEA oder Subscription) enthalten ist.

CLI-Äquivalent:

btp assign accounts/entitlement \
  --to-subaccount <subaccount-id> \
  --for-service integrationsuite \
  --plan enterprise_agreement \
  --amount 1

3. Umgebung aktivieren

Cloud Foundry: Subaccount, Cloud Foundry, Enable Cloud Foundry. Der Org-Name folgt dem Subaccount, etwa zmd-crm-prod. Danach Spaces anlegen.

cf login -a https://api.cf.eu20.hana.ondemand.com
cf create-space app --org zmd-crm-prod
cf spaces

Kyma: Subaccount, Kyma Environment, Enable Kyma. Provisionierung dauert 20 bis 40 Minuten, der Quota-Verbrauch liegt deutlich über Cloud Foundry. ABAP-Entwicklung erfordert das Entitlement abap im Plan standard.

4. Security: Trust, Role Collections, Rollen

Dieser Bereich ist Prüfgegenstand in Audits.

Trust Configuration. Standard ist der SAP ID Service. Im Unternehmenskontext wird der eigene Identity Provider eingebunden: Subaccount, Security, Trust Configuration, Establish Trust für SAML 2.0, oder über SAP Cloud Identity Services (IAS) als Proxy zu Entra ID. IAS als Zwischenschicht liefert Conditional Access, risikobasierte Authentifizierung und ein einheitliches User-Mapping über alle Subaccounts.

Role Collections. Einzelrollenzuweisung skaliert nicht. Role Collections werden pro Funktion definiert, etwa APP_VIEWER, APP_ADMIN, INTEGRATION_DEVELOPER, und auf Gruppen aus dem Identity Provider gemappt, nicht auf einzelne E-Mail-Adressen.

Pfad: Security, Role Collections, Create, Roles hinzufügen, User Groups mit IdP-Gruppennamen belegen.

btp assign security/role-collection "Subaccount Administrator" \
  --to-user admin@example.com \
  --of-idp <origin-key>

Least Privilege. Die Rolle Subaccount Administrator ist kein Entwicklerprofil. Entwickler benötigen in PROD in der Regel keinen Cockpit-Zugriff, sondern Lesezugriff auf Audit Logs und Deployment über die Pipeline mit Service Key oder X.509 statt persönlichem Account.

5. Connectivity: Destinations und Cloud Connector

Destinations kapseln Zieladresse und Authentifizierung, damit keine Credentials im Anwendungscode liegen.

Pfad: Subaccount, Connectivity, Destinations, New Destination.

Konfiguration für ein On-Premise-S/4HANA-System über den Cloud Connector:

Feld	Wert
Name	S4H_PROD
Type	HTTP
URL	http://s4h-virtual:44300 (virtueller Host aus dem Cloud Connector)
Proxy Type	OnPremise
Authentication	PrincipalPropagation oder OAuth2SAMLBearerAssertion

Regelmäßig benötigte Properties: sap-client, HTML5.DynamicDestination=true für UI5-Anwendungen, WebIDEEnabled=true für das Business Application Studio.

Im Cloud Connector wird der virtuelle auf den internen Host gemappt. Freigegeben werden ausschließlich die benötigten Ressourcenpfade, kein /. Die Verbindung erfolgt über Subaccount-ID und Region. Für PROD gilt ein HA-Setup aus Master und Shadow.

6. Monitoring, Audit Log, Kosten

• Subaccount, Audit Log Viewer: die Standard-Retention ist kurz. In regulierten Branchen erfolgt der Export per Audit Log Retrieval API in ein SIEM.
• Global Account, Cost and Usage sowie Usage Analytics: monatliche Kontrolle je Subaccount, Alerts auf CPEA-Verbrauch.
• Alert Notification Service für technische Ereignisse aus Cloud Foundry und Kyma.

7. Zustand reproduzierbar machen

Nach Fertigstellung der Struktur wird sie in Code überführt. Neue Stages entstehen dann in Minuten, und der Soll-Zustand ist auditierbar lesbar.

resource "btp_subaccount" "dev" {
  name      = "crm-dev"
  subdomain = "acme-crm-dev"
  region    = "eu20"
}

resource "btp_subaccount_entitlement" "integration" {
  subaccount_id = btp_subaccount.dev.id
  service_name  = "integrationsuite"
  plan_name     = "enterprise_agreement"
}

Der offizielle Terraform Provider für SAP BTP deckt Subaccounts, Entitlements, Environments, Role Collections und Service-Instanzen ab. Nicht abgedeckte Details, etwa einzelne Destination-Felder, werden über btp CLI im gleichen Repository skriptet und versioniert.

Fehlerbilder und Ursachen

Symptom	Ursache
Service im Marketplace nicht sichtbar	fehlendes Entitlement oder Quota 0 im Subaccount
"Insufficient authorization" trotz Rolle	Role Collection zugewiesen, Nutzer hat sich danach nicht neu angemeldet
Destination-Test mit HTTP 503	Cloud Connector nicht verbunden oder virtueller Host nicht gemappt
Falsche Region im Subaccount	Region nicht änderbar, Subaccount neu anlegen und migrieren
Unerwartete Kosten in DEV	unlimitierte Quotas, laufende Kyma-Cluster ohne Abschaltfenster
Anwendungs-URL soll geändert werden	Subdomain nach dem Anlegen fix

Reihenfolge

1. Account-Modell und Namenskonvention dokumentieren
2. Directories und Subaccounts pro Stage anlegen, Region und Subdomain festlegen
3. Entitlements und Quotas verteilen
4. Umgebung aktivieren: CF Spaces, Kyma oder ABAP
5. Trust über IAS einrichten, Role Collections auf IdP-Gruppen mappen
6. Cloud Connector verbinden, Destinations mit Pfad-Whitelisting anlegen
7. Audit-Log-Export und Kosten-Alerts aktivieren
8. Gesamtzustand in Terraform und CLI-Skripte überführen

Bei dieser Reihenfolge bleibt das Cockpit Kontrollinstanz und ist nicht das Werkzeug für manuelle produktive Änderungen.