Probleme im SAP BTP Cockpit: fünf Fälle und ihre Lösung

Wenn das SAP BTP Cockpit Ihnen Fehler entgegenwirft, ist es wahrscheinlich eine von fünf Ursachen. Ein 401 bei einem Service-Schlüssel liegt fast immer an der OAuth-Anfrage, nicht an den Zugangsdaten. Ein Internal Server Error in der Integration Suite bedeutet meist fehlende Rollensammlungen oder eine veraltete Sitzung. Tote Links stammen von Boostern, die eingerichtet wurden, bevor sich der Subaccount änderte. CAP-Destination-Fehler sind meist ein Namenskonflikt oder eine fehlende Bindung. Und eine App, die gestern in einem Trial-Account lief, kann über Nacht ihre Datenbank verloren haben. Dieser Leitfaden richtet sich an Entwickler und Integrationsberater, die in Cloud-Foundry-Subaccounts arbeiten. Die Triage-Tabelle unten sagt Ihnen, was Sie zuerst prüfen.

Als ich zum ersten Mal das rote Fehlerbanner im SAP BTP Cockpit sah, nahm ich an, ich hätte etwas falsch gemacht. Falscher Link, abgelaufene Sitzung.

Nach dem dritten oder vierten Mal war klar, dass es nicht nur an mir lag.

In den folgenden Wochen führte ich ein Notizbuch und schrieb jedes Mal auf, wenn etwas kaputtging. Internal Server Errors beim Öffnen der Integration Suite. Destinations, die gültig aussahen und die Verbindung verweigerten. Apps, die gestern liefen und heute hingen. Es zeigten sich Muster. Wenige davon waren irgendwo brauchbar dokumentiert, und das Cockpit selbst liefert kaum etwas, womit man arbeiten kann.

Symptom	Wahrscheinlichste Ursache	Zuerst prüfen
401 Unauthorized beim Aufruf einer API mit einem Service-Schlüssel	Falscher Grant-Typ, falsche Token-URL oder fehlende Authorities	Token dekodieren und aud sowie scope lesen
Internal Server Error beim Öffnen der Integration Suite	Fehlende Rollensammlungen oder veraltete Sitzung	Rollensammlungen Ihres Benutzers, dann vollständig abmelden
Booster oder Kachel öffnet eine leere oder falsche Seite	Subaccount wurde nach dem Lauf des Boosters geändert	Stattdessen über den Cockpit-Baum navigieren
CAP-App: „destination not found“ oder Authentifizierungsfehler	Namenskonflikt, fehlende Bindung, falsche OData-Art	cds.requires und xs-app.json gegen den Namen im Cockpit abgleichen
App lief gestern, hängt heute (Trial)	HANA-Cloud-Instanz wurde über Nacht gestoppt	Status der Datenbankinstanz in SAP HANA Cloud Central

Cloud Foundry, Kyma und die ABAP-Umgebung laufen auf der Multi-Cloud-Grundlage von SAP, die für Neukunden seit 2020 der Standard ist. Die ältere Neo-Umgebung erhält nur noch Sicherheits- und Compliance-Updates, und SAP hat ihr Auslaufen auf den 31. Dezember 2028 festgelegt. Fast jedes der folgenden Probleme ist ein Cloud-Foundry-Problem.

Zwei Umbenennungen verwirren Leser älterer Anleitungen noch immer. Der SAP Launchpad Service wurde im Januar 2023 zu SAP Build Work Zone, Standard Edition. Und viele Kacheln und Booster wurden neu gebaut, als SAP Build wuchs, sodass Screenshots von 2022 oft nicht mehr zu dem passen, was Sie sehen.

Bei RISE with SAP kommt BTP meist als Berechtigung auf Credit-Basis im Vertrag. Das Cockpit ist dasselbe. Anders ist, wer in Ihrer Organisation den Global Account kontrolliert. Finden Sie diese Person, bevor Sie eine neue Berechtigung brauchen.

Sie legen eine Service-Instanz an, erzeugen einen Service-Schlüssel, kopieren Client-ID und Secret in Postman, tragen die Token-URL ein und senden die Anfrage. 401. Keine Details.

Sie kopieren das Secret erneut. Es schlägt weiter fehl. Der Service ist in Ordnung. Der OAuth-Ablauf nicht.

Was Sie der Reihe nach prüfen:

