Lorsqu’une équipe adopte RISE with SAP, quelqu’un dit généralement : « SAP gère l’infrastructure ». Cette phrase exacte entretient un malentendu : l’infrastructure inclurait la surveillance de ce qui s’y exécute. Ce n’est pas le cas. La frontière entre SAP et le client est plus nette, et moins favorable au client, que cette formulation ne le suggère.
Ce guide cartographie cette frontière, explique ses conséquences opérationnelles et décrit une connexion de monitoring couvrant les lacunes du modèle de responsabilité partagée.
Ce que SAP gère dans RISE et ses conséquences
RISE regroupe hébergement S/4HANA Cloud Private Edition, BTP et infrastructure managée dans un abonnement. Avec l’hyperscaler, SAP gère calcul, stockage, réseau, correctifs système, haute disponibilité du cluster HANA, administration de base et incidents de plateforme liés à l’infrastructure.
Ce périmètre n’inclut pas la visibilité opérationnelle de l’application. SAP surveille la disponibilité de la plateforme et le fonctionnement du service HANA, mais pas la ponctualité des jobs, les erreurs IDoc, les temps de réponse dialogue selon le SLA ou les échecs silencieux de mise à jour. Ces conditions appartiennent au périmètre client.
Passer à RISE ne réduit donc pas le monitoring applicatif nécessaire. Cela retire le suivi de l’infrastructure, la partie la plus limitée du monitoring SAP. La couche applicative, où naît la majorité des incidents, reste entièrement à surveiller par le client.
Une vue claire des responsabilités partagées
Le tableau distingue les responsabilités. L’engagement de SAP porte sur la disponibilité de plateforme ; la santé applicative reste au client.
| SAP gère dans RISE | Le client conserve |
|---|---|
| Infrastructure hyperscaler : calcul, stockage, réseau | Planification des jobs de fond et contrôle de leurs résultats |
| Haute disponibilité et bascule du cluster HANA | Performance applicative HANA et vues M_* |
| Correctifs OS et mises à jour du noyau | Santé des interfaces IDoc, RFC et API |
| SLA de disponibilité de la plateforme SAP | Short dumps ABAP et échecs de mise à jour |
| Connexion réseau à la région hyperscaler | Performance des extensions BTP et flux Integration Suite |
| Réponse aux incidents d’infrastructure | SLO d’achèvement des processus métier |
| Administration de base et services de plateforme HANA | Qualité du code ABAP spécifique et conception des autorisations |
Point de vigilance : le SLA RISE ne couvre pas les temps de réponse applicatifs, taux de réussite batch, délais d’interfaces ni fenêtres métier. S’en remettre à RISE pour ces conditions expose à découvrir la lacune pendant l’incident, lorsque SAP confirme une plateforme saine et un problème applicatif.
Le périmètre de monitoring qui ne se transfère pas
Métriques applicatives
Les métriques importantes avant RISE le restent : dialogue par code transaction, WP par instance, file de mises à jour, réussite des jobs et fréquence des dumps. SM50, SM66, SM37, SM13 et ST22 restent disponibles et pertinents. Les méthodes de monitoring des WP et jobs SAP s’appliquent sans changement.
Les métriques applicatives HANA restent aussi au client. Dans SYS, M_MEMORY_OVERVIEW, M_DISK_USAGE, M_BACKUP_CATALOG, M_DELTA_MERGE_STATISTICS et M_EXPENSIVE_STATEMENTS sont accessibles à un utilisateur de monitoring de base provisionné pour le client. SAP surveille HANA comme service ; le client le surveille comme base de ses applications. Ces objectifs nécessitent des métriques différentes. Le guide de monitoring HANA couvre cet ensemble.
Résultats métier
SAP ne sait pas si un job devait finir à 6 h ni si son résultat correspond à l’attente métier. Ces exigences et les SLO, engagements sur quoi livrer et quand, sont hors de son périmètre RISE.
La différence entre un SLA de disponibilité à 99,9 % et la continuité réelle devient concrète : la plateforme peut être disponible à 100 % tandis qu’un job échoue, qu’une interface s’arrête et que la clôture manque son échéance. Le SLA SAP est respecté, celui du métier non. Seul le client peut surveiller cette couche et réagir.
Extensions BTP et intégration
BTP peut faire partie de l’offre, mais les extensions sont du code client sur une infrastructure SAP. Le même partage s’applique. Le client doit surveiller disponibilité, erreurs et performances des flux Integration Suite, applications spécifiques et endpoints API d’extension S/4HANA. Les recommandations sur les hubs d’intégration SAP restent applicables.
Connecter le monitoring à RISE with SAP
Connexion RFC à la couche ABAP
Le processus ressemble à toute connexion SAP : créer un utilisateur technique dédié dans le mandant de production, lui attribuer le profil de lecture nécessaire et configurer la destination RFC correspondante dans SM59. Aucun accès infrastructure ni logiciel installé côté SAP n’est nécessaire.
C’est le modèle sans agent. La collecte RFC nécessite les autorisations adaptées, sans contrainte particulière liée à RISE. Le guide d’architecture sans agent détaille leur configuration. Le processus utilisé sur S/4HANA local fonctionne aussi en Private Edition.
Accès SQL HANA dans RISE
L’utilisateur de monitoring de base nécessite notamment MONITORING et CATALOG READ. Sa création suit la procédure SAP pour les utilisateurs de base clients, différente d’un accès DBA complet. L’outil se connecte via JDBC et exécute des requêtes en lecture sur les vues système afin de collecter les métriques applicatives.
La collecte applicative par un outil connecté à HANA est distincte des restrictions d’infrastructure. SAP limite notamment SSH au système, l’administration au-delà du périmètre client et les changements de configuration gérée. Ces restrictions ne concernent pas la même couche que la connexion de monitoring applicatif.
À noter : en Public Edition, le périmètre est plus contraint qu’en Private Edition. La standardisation réduit les possibilités de modification des paramètres et de monitoring spécifique. Vérifiez avec SAP les accès et connexions disponibles avant de supposer que les capacités Private Edition s’appliquent.
Les lacunes découvertes après la mise en production
Elles suivent souvent le même schéma : des capacités auparavant acquises sur site nécessitent une configuration explicite, parce que l’idée « SAP gère le monitoring » a été étendue trop loin.
La plus fréquente concerne les jobs. SAP alerte sur les événements d’infrastructure, pas automatiquement sur le batch client. Un Tier 1 échouant à 4 h ne génère pas d’alerte client sans une plateforme configurée pour le détecter. Le support confirme une plateforme saine : le job est un événement applicatif.
La deuxième concerne les interfaces : IDoc en erreur dans BD87, files qRFC dans SMQ1, destinations RFC devenues injoignables et certificats de connecteurs Integration Suite expirants. Ces événements applicatifs ne déclenchent pas automatiquement une alerte RISE. Le guide d’interfaces SAP s’applique directement ; la connexion RFC vise la même couche, où que soit le matériel.
La troisième concerne HANA. SAP surveille la stabilité de plateforme. La mémoire approchant sa limite relève du suivi client avant de devenir un incident de plateforme. Sans monitoring, le premier signe peut être un arrêt imprévu de la base, comme sur site. Le guide de préparation au go-live S/4HANA décrit les éléments à instrumenter avant la première charge de production, pour une migration ou un système neuf.
RISE change le responsable de l’infrastructure, pas les éléments applicatifs à surveiller ni leur propriétaire. Les clients préparés lisent le partage avant le go-live, connectent le monitoring à temps et distinguent gestion d’infrastructure et surveillance applicative.
Les moins préparés découvrent la lacune au premier incident, lorsque SAP confirme une plateforme saine et que l’enquête doit repartir de zéro faute de données applicatives.
Redpeaks se connecte à RISE par RFC standard et SQL HANA, sans accès infrastructure, avec une couverture comparable à celle sur site. Découvrez le monitoring RISE with SAP.
