Surveillance des interfaces SAP : détecter les défaillances silencieuses avant qu’elles n’atteignent le métier

Une destination RFC peut afficher un test de connexion réussi dans SM59 à 09 h, alors que le système situé à l’autre extrémité a cessé de traiter les appels entrants depuis 07 h 30. Le test vérifie qu’un chemin réseau existe. Il ne vérifie pas si quelque chose, côté réception, est en cours d’exécution, lit les données ou poste ce qu’il reçoit. Vous obtenez donc un voyant vert sur la connexion, sans aucune indication que chaque message envoyé depuis 07 h 30 est supprimé silencieusement.

C’est la caractéristique principale des défaillances d’interfaces dans les environnements SAP : les plus dangereuses ne se signalent pas comme des erreurs. Elles ressemblent à un silence opérationnel. L’interface est techniquement active. Les messages sont techniquement envoyés. Aucun statut d’erreur n’est remonté côté émetteur. La défaillance n’apparaît que lorsqu’un utilisateur métier demande pourquoi la mise à jour de stock en provenance du système de gestion d’entrepôt n’a pas été postée, ou pourquoi les factures clients issues du cycle de facturation n’apparaissent pas dans le système du partenaire EDI.

Cet article présente les modes de défaillance spécifiques qui rendent la surveillance des interfaces SAP différente des autres domaines de monitoring, les métriques et signaux qui permettent de détecter les défaillances silencieuses avant qu’elles n’atteignent le métier, ainsi que la couverture de monitoring à mettre en place sur les couches IDoc, RFC, API et processus métier.

Pourquoi les défaillances d’interfaces sont différentes des autres problèmes de monitoring SAP ?

L’erreur qui ne ressemble pas à une erreur

La plupart des dispositifs de monitoring SAP sont construits autour d’états d’erreur : un job avec le statut ABORTED, un work process en erreur, un système qui ne répond plus. Ce sont des défaillances visibles. Quelque chose ne va clairement pas, une alerte se déclenche, et l’équipe d’exploitation investigue.

Les défaillances d’interfaces ne produisent souvent pas d’état d’erreur visible côté émetteur. Un IDoc envoyé à un sous-système EDI reste indéfiniment en statut 02 si le système EDI a cessé de récupérer les messages. Aucune nouvelle erreur n’est générée. Le nombre d’IDocs en statut 02 continue simplement d’augmenter. Une file qRFC se remplit de messages sortants parce que le système récepteur est sous charge et traite lentement. Aucune erreur ne se déclenche tant que la file n’atteint pas une limite configurée, et beaucoup de systèmes n’ont même pas cette limite en place. Un endpoint HTTP répond avec un code 200, mais le corps de la réponse contient un message d’erreur que la couche d’intégration émettrice n’analyse pas.

La couverture de monitoring qui détecte ces situations est différente d’une alerte classique basée sur des seuils de nombre d’erreurs. Elle nécessite de surveiller des états qui ne sont techniquement pas des erreurs, mais qui sont anormaux sur le plan opérationnel : des messages restés trop longtemps dans un statut d’envoi, des files qui grossissent alors qu’elles devraient se vider, ou des volumes qui s’écartent du comportement habituel à ce moment de la journée.

Pourquoi le volume compte autant que le taux d’erreur ?

Une interface order-to-cash performante dans une entreprise industrielle traite plusieurs centaines d’IDocs ORDERS05 par heure pendant les heures ouvrées. Elle traite zéro IDoc pendant la nuit. Ces deux états sont normaux.

Un état anormal : zéro IDoc à 10 h un mardi matin, alors que les commandes devraient circuler. Ce n’est pas un état d’erreur dans une transaction SAP. BD87 ne montre aucune erreur. WE05 ne montre rien dans la file. L’interface semble saine parce que rien n’échoue. En réalité, aucun message n’est envoyé, ce qui signifie que quelque chose en amont a cessé de les générer.