1. Grant-Typ. Der technische Zugriff auf die meisten BTP-Service-APIs nutzt client_credentials. Setzen Sie ihn in Postman ausdrücklich. Verlassen Sie sich nicht auf den Standardwert.
2. Token-URL. Übernehmen Sie sie aus dem Service-Schlüssel. Manche Schlüssel liefern eine tokenurl, andere die XSUAA-url, an die Sie /oauth/token anhängen. Leihen Sie sich nie eine aus einem anderen Subaccount.
3. Header. Senden Sie bei einem direkten Token-Aufruf Content-Type: application/x-www-form-urlencoded und Authorization: Basic <base64(clientid:clientsecret)>.
4. Authorities. Mit Client Credentials trägt das Token nur die Scopes, die dieser Service-Instanz gewährt wurden. Braucht die API eine Rolle, die die Instanz nicht hat, erhalten Sie trotzdem ein Token, und die API sagt trotzdem Nein. Beheben Sie das in den Instanzparametern (zum Beispiel den Rollen einer Instanz des Integration-Suite-API-Plans), nicht in der Anfrage.
5. Audience. Wenn Sie ein Token haben und die API es ablehnt, dekodieren Sie das Token und lesen Sie den Claim aud. Passt er nicht zur aufgerufenen API, verwenden Sie einen Schlüssel aus der falschen Service-Instanz.

Sie öffnen die Integration Suite und erhalten ein rotes Banner „Internal Server Error“. Kein Log. Neu laden, anderer Browser, gleiches Ergebnis.

Meist passiert es, nachdem der Service eine Weile ungenutzt blieb: morgens geöffnet, ein paar Stunden liegen gelassen, später wieder benutzt. Die Community-Threads und die Knowledge Base von SAP nennen zwei übliche Ursachen: fehlende Rollensammlungen und veraltete Sitzungen.

Was es meist behebt:

1. Rollensammlungen prüfen. Ihr Benutzer braucht Integration_Provisioner, um den Tenant einzurichten, und die passenden PI_-Rollensammlungen (Administrator, Integrationsentwickler, Fachexperte), um darin zu arbeiten. Weisen Sie sie im Subaccount unter Security zu.
2. Vollständig abmelden. Rollenänderungen erreichen Ihre Sitzung erst nach einer frischen Anmeldung. Schließen Sie jeden BTP- und Integration-Suite-Tab, melden Sie sich ab und dann wieder an.
3. Löschen Sie die Cookies für die BTP-Domains, wenn der Fehler eine frische Anmeldung übersteht. Ein veraltetes Sitzungs-Cookie kann die Sitzung überleben.
4. Nutzen Sie eine einzige Cockpit-Sitzung. Mehrere Tabs oder Browserprofile auf demselben Subaccount verursachen Sitzungskonflikte, die genau wie dieser Fehler aussehen.

Das eigentliche Problem ist die Sichtbarkeit. Das Cockpit sagt Ihnen nichts darüber, was fehlgeschlagen ist, also raten Sie am Ende. Arbeiten Sie stattdessen die Liste der Reihe nach ab. Einen weiteren Blick darauf, warum Integrationsprogramme ins Stocken geraten, bietet mein Beitrag zu Verzögerungen bei der SAP Integration Suite.

Sie klicken auf „Go to Application“ und erhalten einen leeren Bildschirm, eine generische Startseite oder eine Weiterleitung, die keinen Sinn ergibt.

Es folgt Mustern:

1. Booster-Links brechen, wenn sich die Subaccount-Einrichtung nach dem Lauf des Boosters ändert. Die Weiterleitung zeigt auf etwas, das nicht mehr existiert.
2. Kacheln der Integration Suite funktionieren mal, liefern mal Fehler, laufen mal in ein Timeout, meist aus den oben genannten Sitzungsgründen.
3. Links in SAP Build Work Zone zeigen „connection denied“, wenn die Subskription existiert, Ihrem Benutzer aber die Rollensammlung für die Site fehlt.
4. Mehrere Tabs oder Browserprofile öffnen Links in abgelaufenen Kontexten.

Was funktioniert: Navigieren Sie über den Cockpit-Baum (Subaccount, dann Services, dann Instances and Subscriptions) und legen Sie Lesezeichen für die direkten URLs von Integration Suite, Destinations und Work Zone an. Nutzen Sie eine Sitzung in einem sauberen Browserprofil. Wenn ein Link jedes dritte Mal fehlschlägt, hören Sie auf, der Plattform zu vertrauen, und fangen an, Umgehungen zu bauen. Lesezeichen sind die billigste Umgehung, die es gibt. Wenn Sie sich noch zurechtfinden müssen, behandelt meine Einführung in das BTP Cockpit die grundlegende Navigation.

