Problèmes du cockpit SAP BTP : cinq cas et comment les résoudre

Si le cockpit SAP BTP vous renvoie des erreurs, c'est probablement l'une de cinq causes. Un 401 avec une clé de service vient presque toujours de la requête OAuth, pas des identifiants. Une Internal Server Error sur Integration Suite signifie généralement des collections de rôles manquantes ou une session périmée. Les liens morts viennent de boosters configurés avant que le sous-compte ne change. Les échecs de destination CAP sont en général une différence de nom ou un binding manquant. Et une application qui fonctionnait hier sur un compte trial a peut-être perdu sa base de données pendant la nuit. Ce guide s'adresse aux développeurs et aux consultants en intégration qui travaillent dans des sous-comptes Cloud Foundry. Le tableau de triage ci-dessous indique quoi vérifier en premier.

La première fois que j'ai vu la bannière d'erreur rouge dans le cockpit SAP BTP, j'ai cru avoir fait quelque chose de travers. Mauvais lien, session expirée.

Après la troisième ou la quatrième fois, il était clair que ce n'était pas seulement moi.

Au cours des semaines suivantes, j'ai tenu un carnet où je notais chaque fois que quelque chose cassait. Des Internal Server Errors à l'ouverture d'Integration Suite. Des destinations qui semblaient valides et refusaient de se connecter. Des applications qui fonctionnaient hier et se bloquaient aujourd'hui. Des schémas sont apparus. Peu d'entre eux étaient documentés quelque part d'utile, et le cockpit lui-même ne donne presque rien à exploiter.

Symptôme	Cause la plus probable	À vérifier en premier
401 Unauthorized lors de l'appel d'une API avec une clé de service	Mauvais grant type, mauvaise URL de jeton ou autorisations manquantes	Décoder le jeton et lire aud et scope
Internal Server Error à l'ouverture d'Integration Suite	Collections de rôles manquantes ou session périmée	Les collections de rôles de votre utilisateur, puis une déconnexion complète
Un booster ou une tuile ouvre une page vide ou erronée	Le sous-compte a changé après l'exécution du booster	Naviguer plutôt par l'arborescence du cockpit
Application CAP : « destination not found » ou erreurs d'authentification	Différence de nom, binding manquant, mauvais kind OData	cds.requires et xs-app.json comparés au nom dans le cockpit
L'application fonctionnait hier, se bloque aujourd'hui (trial)	L'instance HANA Cloud s'est arrêtée pendant la nuit	Le statut de l'instance de base de données dans SAP HANA Cloud Central

Cloud Foundry, Kyma et l'environnement ABAP reposent sur la fondation multicloud de SAP, qui est le choix par défaut pour les nouveaux clients depuis 2020. L'ancien environnement Neo ne reçoit que des mises à jour de sécurité et de conformité, et SAP a fixé son arrêt au 31 décembre 2028. Presque tous les problèmes ci-dessous sont des problèmes Cloud Foundry.

Deux changements de nom prêtent encore à confusion quand on lit d'anciens guides. SAP Launchpad service est devenu SAP Build Work Zone, standard edition, en janvier 2023. Et beaucoup de tuiles et de boosters ont été reconstruits avec la croissance de SAP Build, si bien que les captures d'écran de 2022 ne correspondent souvent plus à ce que vous voyez.

Avec RISE with SAP, BTP arrive généralement sous la forme d'un droit d'utilisation à crédits inclus dans le contrat. Le cockpit est le même. Ce qui change, c'est qui, dans votre organisation, contrôle le compte global : trouvez cette personne avant d'avoir besoin d'un nouveau droit.

Vous créez une instance de service, générez une clé de service, copiez le client ID et le secret dans Postman, ajoutez l'URL de jeton et envoyez la requête. 401. Aucun détail.

Vous recopiez le secret. Toujours en échec. Le service est en bon état. C'est le flux OAuth qui ne l'est pas.

À vérifier, dans l'ordre :

1. Grant type. L'accès technique à la plupart des API des services BTP utilise client_credentials. Définissez-le explicitement dans Postman. Ne vous fiez pas à la valeur par défaut.
2. URL du jeton. Prenez-la dans la clé de service. Certaines clés fournissent un tokenurl ; d'autres donnent l'url XSUAA, à laquelle vous ajoutez /oauth/token. N'empruntez jamais celle d'un autre sous-compte.
3. En-têtes. Pour un appel direct au jeton, envoyez Content-Type: application/x-www-form-urlencoded et Authorization: Basic <base64(clientid:clientsecret)>.
4. Autorisations (authorities). Avec client credentials, le jeton ne porte que les scopes accordés à cette instance de service. Si l'API exige un rôle que l'instance n'a pas, vous obtenez quand même un jeton, et l'API dit quand même non. Corrigez-le dans les paramètres de l'instance (par exemple les rôles d'une instance du plan API d'Integration Suite), pas dans la requête.
5. Audience. Si vous avez un jeton et que l'API le rejette, décodez-le et lisez la revendication aud. Si elle ne correspond pas à l'API que vous appelez, vous utilisez une clé issue de la mauvaise instance de service.