Le monitoring basé sur le volume, qui vérifie si le débit de messages correspond au comportement attendu selon l’heure et le calendrier métier, permet de détecter ce type de défaillance. Une interface qui traite habituellement 400 IDocs par heure le mardi matin et qui est toujours à zéro après 30 minutes d’activité ne tombe pas en erreur. Elle est absente. La distinction est importante, car la correction d’un échec de traitement, où quelque chose génère des erreurs, n’est pas la même que la correction d’une chute de volume, où quelque chose en amont a cessé d’envoyer.

La détection des anomalies de volume nécessite des lignes de base historiques par interface et par plage horaire. Elle est plus complexe à configurer qu’une alerte sur le nombre d’erreurs, ce qui explique pourquoi la plupart des dispositifs de monitoring l’ignorent. C’est pourtant ce qui permet de détecter les défaillances silencieuses ayant le plus fort impact métier.

Monitoring IDoc : aller au-delà des codes statut

Les codes statut qui méritent une attention immédiate

Les IDocs dans SAP disposent de plus de 70 codes statut couvrant chaque étape du traitement sortant et entrant. La plupart sont informatifs. Une partie d’entre eux représente des états qui exigent une attention immédiate en production. Le tableau ci-dessous couvre ceux qui ont la plus forte pertinence opérationnelle.

Huit codes statut concentrent la grande majorité des incidents IDoc à surveiller. Parmi les états d’erreur, le statut 51, erreur de posting, est le plus fréquent en production : l’IDoc a atteint l’étape de traitement entrant mais n’a pas réussi à créer le document SAP. Les causes racines vont des données de base manquantes aux problèmes d’autorisation, en passant par une configuration incorrecte du type de message. Le statut 51 nécessite presque toujours l’intervention d’un utilisateur métier ou d’un consultant fonctionnel, pas seulement d’une équipe Basis. Le diriger vers une boîte générique Basis ajoute des heures au temps de résolution.

Les statuts 25, traitement échoué, et 26, erreur de contrôle syntaxique, indiquent des problèmes côté émetteur ou mapping. Le statut 25 pointe souvent vers le sous-système EDI ou le programme ABAP sortant. Le statut 26 signifie que l’IDoc a été généré avec une erreur structurelle, ce qui relève d’un problème de code ou de configuration côté émetteur.

Deux états intermédiaires méritent une attention particulière, même s’ils ne sont pas des codes d’erreur. Les statuts 02 et 12, envoyés au sous-système EDI ou variante ALE, signifient que l’IDoc a été transmis à la couche de traitement suivante. Techniquement, ce n’est pas une erreur. Mais un IDoc qui reste en statut 02 pendant quatre heures en pleine journée ouvrée est anormal sur le plan opérationnel. Ajouter des alertes basées sur l’âge de ces statuts, et pas seulement sur les erreurs, est l’une des configurations les plus utiles à mettre en place, tout en étant l’une des moins fréquemment implémentées.

Le statut 64, prêt à être transmis à l’application, correspond à l’état de file d’attente entrant. Quelques éléments à un instant donné sont normaux. Un backlog qui augmente ne l’est pas. Il faut surveiller le nombre d’IDocs en statut 64 sur une fenêtre de 15 minutes. S’il augmente au lieu de se résorber, la capacité de traitement entrant ne suit plus, et la cause amont mérite d’être identifiée avant que le backlog ne devienne assez important pour affecter les échéances métier.

IDocs bloqués en traitement : la file qui grossit sans aucune alarme

Le statut 64 représente les IDocs entrants qui ont été reçus et mis en file d’attente pour un posting applicatif, en attente d’un processus disponible. En charge normale, cette file se vide rapidement. Quelques éléments en statut 64 à un instant donné sont attendus. Un backlog croissant en statut 64 ne l’est pas.

Ce backlog augmente lorsque la capacité de traitement entrant ne suit pas le volume entrant. Cela se produit lorsque les background work processes affectés au traitement IDoc entrant sont occupés par d’autres jobs, lorsque le programme de traitement entrant lui-même ralentit à cause d’une régression de performance, ou lorsqu’un IDoc précédent dans la même séquence de traitement est bloqué et empêche les suivants d’avancer.