Sie stellen eine CAP-App bereit, konfigurieren eine Destination im Cockpit, und Anfragen scheitern trotzdem mit „destination not found“ oder Authentifizierungsfehlern. Die Destination ist aufgelistet. Die App läuft. Die Fehlermeldungen führen nirgendwohin.

Die CAP-Dokumentation von SAP ist klar darin, wie das verdrahtet sein soll: Der Remote-Service wird unter cds.requires in der package.json (oder .cdsrc.json) mit einem kind deklariert, und der Destination-Name steht unter credentials.destination. Die App braucht außerdem Bindungen sowohl an den Destination-Service als auch an XSUAA. Die meisten Fehler sind ein Bruch irgendwo in dieser Kette.

1. 01cds.requiresDeklariert den Remote-Service, seine Art und den Destination-Namen
2. 02ProduktionsprofilEnthält nach dem Deployment die Zugangsdaten der Destination
3. 03Service-BindungenDie App ist an Destination und XSUAA gebunden
4. 04Destination im CockpitDerselbe Name wie in cds.requires und xs-app.json, Groß- und Kleinschreibung eingeschlossen
5. 05Remote-Serviceodata-v2 für einen V2-Service, odata für V4

Anfragen erreichen den Remote-Service

Symptom	Lösung
Destination ist aufgelistet, aber die App findet sie nicht	Vergleichen Sie den Namen in cds.requires und in den Routen der xs-app.json mit dem Cockpit, Zeichen für Zeichen, einschließlich Groß- und Kleinschreibung
Läuft lokal, scheitert nach dem Deployment	Prüfen Sie, ob das Profil [production] tatsächlich die Zugangsdaten der Destination enthält und die App an Destination und XSUAA gebunden ist
Remote-OData-V2-Service liefert Fehler	Setzen Sie kind auf odata-v2 für einen V2-Service und auf odata für V4. Nutzen Sie V4, wo immer beide Seiten es zulassen
Eine UI5-App braucht V2, Ihr CAP-Service ist aber V4	Fügen Sie das Plugin @cap-js-community/odata-v2-adapter hinzu. Der ältere @sap/cds-odata-v2-adapter-proxy ist veraltet
Authentifizierung scheitert trotz gültiger Zugangsdaten	Beginnen Sie mit OAuth2ClientCredentials oder BasicAuthentication. Nutzen Sie SAML oder Principal Propagation nur, wenn das Szenario es verlangt
Unklar, ob das Ziel überhaupt erreichbar ist	Nutzen Sie „Check Connection“ an der Destination im Cockpit, bevor Sie die App debuggen

Teams, die das gut handhaben, führen pro App eine kurze Destination-Checkliste. Nicht, weil die Einrichtung komplex wäre. Sondern weil eine falsche Annahme zu Name, Bindung oder OData-Art stillschweigend scheitert und viel länger zu finden als zu verhindern ist.

Eine CAP-App, die gestern lief, hängt jetzt. Kein Fehler. Das Cockpit zeigt sie als laufend. Sie starten sie neu. Nichts.

Prüfen Sie zuerst die Datenbank. Das Trial-Tutorial zu HANA Cloud von SAP selbst besagt, dass Free-Tier-Instanzen jede Nacht gestoppt werden und an jedem Arbeitstag neu gestartet werden müssen. Der Trial-Account selbst hält bis zu 90 Tage, wenn Sie sich regelmäßig anmelden. Ihre App ist in Ordnung. Ihre Datenbank schläft.

Was hilft:

1. Starten Sie die HANA-Cloud-Instanz in SAP HANA Cloud Central neu, bevor Sie mit dem Debuggen von Code beginnen.
2. Nutzen Sie die CLI (cf apps, cf services), um Speicher- und Service-Nutzung zu sehen. Die Cockpit-Oberfläche zeigt weit weniger.
3. Löschen Sie ungenutzte Service-Instanzen, bevor Sie neue anlegen. Trial-Kontingente gelten für den gesamten Account, nicht nur für eine App.
4. Halten Sie Demo- und Test-Workloads in getrennten Subaccounts.

