SAP BTP Cockpit-problemen: vijf kwesties en hoe u ze oplost

Gooit de SAP BTP Cockpit fouten naar u toe, dan is het waarschijnlijk een van vijf dingen. Een 401 van een service key is bijna altijd het OAuth-verzoek, niet de inloggegevens. Een Internal Server Error in Integration Suite betekent meestal ontbrekende role collections of een verouderde sessie. Dode links komen van boosters die zijn ingesteld voordat het subaccount veranderde. CAP-destinationfouten zijn meestal een naamverschil of een ontbrekende binding. En een app die gisteren werkte op een trial-account, kan 's nachts zijn database zijn kwijtgeraakt. Deze gids is voor ontwikkelaars en integratieconsultants die in Cloud Foundry-subaccounts werken. De triagetabel hieronder vertelt u wat u als eerste controleert.

De eerste keer dat ik de rode foutbanner in de SAP BTP Cockpit zag, nam ik aan dat ik iets verkeerd had gedaan. Verkeerde link, verlopen sessie.

Na de derde of vierde keer was duidelijk dat het niet alleen mij overkwam.

In de weken daarna hield ik een notitieboekje bij waarin ik opschreef wanneer er iets stukging. Internal Server Errors bij het openen van Integration Suite. Destinations die er geldig uitzagen en toch geen verbinding wilden maken. Apps die gisteren werkten en vandaag vastliepen. Er ontstonden patronen. Weinig ervan stond ergens bruikbaar gedocumenteerd, en de Cockpit zelf geeft u bijna niets om mee te werken.

Symptoom	Meest waarschijnlijke oorzaak	Controleer eerst
401 Unauthorized bij het aanroepen van een API met een service key	Verkeerd grant type, verkeerde token-URL of ontbrekende authorities	Decodeer het token en lees aud en scope
Internal Server Error bij het openen van Integration Suite	Ontbrekende role collections of verouderde sessie	Role collections van uw gebruiker, daarna volledig uitloggen
Booster of tegel opent een lege of verkeerde pagina	Subaccount is veranderd nadat de booster liep	Navigeer in plaats daarvan via de Cockpit-boom
CAP-app: “destination not found” of authenticatiefouten	Naamverschil, ontbrekende binding, verkeerd OData-kind	cds.requires en xs-app.json naast de naam in de Cockpit
App werkte gisteren, hangt vandaag (trial)	HANA Cloud-instance 's nachts gestopt	Status van de database-instance in SAP HANA Cloud Central

Cloud Foundry, Kyma en de ABAP environment draaien op het multi-cloudfundament van SAP, dat sinds 2020 de standaard is voor nieuwe klanten. De oudere Neo-omgeving krijgt alleen nog beveiligings- en compliance-updates, en SAP heeft de uitfasering vastgesteld op 31 december 2028. Vrijwel elk probleem hieronder is een Cloud Foundry-probleem.

Twee hernoemingen verwarren nog steeds mensen die oudere gidsen lezen. SAP Launchpad service werd in januari 2023 SAP Build Work Zone, standard edition. En veel tegels en boosters zijn herbouwd naarmate SAP Build groeide, dus screenshots uit 2022 komen vaak niet meer overeen met wat u ziet.

Bij RISE with SAP komt BTP meestal als een creditgebaseerde entitlement binnen het contract. De Cockpit is hetzelfde. Wat verschilt is wie in uw organisatie het global account beheert, dus zoek die persoon op voordat u een nieuwe entitlement nodig hebt.

U maakt een service-instance aan, genereert een service key, kopieert de client-ID en het secret naar Postman, voegt de token-URL toe en verstuurt het verzoek. 401. Geen details.

U kopieert het secret opnieuw. Nog steeds mis. De service is in orde. De OAuth-flow niet.

Wat u controleert, in volgorde:

1. Grant type. Technische toegang tot de meeste BTP-service-API's gebruikt client_credentials. Stel dat expliciet in Postman in. Vertrouw niet op de standaardwaarde.
2. Token-URL. Neem hem over uit de service key. Sommige keys geven een tokenurl; andere geven de XSUAA-url, waaraan u /oauth/token toevoegt. Leen er nooit een van een ander subaccount.
3. Headers. Stuur bij een directe tokenaanroep Content-Type: application/x-www-form-urlencoded en Authorization: Basic <base64(clientid:clientsecret)>.
4. Authorities. Bij client credentials bevat het token alleen de scopes die aan die service-instance zijn toegekend. Heeft de API een rol nodig die de instance niet heeft, dan krijgt u toch een token en zegt de API toch nee. Los het op in de instanceparameters (bijvoorbeeld de rollen op een instance van het API-plan van Integration Suite), niet in het verzoek.
5. Audience. Hebt u een token en wijst de API het af, decodeer het token dan en lees de aud-claim. Komt die niet overeen met de API die u aanroept, dan gebruikt u een key van de verkeerde service-instance.

U opent Integration Suite en krijgt een rode banner “Internal Server Error”. Geen log. Herladen, andere browser, hetzelfde resultaat.