Surveiller le nombre d’IDocs en statut 64 sur une fenêtre glissante de 15 minutes, et déclencher une alerte lorsque ce nombre augmente au lieu de diminuer, permet de détecter les problèmes de capacité avant qu’ils ne causent des retards visibles dans les processus métier qui dépendent des données entrantes.

L’IDoc terminé qui a posté la mauvaise information

Le statut 53 est le code de succès d’un IDoc : le document applicatif a été posté. Pour la plupart des configurations de monitoring, un IDoc en statut 53 est un dossier clos. L’interface a fonctionné. Rien à surveiller.

Cette hypothèse est correcte pour la majorité des IDocs. Elle est fausse pour les types de messages où la logique de validation métier est faible ou lorsque le mapping entre le format externe et le document SAP est complexe. Un IDoc ORDERS05 peut se terminer en statut 53 et créer une commande client avec un destinataire incorrect si la configuration de détermination du partenaire présente une faille. Un IDoc DESADV, avis de livraison, peut être posté avec succès et créer une entrée de marchandises sur la mauvaise ligne de commande d’achat si la gestion de la référence MBLNR comporte un cas limite.

Ce type de défaillance ne peut pas être détecté au niveau IDoc. Il nécessite un monitoring des processus métier : vérifier si les documents créés par l’interface ont du sens dans leur contexte. Une entrée de marchandises postée sur une commande d’achat déjà entièrement réceptionnée, ou une commande client créée avec une ligne à valeur zéro, sont des signaux visibles dans les données métier qui indiquent qu’une interface a posté quelque chose qu’elle n’aurait pas dû.

Toutes les interfaces ne justifient pas ce niveau de monitoring. Celles qui le nécessitent sont les flux à fort volume et critiques pour le métier, où une erreur systématique dans la logique de posting pourrait mettre plusieurs jours à être détectée manuellement et affecter des centaines de documents avant que quelqu’un ne s’en aperçoive.

Monitoring RFC et qRFC : des connexions qui semblent actives mais ne le sont pas

Les tests de connexion SM59 ne sont pas des contrôles de santé

La méthode standard pour vérifier une destination RFC est le test de connexion dans SM59 : sélectionner la destination, lancer le test, voir un résultat vert. Ce test confirme qu’un chemin réseau existe entre le système SAP et l’hôte cible, et que le système cible répond à une poignée de main initiale. Il ne confirme pas que l’application derrière cette connexion fonctionne, qu’elle traite les appels RFC entrants, ou que le compte utilisateur configuré dans la destination possède les autorisations nécessaires pour exécuter les modules fonctionnels appelés.

Une destination RFC qui réussit le test SM59 alors que l’application réceptrice s’est arrêtée il y a 20 minutes réussira encore le test suivant. Le test vérifie le réseau, pas l’application. C’est une distinction importante lorsqu’une interface échoue silencieusement : un test SM59 réussi ne prouve pas que l’interface fonctionne, et l’utiliser comme preuve fait perdre du temps pendant l’investigation.

Ce qui constitue une preuve pertinente : un appel tRFC récent dans SM58 qui a été dispatché et confirmé comme reçu, ou un message qRFC actif qui a été traité et retiré de la file. Le monitoring doit s’appuyer sur des preuves de traitement au niveau transactionnel, pas sur des preuves de joignabilité réseau au niveau connexion.

La profondeur des files qRFC comme signal d’alerte précoce

Queued RFC livre les messages selon une séquence FIFO vers une file enregistrée sur le système récepteur. Chaque file possède un nom, un serveur applicatif associé et un programme de traitement. Lorsque tout fonctionne, les messages entrent dans la file et sont traités suffisamment vite pour que la profondeur reste faible. Lorsque le côté récepteur est lent, occupé ou indisponible, la profondeur de la file augmente.