Wenn Sie mehr als eine App und Datenbank zuverlässig betreiben oder stabile Verfügbarkeit für Demos brauchen, wechseln Sie in einen produktiven Account. Free-Tier-Pläne in einem produktiven Account lassen sich ohne Verlust Ihrer Arbeit auf kostenpflichtig hochstufen, was bei einem Trial-Account nicht geht.

Warum erhalte ich einen 401-Fehler mit Zugangsdaten aus dem SAP-BTP-Service-Schlüssel, obwohl sie korrekt aussehen?

Fast immer liegt es an der OAuth-Anfrage, nicht an den Zugangsdaten. Die üblichen Ursachen sind der falsche Grant-Typ (nutzen Sie client_credentials für technischen Zugriff), eine Token-URL, die nicht zum Service-Schlüssel passt, oder falsche Header beim Token-Aufruf.

Wenn Sie ein Token erhalten und die API es trotzdem ablehnt, dekodieren Sie es. Prüfen Sie, ob der Claim aud zur API passt, und prüfen Sie die Scopes. Bei Client Credentials stammen die Scopes aus den Authorities, die der Service-Instanz gewährt wurden. Beheben Sie fehlende Rollen daher in den Instanzparametern.

Was verursacht Internal Server Errors beim Öffnen der Integration Suite im BTP Cockpit?

Meist fehlende Rollensammlungen oder eine veraltete Sitzung. Stellen Sie sicher, dass Ihr Benutzer Integration_Provisioner und die benötigten PI_-Rollensammlungen hat. Schließen Sie dann jeden BTP-Tab, melden Sie sich ab und wieder an, denn neue Rollen gelten erst nach einer frischen Anmeldung.

Besteht der Fehler weiter, löschen Sie die Cookies für die BTP-Domains und bleiben Sie bei einer einzigen Cockpit-Sitzung. Mehrere Tabs auf demselben Subaccount lösen denselben Fehler aus.

Warum verbindet sich meine CAP-App nicht mit einer Destination, die im Cockpit korrekt erscheint?

Meist ein Namenskonflikt. Der Destination-Name in cds.requires und in den Routen Ihrer xs-app.json muss exakt mit dem Cockpit übereinstimmen, einschließlich Groß- und Kleinschreibung.

Stimmt der Name, prüfen Sie, ob die App sowohl an den Destination-Service als auch an XSUAA gebunden ist, ob das Profil [production] die Zugangsdaten trägt und ob kind zum Remote-Service passt: odata-v2 für V2, odata für V4. Mit „Check Connection“ im Cockpit bestätigen Sie, dass das Ziel erreichbar ist.

Warum funktioniert meine SAP-BTP-Trial-App über Nacht nicht mehr?

In Trial- und Free-Tier-Plänen werden SAP-HANA-Cloud-Instanzen jede Nacht gestoppt, um Ressourcen zu sparen. Ihre App läuft weiter, erreicht aber ihre Datenbank nicht. Starten Sie die Instanz in SAP HANA Cloud Central an jedem Arbeitstag neu, bevor Sie loslegen.

Prüfen Sie mit cf apps und cf services Speicher- und Service-Nutzung, denn Trial-Kontingente sind im Cockpit schwer zu sehen. Löschen Sie ungenutzte Instanzen, bevor Sie neue anlegen.

Warum führen Links in Boostern und Kacheln auf leere Seiten?

Booster-Links brechen, wenn sich die Subaccount-Struktur nach dem Lauf des Boosters ändert. Die Weiterleitung zeigt auf einen Ort, der nicht mehr existiert oder nie vollständig konfiguriert wurde.

Navigieren Sie stattdessen über den Cockpit-Baum und legen Sie Lesezeichen für direkte URLs von Integration Suite, Destinations und SAP Build Work Zone an. Verlassen Sie sich bei allem, was Sie täglich nutzen, nicht auf die von Boostern erzeugte Navigation.

Wann sollte ich von einem BTP-Trial-Account auf einen kostenpflichtigen Plan wechseln?

Wenn die Grenzen anfangen, Sie Zeit zu kosten. Wenn Sie mehr als eine App oder Datenbank betreiben oder stabile Verfügbarkeit für Demos oder Tests brauchen, verursacht der Trial mehr Reibung, als er spart.

Die wichtigsten Gewinne sind Stabilität und bessere Sichtbarkeit der Ressourcen, nicht neue Funktionen. Ein produktiver Account mit Free-Tier-Plänen ist ein guter Zwischenschritt: Sie können diese Pläne später auf kostenpflichtig hochstufen, ohne etwas neu aufzubauen.