Vous ouvrez Integration Suite et une bannière rouge « Internal Server Error » apparaît. Aucun journal. Rechargement, autre navigateur, même résultat.

Cela arrive généralement après une période d'inactivité du service : ouvert le matin, laissé quelques heures, réutilisé plus tard. Les fils de la communauté SAP et la base de connaissances pointent deux causes habituelles : des collections de rôles manquantes et des sessions périmées.

Ce qui résout généralement le problème :

1. Vérifiez les collections de rôles. Votre utilisateur a besoin de Integration_Provisioner pour configurer le tenant, et des collections de rôles PI_ concernées (administrateur, développeur d'intégration, expert métier) pour y travailler. Attribuez-les dans le sous-compte, sous Security.
2. Déconnectez-vous complètement. Les changements de rôles n'atteignent votre session qu'après une nouvelle connexion. Fermez tous les onglets BTP et Integration Suite, déconnectez-vous, puis reconnectez-vous.
3. Effacez les cookies des domaines BTP si l'erreur survit à une nouvelle connexion. Un cookie de session périmé peut survivre à la session.
4. Utilisez une seule session du cockpit. Plusieurs onglets ou profils de navigateur sur le même sous-compte provoquent des conflits de session qui ressemblent exactement à cette erreur.

Le vrai problème, c'est la visibilité. Le cockpit ne dit rien de ce qui a échoué, alors vous finissez par deviner. Parcourez plutôt la liste dans l'ordre. Pour une vue plus large des raisons pour lesquelles les programmes d'intégration s'enlisent, voir mon article sur les retards de livraison de SAP Integration Suite.

Vous cliquez sur « Go to Application » et obtenez un écran blanc, une page d'accueil générique ou une redirection absurde.

Cela suit des schémas :

1. Les liens de booster cassent quand la configuration du sous-compte change après l'exécution du booster. La redirection pointe vers un endroit qui n'existe plus.
2. Les tuiles Integration Suite fonctionnent parfois, parfois renvoient une erreur, parfois expirent, en général pour les raisons de session vues plus haut.
3. Les liens SAP Build Work Zone affichent « connection denied » quand l'abonnement existe mais que votre utilisateur n'a pas la collection de rôles du site.
4. Plusieurs onglets ou profils de navigateur ouvrent les liens dans des contextes expirés.

Ce qui marche : naviguez par l'arborescence du cockpit (sous-compte, puis Services, puis Instances and Subscriptions), et mettez en favori les URL directes d'Integration Suite, des destinations et de Work Zone. Utilisez une seule session dans un profil de navigateur propre. Quand un lien échoue une fois sur trois, on cesse de faire confiance à la plateforme et on se met à bricoler des contournements. Les favoris sont le contournement le moins cher qui existe. Si vous cherchez encore vos repères, mon parcours du cockpit BTP couvre la navigation de base.

Vous déployez une application CAP, configurez une destination dans le cockpit, et les requêtes échouent toujours avec « destination not found » ou des erreurs d'authentification. La destination est listée. L'application tourne. Les messages d'erreur ne mènent nulle part d'utile.

La documentation CAP de SAP est claire sur la façon dont tout cela doit être câblé : le service distant est déclaré sous cds.requires dans package.json (ou .cdsrc.json) avec un kind, et le nom de la destination va sous credentials.destination. L'application doit aussi avoir des bindings vers le service Destination et vers XSUAA. La plupart des échecs sont une rupture quelque part dans cette chaîne.

1. 01cds.requiresDéclare le service distant, son kind et le nom de la destination
2. 02Profil de productionContient les identifiants de la destination après le déploiement
3. 03Bindings de serviceL'application est liée à Destination et à XSUAA
4. 04Destination dans le cockpitMême nom que dans cds.requires et xs-app.json, casse comprise
5. 05Service distantodata-v2 pour un service V2, odata pour V4

Les requêtes atteignent le service distant

Symptôme	Correctif
La destination est listée mais l'application ne la trouve pas	Comparez le nom dans cds.requires et dans les routes de xs-app.json avec celui du cockpit, caractère par caractère, casse comprise
Fonctionne en local, échoue après le déploiement	Vérifiez que le profil [production] contient bien les identifiants de la destination, et que l'application est liée à Destination et à XSUAA
Le service OData V2 distant renvoie des erreurs	Définissez kind sur odata-v2 pour un service V2 et sur odata pour V4. Utilisez V4 partout où les deux côtés le permettent
Une application UI5 a besoin de V2 mais votre service CAP est en V4	Ajoutez le plugin @cap-js-community/odata-v2-adapter. L'ancien @sap/cds-odata-v2-adapter-proxy est obsolète
L'authentification échoue avec des identifiants valides	Commencez par OAuth2ClientCredentials ou BasicAuthentication. N'utilisez SAML ou la propagation de principal que si le scénario l'exige
Vous n'êtes pas sûr que la cible soit joignable	Utilisez « Check Connection » sur la destination dans le cockpit avant de déboguer l'application

Les équipes qui s'en sortent bien tiennent une courte liste de contrôle de destination par application. Pas parce que la configuration est complexe. Parce qu'une seule mauvaise hypothèse sur le nom, le binding ou le kind OData échoue en silence et prend bien plus de temps à trouver qu'à prévenir.

Une application CAP qui fonctionnait hier se bloque maintenant. Aucune erreur. Le cockpit indique qu'elle tourne. Vous la redémarrez. Rien.

Vérifiez d'abord la base de données. Le tutoriel HANA Cloud trial de SAP indique que les instances free tier sont arrêtées chaque nuit et doivent être redémarrées chaque jour où vous travaillez. Le compte trial lui-même dure jusqu'à 90 jours si vous vous connectez régulièrement. Votre application va bien. C'est sa base de données qui dort.

Ce qui aide :

1. Redémarrez l'instance HANA Cloud depuis SAP HANA Cloud Central avant de commencer à déboguer le code.
2. Utilisez la CLI (cf apps, cf services) pour voir la mémoire et l'usage des services. L'interface du cockpit en montre bien moins.
3. Supprimez les instances de service inutilisées avant d'en créer de nouvelles. Les quotas trial s'appliquent à tout le compte, pas à une seule application.
4. Gardez les charges de démonstration et de test dans des sous-comptes séparés.

Si vous avez besoin de plus d'une application et d'une base de données qui tournent de façon fiable, ou d'une disponibilité stable pour des démos, passez à un compte productif. Les plans free tier d'un compte productif peuvent passer en payant sans perdre votre travail, ce qu'un compte trial ne permet pas.

Pourquoi une erreur 401 avec les identifiants d'une clé de service SAP BTP, alors qu'ils semblent corrects ?

Presque toujours à cause de la requête OAuth, pas des identifiants. Les causes habituelles sont un mauvais grant type (utilisez client_credentials pour l'accès technique), une URL de jeton qui ne correspond pas à la clé de service, ou de mauvais en-têtes sur l'appel au jeton.

Si vous obtenez un jeton et que l'API le rejette quand même, décodez-le. Vérifiez que la revendication aud correspond à l'API, et vérifiez les scopes. Avec client credentials, les scopes viennent des autorisations accordées à l'instance de service : corrigez donc les rôles manquants dans les paramètres de l'instance.

Qu'est-ce qui provoque des Internal Server Errors à l'ouverture d'Integration Suite dans le cockpit BTP ?

Le plus souvent des collections de rôles manquantes ou une session périmée. Assurez-vous que votre utilisateur a Integration_Provisioner et les collections de rôles PI_ dont vous avez besoin. Ensuite, fermez tous les onglets BTP, déconnectez-vous et reconnectez-vous, car les nouveaux rôles ne s'appliquent qu'après une nouvelle connexion.

Si le problème persiste, effacez les cookies des domaines BTP et limitez-vous à une seule session du cockpit. Plusieurs onglets sur le même sous-compte déclenchent la même erreur.

Pourquoi mon application CAP n'arrive-t-elle pas à se connecter à une destination qui apparaît correctement dans le cockpit ?

Généralement à cause d'une différence de nom. Le nom de la destination dans cds.requires et dans les routes de votre xs-app.json doit correspondre exactement à celui du cockpit, casse comprise.

Si le nom est bon, vérifiez que l'application est liée à la fois au service Destination et à XSUAA, que le profil [production] porte les identifiants, et que le kind correspond au service distant : odata-v2 pour V2, odata pour V4. Utilisez « Check Connection » dans le cockpit pour confirmer que la cible est joignable.

Pourquoi mon application SAP BTP trial cesse-t-elle de fonctionner la nuit ?

Sur les plans trial et free tier, les instances SAP HANA Cloud sont arrêtées chaque nuit pour économiser des ressources. Votre application continue de tourner mais ne peut plus joindre sa base de données. Redémarrez l'instance dans SAP HANA Cloud Central chaque jour avant de travailler.

Utilisez cf apps et cf services pour vérifier la mémoire et l'usage des services, car les quotas trial sont difficiles à voir dans le cockpit. Supprimez les instances inutilisées avant d'en créer de nouvelles.

Pourquoi les liens dans les boosters et les tuiles mènent-ils à des pages vides ?

Les liens de booster cassent quand la structure du sous-compte change après l'exécution du booster. La redirection pointe vers un emplacement qui n'existe plus ou n'a jamais été entièrement configuré.

Naviguez plutôt par l'arborescence du cockpit, et mettez en favori les URL directes d'Integration Suite, des destinations et de SAP Build Work Zone. Ne comptez pas sur la navigation générée par les boosters pour ce que vous utilisez au quotidien.

Quand passer d'un compte trial BTP à un plan payant ?

Quand les limites vous font perdre du temps. Si vous exploitez plus d'une application ou d'une base de données, ou si vous avez besoin d'une disponibilité stable pour des démos ou des tests, le trial crée plus de friction qu'il n'en épargne.

Les gains principaux sont la stabilité et une meilleure visibilité sur les ressources, pas de nouvelles fonctionnalités. Un compte productif avec des plans free tier est une bonne étape intermédiaire : vous pourrez passer ces plans en payant plus tard sans rien reconstruire.