L’augmentation de la profondeur de file précède les erreurs franches. Les messages n’échouent pas encore. Ils attendent. Mais une file qui est passée d’une profondeur normale de 5 à 200 en une heure indique un système sous pression. Elle finira par produire des erreurs si la cause de l’accumulation n’est pas résolue. Déclencher des alertes sur la croissance de la profondeur de file, plutôt que d’attendre que la file produise des erreurs, donne à l’équipe d’exploitation du temps pour enquêter et intervenir.

Les seuils pertinents dépendent de chaque file et de son schéma normal de traitement. Une file qui tourne habituellement à une profondeur de 2 et atteint 50 est plus préoccupante qu’une file dont la profondeur normale est de 80 pendant les fenêtres batch et qui se situe à 90. Des seuils génériques appliqués uniformément à toutes les files qRFC créent du bruit pour certaines interfaces et manquent de vrais problèmes pour d’autres.

Files bloquées : ce que signifient réellement SYSFAIL et CPICERR

Une file qRFC en statut SYSFAIL a rencontré une erreur système : généralement un problème de connexion, un timeout ou une défaillance dans l’enregistrement de la file sur le système récepteur. La file arrête de traiter. Tous les messages derrière celui qui échoue restent en file d’attente. Ils ne sont pas livrés, et aucune erreur individuelle n’est générée pour chacun d’eux.

CPICERR indique une erreur de communication CPI-C, ce qui signifie généralement que le système récepteur a refusé la connexion ou l’appel. Ces deux états nécessitent une intervention manuelle : corriger le problème de connectivité sous-jacent et libérer la file, ou déplacer la file vers un autre serveur applicatif si le serveur enregistré est indisponible.

L’exigence de monitoring pour les files bloquées est simple et absolue : toute file en statut SYSFAIL ou CPICERR en production nécessite une attention immédiate. Il n’existe pas de seuil acceptable. Une seule file bloquée en production est déjà de trop, car une file bloquée n’est pas un état dégradé. C’est un état arrêté pour tous les messages de cette file.

Attention : le blocage d’une file ne déclenche pas d’alerte dans le monitoring standard SAP, sauf configuration explicite. Le comportement par défaut veut qu’une file bloquée reste silencieusement dans SMQ1 jusqu’à ce que quelqu’un ouvre manuellement la transaction. Dans les environnements sans monitoring actif des files qRFC, les files bloquées sont découvertes par les utilisateurs métier qui signalent des données manquantes, et non par l’équipe d’exploitation.

Intégrations API et middleware : là où le monitoring devient plus complexe

HTTP 200 n’est pas une confirmation de succès

Les intégrations REST et SOAP entre SAP et les systèmes externes utilisent HTTP comme couche de transport. Les codes de réponse HTTP sont le principal signal de succès ou d’échec au niveau connexion : 200 signifie que la requête a été reçue et qu’une réponse a été retournée, 4xx signifie que la requête a été rejetée, 5xx signifie que le serveur a rencontré une erreur.

Le problème est que 200 signifie que la réponse a été retournée, pas qu’elle contient un succès. Un système récepteur qui a accepté la charge utile mais a rencontré une erreur de logique métier pendant son traitement renvoie souvent un HTTP 200 avec un corps d’erreur : un objet JSON avec un code d’erreur, une réponse XML contenant un élément fault, ou une réponse en texte brut contenant un message d’exception. La couche d’intégration côté SAP a envoyé le message, reçu un 200, l’a enregistré comme succès et est passée à la suite. Le système récepteur ne l’a pas traité.

Surveiller les intégrations HTTP uniquement au niveau du code de réponse permet de détecter les défaillances techniques franches. Surveiller le corps de réponse, en analysant le contenu pour vérifier qu’il indique un succès réel plutôt qu’une erreur encapsulée, permet de détecter les cas où le transport a fonctionné mais pas l’opération métier. Cela nécessite que la couche d’intégration mette en œuvre une validation du corps de réponse, et pas seulement une vérification du code statut.

Monitoring de SAP Integration Suite et des flux basés sur BTP