Het gebeurt meestal nadat de service een tijd ongebruikt is gebleven: 's ochtends geopend, een paar uur met rust gelaten, later weer gebruikt. De communitythreads en kennisbank van SAP wijzen op twee gebruikelijke oorzaken: ontbrekende role collections en verouderde sessies.

Wat het meestal oplost:

1. Controleer de role collections. Uw gebruiker heeft Integration_Provisioner nodig om de tenant in te richten en de relevante PI_-role collections (administrator, integration developer, business expert) om erin te werken. Wijs ze toe in het subaccount onder Security.
2. Log volledig uit. Rolwijzigingen bereiken uw sessie pas na een nieuwe aanmelding. Sluit elk BTP- en Integration Suite-tabblad, meld u af en meld u daarna opnieuw aan.
3. Wis de cookies voor de BTP-domeinen als de fout een nieuwe aanmelding overleeft. Een verouderde sessiecookie kan de sessie zelf overleven.
4. Gebruik één Cockpit-sessie. Meerdere tabbladen of browserprofielen op hetzelfde subaccount veroorzaken sessieconflicten die er precies zo uitzien als deze fout.

Het echte probleem is zichtbaarheid. De Cockpit vertelt u niets over wat er is mislukt, dus u gaat gokken. Loop in plaats daarvan de lijst in volgorde af. Voor een bredere blik op waarom integratieprogramma's vastlopen, zie mijn stuk over vertragingen bij de oplevering van SAP Integration Suite.

U klikt op “Go to Application” en krijgt een leeg scherm, een generieke landingspagina of een redirect die nergens op slaat.

Het volgt patronen:

1. Boosterlinks breken wanneer de subaccountinrichting verandert nadat de booster liep. De redirect wijst naar een plek die niet meer bestaat.
2. Integration Suite-tegels werken soms, geven soms een fout, lopen soms op een time-out, meestal om de sessieredenen hierboven.
3. Links naar SAP Build Work Zone tonen “connection denied” wanneer het abonnement bestaat maar uw gebruiker de role collection voor de site mist.
4. Meerdere tabbladen of browserprofielen openen links in verlopen contexten.

Wat werkt: navigeer via de Cockpit-boom (subaccount, dan Services, dan Instances and Subscriptions) en bewaar de directe URL's voor Integration Suite, destinations en Work Zone als bladwijzer. Gebruik één sessie in een schoon browserprofiel. Wanneer een link elke derde keer faalt, houdt u op het platform te vertrouwen en begint u omwegen te bouwen. Bladwijzers zijn de goedkoopste omweg die er is. Zoekt u nog uw weg, dan behandelt mijn rondleiding door de BTP Cockpit de basisnavigatie.

U deployt een CAP-app, configureert een destination in de Cockpit en verzoeken falen nog steeds met “destination not found” of authenticatiefouten. De destination staat in de lijst. De app draait. De foutmeldingen wijzen nergens bruikbaar naartoe.

De CAP-documentatie van SAP is duidelijk over hoe dit gekoppeld hoort te zijn: de remote service wordt gedeclareerd onder cds.requires in package.json (of .cdsrc.json) met een kind, en de destinationnaam komt onder credentials.destination. De app heeft ook bindings nodig met zowel de Destination-service als XSUAA. De meeste fouten zijn een breuk ergens in die keten.

1. 01cds.requiresDeclareert de remote service, het kind en de destinationnaam
2. 02ProductieprofielBevat de destination-inloggegevens na deployment
3. 03Service-bindingsDe app is gebonden aan Destination en XSUAA
4. 04Destination in de CockpitDezelfde naam als in cds.requires en xs-app.json, inclusief hoofdletters
5. 05Remote serviceodata-v2 voor een V2-service, odata voor V4

Verzoeken bereiken de remote service

Symptoom	Oplossing
Destination staat in de lijst maar de app vindt hem niet	Vergelijk de naam in cds.requires en in de routes van xs-app.json teken voor teken met de Cockpit, inclusief hoofdletters
Werkt lokaal, faalt na deployment	Controleer of het [production]-profiel de destination-inloggegevens echt bevat en of de app is gebonden aan Destination en XSUAA
Remote OData V2-service geeft fouten	Zet kind op odata-v2 voor een V2-service en op odata voor V4. Gebruik V4 waar beide kanten het toelaten
Een UI5-app heeft V2 nodig maar uw CAP-service is V4	Voeg de plugin @cap-js-community/odata-v2-adapter toe. De oudere @sap/cds-odata-v2-adapter-proxy is deprecated
Authenticatie faalt met geldige inloggegevens	Begin met OAuth2ClientCredentials of BasicAuthentication. Gebruik SAML of principal propagation alleen wanneer het scenario dat vraagt
Onzeker of het doel überhaupt bereikbaar is	Gebruik “Check Connection” op de destination in de Cockpit voordat u de app debugt