SAP Integration Suite, anciennement SAP Cloud Platform Integration, route et transforme les messages entre SAP et les systèmes externes. Ses modes de défaillance diffèrent des interfaces RFC ou IDoc directes, car elle ajoute une couche supplémentaire avec sa propre gestion des erreurs, sa logique de retry et son magasin de messages.

Un flux Integration Suite peut échouer de plusieurs façons qui ne sont pas visibles côté SAP : l’adaptateur du flux ne parvient pas à joindre l’endpoint cible, la transformation du message produit une erreur de mapping, la politique de retry épuise toutes ses tentatives et le message est déplacé vers la file d’erreur. Tous ces états sont visibles dans la vue Operations d’Integration Suite dans le cockpit BTP, pas dans une transaction SAP.

Pour les équipes SAP habituées à monitorer depuis des transactions ABAP, cela crée un manque de visibilité. Le système SAP a bien envoyé le message à Integration Suite. C’est dans Integration Suite que le problème s’est produit. Sans couverture de monitoring couvrant à la fois la couche SAP ABAP et la couche BTP, l’investigation commence avec seulement la moitié du tableau.

Concrètement, cela signifie que le monitoring des interfaces dans les paysages intégrés à BTP doit inclure le monitoring BTP Operations comme un élément de périmètre explicite, et non comme un sujet géré séparément par l’équipe cloud. Les nombres d’erreurs de messages, les instances de flux échouées et les taux d’erreur d’adaptateurs issus d’Integration Suite sont aussi pertinents pour la santé globale de l’interface que les données SM58 et BD87.

Expiration des certificats SSL : la panne d’interface la plus évitable

Les certificats SSL sur les destinations RFC, les endpoints HTTPS et les connecteurs middleware expirent. Lorsqu’ils expirent, la connexion échoue avec une erreur de validation de certificat et l’interface s’arrête immédiatement. Pas de dégradation progressive, pas de période d’avertissement, pas de renouvellement automatique dans la plupart des configurations SAP.

C’est l’une des catégories de défaillance d’interface les plus évitables. Une expiration de certificat est planifiée. La date d’expiration est connue à l’avance. Une alerte configurée 30 jours avant l’expiration donne à l’équipe le temps de renouveler et déployer le certificat sans urgence. Une alerte à 7 jours donne un délai suffisant dans la plupart des cas. Aucune alerte signifie une découverte au moment de l’expiration, pendant les heures ouvrées si l’équipe a de la chance, pendant un week-end si elle ne l’a pas.

Le monitoring de l’expiration des certificats SSL n’est pas complexe. Il nécessite une liste des endpoints avec certificats, un contrôle planifié de la date d’expiration de chaque certificat et un seuil d’alerte. La mise en place du monitoring prend quelques heures. La panne d’interface qu’il permet d’éviter prend bien plus de temps à résoudre, surtout si le renouvellement du certificat implique une autorité de certification externe et nécessite un délai.

Monitoring de bout en bout des flux : relier la santé technique aux résultats métier

Quand l’interface fonctionne mais pas le processus métier

Le monitoring technique des interfaces, qui couvre les statuts IDoc, les files RFC et les codes HTTP, indique si la couche de transport de données fonctionne. Il ne dit pas si le processus métier qui dépend de ces données fonctionne. Une interface peut traiter chaque message sans erreur alors que le processus métier qu’elle soutient a cessé de fonctionner, parce que les données traitées sont incorrectes.

L’exemple le plus fréquent en pratique : une interface ORDERS05 entrante traite sans erreur et crée des commandes clients dans SAP, tandis qu’une condition de prix mise à jour dans le système émetteur n’est pas reflétée dans la détermination du prix SAP. Chaque commande est postée. Chaque IDoc atteint le statut 53. Le métier découvre l’erreur de prix lorsque les premières factures sortent avec des montants incorrects. Le monitoring technique est resté vert tout du long.

Le monitoring des processus métier comble cette lacune en vérifiant les résultats, pas seulement le statut du transport. Les commandes clients créées par l’interface présentaient-elles les marges attendues ? Les mouvements de stock ont-ils été postés dans les emplacements de stockage prévus ? Les factures entrantes ont-elles été rapprochées automatiquement, ou sont-elles passées en revue manuelle à un taux anormalement élevé ? Ce sont des signaux métier que le monitoring technique des interfaces ne produit pas.

Mettre en place un monitoring des flux métier nécessite une collaboration entre l’équipe IT operations et les responsables de processus afin de définir ce qu’est un résultat sain pour chaque interface. C’est plus exigeant à construire qu’un monitoring par code statut. Mais cela détecte le mode de défaillance à l’origine des incidents les plus coûteux : le traitement correct de données incorrectes.

La détection des anomalies de volume comme complément aux alertes d’erreur

Chaque interface en production possède un profil de volume normal. Certaines sont constantes et traitent un flux régulier de messages tout au long de la journée ouvrée. Certaines sont orientées batch, avec un pic à une heure précise puis une période calme. D’autres dépendent du calendrier, avec des volumes plus élevés certains jours ou à certains moments du mois.

Construire une ligne de base de volume par interface, par heure de la journée et par jour de la semaine, permet de déclencher une catégorie d’alertes que le monitoring d’erreurs ne peut pas fournir : l’alerte qui se déclenche lorsqu’une interface normalement active devient silencieuse. Zéro message traité sur les 30 dernières minutes par une interface qui traite normalement 200 messages par heure n’est pas un état d’erreur. C’est une absence. Mais cette absence représente un risque métier identique à celui d’une interface qui traite des erreurs : le processus aval ne reçoit pas les données.

La détection des anomalies de volume nécessite au moins quatre semaines de données de référence avant que les seuils d’alerte soient significatifs, car les schémas hebdomadaires et mensuels doivent être capturés pour distinguer les véritables anomalies des périodes attendues de faible volume. L’investissement de configuration est pertinent pour les interfaces suffisamment critiques pour qu’une chute de volume de deux heures ait un impact métier visible.

Référence de couverture pour le monitoring des interfaces

Le tableau ci-dessous organise les métriques de monitoring présentées dans cet article par couche, avec la source ou la vue SAP concernée, un seuil d’alerte pratique et l’action recommandée pour chacune.

La couche interface est celle où se trouvent la plupart des angles morts SAP

Le monitoring des interfaces reçoit moins d’attention systématique que le monitoring des serveurs applicatifs ou des bases de données, en partie parce qu’il traverse plusieurs systèmes et frontières de responsabilité, et en partie parce que ses modes de défaillance sont moins évidents. Une base de données qui ne répond plus est immédiatement visible. Une interface qui traite des messages sans produire les résultats métier attendus exige un autre niveau d’attention pour être détectée.

La couverture qui fait la différence repose sur la combinaison de trois couches. Le monitoring technique du transport, qui couvre les statuts IDoc, les files RFC et les taux d’erreur API, constitue la base. La détection des anomalies de volume est la couche qui identifie les défaillances ne produisant aucune erreur. Le monitoring des flux métier est la couche qui détecte les défaillances où le transport est correct, mais les résultats sont incorrects.

La plupart des environnements SAP disposent d’une version de la première couche. Très peu disposent de la deuxième, et encore moins de la troisième. L’écart entre la première couche seule et les trois couches complètes est l’écart entre un monitoring qui détecte ce que SAP signale explicitement comme incorrect, et un monitoring qui détecte ce que le métier finira par signaler comme incorrect. Le second est celui qui évite l’appel du vendredi après-midi pour comprendre pourquoi les livraisons de la semaine précédente n’ont pas été expédiées.

Redpeaks surveille les interfaces SAP sur les couches IDoc, RFC, qRFC, HTTP et BTP depuis une connexion unique sans agent, avec alertes basées sur les lignes de base de volume et intégration ITSM pour router chaque type d’alerte vers la bonne équipe.

Découvrez la couverture de monitoring des interfaces