Teams die dit goed aanpakken, houden per app een korte destinationchecklist bij. Niet omdat de setup complex is. Maar omdat één verkeerde aanname over naam, binding of OData-kind stilletjes faalt en veel meer tijd kost om te vinden dan om te voorkomen.

Een CAP-app die gisteren werkte, hangt nu. Geen fout. De Cockpit toont dat hij draait. U herstart hem. Niets.

Controleer eerst de database. De eigen tutorial voor de HANA Cloud-trial van SAP stelt dat free-tier-instances elke nacht worden gestopt en elke dag dat u werkt opnieuw moeten worden gestart. Het trial-account zelf duurt maximaal 90 dagen als u regelmatig inlogt. Uw app is in orde. De database slaapt.

Wat helpt:

1. Herstart de HANA Cloud-instance vanuit SAP HANA Cloud Central voordat u code gaat debuggen.
2. Gebruik de CLI (cf apps, cf services) om geheugen- en servicegebruik te zien. De Cockpit-UI toont veel minder.
3. Verwijder ongebruikte service-instances voordat u nieuwe aanmaakt. Trialquota gelden voor het hele account, niet voor één app.
4. Houd demo- en testworkloads in aparte subaccounts.

Hebt u meer dan één app en database nodig die betrouwbaar draaien, of stabiele uptime voor demo's, stap dan over op een productief account. Free-tierplannen in een productief account kunnen worden opgewaardeerd naar betaald zonder dat u uw werk kwijtraakt, wat met een trial-account niet kan.

Waarom krijg ik een 401-fout met SAP BTP service key-inloggegevens terwijl ze er correct uitzien?

Bijna altijd het OAuth-verzoek, niet de inloggegevens. De gebruikelijke oorzaken zijn het verkeerde grant type (gebruik client_credentials voor technische toegang), een token-URL die niet overeenkomt met de service key of verkeerde headers bij de tokenaanroep.

Krijgt u een token en wijst de API het toch af, decodeer het dan. Controleer of de aud-claim overeenkomt met de API en controleer de scopes. Bij client credentials komen scopes uit de authorities die aan de service-instance zijn toegekend, dus los ontbrekende rollen op in de instanceparameters.

Wat veroorzaakt Internal Server Errors bij het openen van Integration Suite in de BTP Cockpit?

Meestal ontbrekende role collections of een verouderde sessie. Zorg dat uw gebruiker Integration_Provisioner heeft, plus de PI_-role collections die u nodig hebt. Sluit daarna elk BTP-tabblad, meld u af en weer aan, want nieuwe rollen gelden pas na een nieuwe aanmelding.

Blijft het probleem, wis dan de cookies voor de BTP-domeinen en houd het bij één Cockpit-sessie. Meerdere tabbladen op hetzelfde subaccount veroorzaken dezelfde fout.

Waarom maakt mijn CAP-app geen verbinding met een destination die in de Cockpit correct lijkt te staan?

Meestal een naamverschil. De destinationnaam in cds.requires en in uw xs-app.json-routes moet exact overeenkomen met de Cockpit, inclusief hoofdletters.

Klopt de naam, controleer dan of de app is gebonden aan zowel de Destination-service als XSUAA, of het [production]-profiel de inloggegevens bevat en of het kind overeenkomt met de remote service: odata-v2 voor V2, odata voor V4. Gebruik “Check Connection” in de Cockpit om te bevestigen dat het doel bereikbaar is.

Waarom stopt mijn SAP BTP trial-app 's nachts met werken?

Op trial- en free-tierplannen worden SAP HANA Cloud-instances elke nacht gestopt om resources te besparen. Uw app blijft draaien maar kan zijn database niet bereiken. Herstart de instance elke dag in SAP HANA Cloud Central voordat u gaat werken.

Gebruik cf apps en cf services om geheugen- en servicegebruik te controleren, want trialquota zijn in de Cockpit moeilijk te zien. Verwijder ongebruikte instances voordat u nieuwe aanmaakt.

Waarom leiden links in boosters en tegels naar lege pagina's?

Boosterlinks breken wanneer de subaccountstructuur verandert nadat de booster liep. De redirect wijst naar een locatie die niet meer bestaat of nooit volledig is geconfigureerd.

Navigeer in plaats daarvan via de Cockpit-boom en bewaar directe URL's voor Integration Suite, destinations en SAP Build Work Zone als bladwijzer. Vertrouw voor alles wat u dagelijks gebruikt niet op navigatie die door boosters is gegenereerd.

Wanneer moet ik van een BTP trial-account overstappen naar een betaald plan?

Wanneer de beperkingen u tijd gaan kosten. Draait u meer dan één app of database, of hebt u stabiele uptime nodig voor demo's of tests, dan veroorzaakt de trial meer frictie dan hij oplevert.

De belangrijkste winst is stabiliteit en duidelijker inzicht in resources, geen nieuwe functies. Een productief account met free-tierplannen is een goede tussenstap: u kunt die plannen later upgraden naar betaald zonder iets opnieuw op te bouwen.