Le middleware est introduit dans les architectures d’intégration SAP pour de bonnes raisons techniques : découpler les systèmes, traduire les protocoles, centraliser la gestion des erreurs ou encore permettre la transformation des messages. Pourtant, les conséquences de ces choix sur le monitoring sont rarement abordées lors des discussions d’architecture. Or, le middleware introduit également de nouveaux angles morts qui ne sont pas toujours évalués explicitement.
Un hub qui traite correctement les messages est invisible pour le système SAP qui les a envoyés. Un hub qui échoue l’est également, du point de vue de SAP. Le système émetteur ne sait pas si le message a effectivement été livré, correctement transformé puis traité par le système destinataire, sauf si le hub est monitoré séparément et si ce monitoring est conçu pour faire remonter les erreurs à l’équipe responsable de la partie SAP.
Cet article présente les principales façons dont une architecture middleware modifie ce qui peut être observé, déplace les responsabilités de monitoring et influence les décisions d’architecture permettant de rendre les opérations plus simples à gérer de part et d’autre de la couche d’intégration.
Ce qu’une architecture en hub change réellement en matière de visibilité
Le point de référence d’une architecture point à point
Dans une connexion RFC ou IDoc directe entre deux systèmes SAP, la visibilité disponible côté émetteur est relativement complète. SM58 indique si un appel RFC transactionnel a été envoyé et acquitté. BD87 affiche le statut de l’IDoc à chaque étape. Si l’appel échoue, l’erreur est visible dans les moniteurs transactionnels du système émetteur. S’il aboutit, l’accusé de réception confirme que le système destinataire a accepté le message.
Cette visibilité n’est pas parfaite. Un message reconnu comme reçu par la couche RFC du système destinataire peut encore échouer lors du traitement applicatif et produire, par exemple, une erreur IDoc de statut 51 côté destinataire. Cette erreur ne sera pas visible sur le système émetteur sans monitoring explicite du système récepteur. Mais la surface d’erreur reste clairement définie et limitée. Les outils de monitoring disponibles côté SAP en couvrent une grande partie.
Ce qui change lorsque le middleware entre en jeu
Lorsqu’un message transite par un hub, la visibilité du système SAP émetteur se réduit essentiellement à une seule information : le message a-t-il bien atteint le middleware ?
Si la réponse est oui, le système SAP poursuit son traitement. Tout ce qui se passe ensuite, traitement par le middleware, transformation, livraison au système cible et traitement applicatif par ce dernier, sort du champ d’observation direct du système SAP émetteur.
L’ampleur de cet angle mort dépend directement du niveau d’asynchronisme de l’architecture. Dans une architecture entièrement asynchrone, le système SAP dépose un message dans la file d’entrée du middleware et reprend immédiatement son traitement. Du point de vue du monitoring transactionnel SAP, l’envoi est réussi. La question de savoir si le système en aval a réellement reçu et traité le message doit alors être résolue par le monitoring du middleware, et non par le système SAP.
Dans une architecture de hub synchrone, le système SAP attend une réponse du middleware, qui attend lui-même une réponse du système cible. SAP connaît donc le résultat final puisque l’appel se termine soit par un succès, soit par une erreur. Les architectures synchrones conservent une meilleure visibilité de bout en bout, mais au prix des performances : le work process SAP maintient une connexion pendant toute la durée de la chaîne d’appels en aval.
Hubs asynchrones et problème des Dead Letter Queues
L’intégration asynchrone est aujourd’hui le modèle dominant dans les architectures middleware SAP modernes, car elle permet de découpler les performances du système émetteur et du système destinataire. Le système SAP n’est pas bloqué dans l’attente d’une réponse du système en aval. De même, les pics de traitement côté destinataire ne ralentissent pas directement le système SAP émetteur. Ce sont de vrais avantages.
Le coût en termes de monitoring est que la confirmation de livraison sort entièrement du champ de visibilité du système SAP émetteur. Celui-ci sait uniquement qu’il a transmis le message. La confirmation que le message a effectivement été traité par le destinataire n’existe que dans les logs du middleware et, si l’architecture du hub est correctement conçue, dans les données applicatives du système cible.
Le mode d’échec caractéristique des architectures asynchrones est la Dead Letter Queue, ou DLQ. Lorsqu’un message échoue dans le middleware et atteint le nombre maximal de tentatives de traitement, il est déplacé vers la DLQ. Ce comportement est correct : le message est conservé pour analyse au lieu d’être supprimé.
Le problème opérationnel apparaît lorsque les messages s’accumulent silencieusement dans la DLQ parce qu’aucune alerte n’a été configurée sur sa profondeur.
Une DLQ dans laquelle des messages s’accumulent depuis trois jours représente trois jours d’échecs de livraison qui n’ont déclenché aucune alerte. Le système SAP émetteur considère l’envoi comme réussi puisque le message a atteint le hub. Le hub considère de son côté que la politique de gestion des erreurs a été correctement appliquée puisque le message a été déplacé vers la DLQ. Le métier ne découvre alors le problème que lorsqu’un processus en aval produit des données incorrectes ou incomplètes.
| Attention : les Dead Letter Queues sans alerte de monitoring font partie des sources les plus fréquentes d’échecs silencieux dans les architectures basées sur un hub. Déclencher une alerte dès qu’un ou deux messages sont présents dans une DLQ n’est pas excessif dans un environnement de production. Un message dans une DLQ est un message dont le traitement a échoué après épuisement des tentatives de reprise. Chaque entrée représente donc une livraison qui n’a pas eu lieu. Pour les flux Tier 1, l’alerte devrait être considérée comme critique. |
|---|
Le double besoin de monitoring et les zones où les responsabilités se perdent
Toute intégration transitant par un middleware nécessite du monitoring à deux endroits : sur le système émetteur et sur le hub. Le système émetteur confirme que le message a été transmis. Le hub confirme qu’il a été traité et livré. Aucune de ces deux confirmations n’est suffisante à elle seule.
Dans la majorité des organisations, ces deux points sont gérés par des équipes différentes. L’équipe SAP Basis ou SAP Operations monitore le côté SAP. Une équipe middleware, BTP Operations ou infrastructure monitore le hub. Lorsqu’un message échoue quelque part entre les deux, l’investigation oblige les équipes à consulter leurs outils de monitoring respectifs, comparer les timestamps et les identifiants de messages, puis reconstituer la séquence de l’incident de part et d’autre de la frontière technique.
Le véritable angle mort apparaît lorsque les deux environnements de monitoring ne partagent pas un identifiant commun pour chaque message. Sans correlation ID conservé depuis le système SAP émetteur jusqu’au système cible en passant par le middleware, rapprocher un événement SAP d’un événement côté hub nécessite de comparer manuellement les timestamps et les différentes traces. Cette méthode est lente et sujette aux erreurs, particulièrement sous la pression d’un incident.
La décision d’architecture permettant d’éliminer ce problème consiste à imposer un correlation ID dès le point d’origine de chaque message. Le système SAP génère ou inclut un identifiant unique dans le payload. Le middleware conserve cet identifiant dans ses logs de traitement. Le système cible le reprend dans les accusés de réception au niveau applicatif. En cas d’erreur, chaque équipe peut alors rechercher le même identifiant dans tous les outils de monitoring et retrouver immédiatement les événements correspondant à chaque étape du traitement.
Échecs de transformation : livraison réussie, résultat métier incorrect
La transformation des messages dans le middleware, par exemple la conversion d’un IDoc en payload REST, le mapping de noms de champs entre deux systèmes ou la restructuration de données hiérarchiques, introduit un type d’erreur que ni le système SAP émetteur ni le système destinataire ne détectent automatiquement.
La transformation est exécutée dans le middleware. Si elle produit un résultat syntaxiquement valide mais sémantiquement incorrect, le message est tout de même livré avec succès et le système cible peut le traiter sans générer d’erreur. Le résultat métier, lui, est incorrect.
Prenons l’exemple d’un IDoc de commande dans lequel une erreur de mapping entraîne la copie de la quantité dans le champ du prix. Le bon de commande créé possède une structure parfaitement valide, mais des valeurs incorrectes. Le middleware et le système cible signalent tous les deux un succès. L’erreur n’apparaît que lorsqu’un utilisateur remarque que le prix est exactement égal à la quantité commandée, ce qui est manifestement incohérent.
Détecter ce type de problème nécessite une validation du payload au niveau du middleware. Il faut vérifier que les données transformées contiennent des valeurs conformes aux valeurs et plages attendues, et pas seulement que la transformation s’est exécutée sans erreur technique.
Cette exigence de monitoring doit apparaître dans les spécifications d’architecture du hub d’intégration. Elle ne devrait pas être découverte après le premier incident en production.
SAP Integration Suite : l’interface de monitoring que la plupart des équipes sous-exploitent
SAP Integration Suite sur BTP propose une vue Operations qui affiche le statut du traitement des messages, les résultats d’exécution des flows et les logs d’erreur. C’est l’outil adapté pour monitorer les integration flows hébergés sur BTP. Pourtant, la plupart des équipes SAP Basis disposent au mieux d’un accès en lecture seule et ne l’utilisent pas réellement dans un contexte opérationnel quotidien.
L’API OData d’Integration Suite est plus intéressante encore pour le monitoring des intégrations. Elle expose sous une forme exploitable par machine le statut du traitement des messages, les statistiques d’exécution des flows et les volumes d’erreurs. Une plateforme de monitoring configurée pour interroger l’API Integration Suite toutes les minutes et déclencher une alerte lorsque le taux d’erreur d’un flow donné dépasse un seuil fournit la visibilité temps réel côté hub qu’une consultation manuelle de la vue Operations ne peut pas offrir.
La configuration nécessite des identifiants de client API dans le sous-compte BTP avec les droits nécessaires au monitoring des messages, un endpoint pour l’API de management d’Integration Suite et une plateforme de monitoring capable d’interroger des API REST.
La plupart des outils de monitoring SAP n’intègrent pas cette connexion nativement. C’est l’une des raisons pour lesquelles la vue Operations reste souvent un outil consulté manuellement plutôt qu’une véritable source d’alertes. L’intégration de l’API change complètement cette situation.
| À noter : lorsqu’Integration Suite est utilisée parallèlement à une plateforme middleware tierce comme MuleSoft ou Boomi pour certains scénarios d’intégration, le monitoring doit couvrir les deux plateformes indépendamment. Un environnement dans lequel certains flux transitent par Integration Suite et d’autres par une solution tierce nécessite une couverture de monitoring sur chaque plateforme ainsi que des correlation IDs permettant de retracer un message d’une plateforme à l’autre lorsqu’un même processus métier traverse plusieurs solutions. |
|---|
Les décisions d’architecture qui rendent le monitoring réellement possible
Les conséquences d’une architecture de hub d’intégration sur le monitoring sont largement déterminées par les décisions prises pendant la phase d’architecture, bien avant la phase d’exploitation. Trois décisions ont un impact particulièrement important sur la couverture du monitoring.
Premièrement, standardisez autant que possible une plateforme d’intégration principale pour la majorité des flux SAP, plutôt que de laisser chaque équipe projet introduire son propre middleware. Une architecture dans laquelle les intégrations reposent sur cinq plateformes différentes nécessite cinq approches de monitoring, cinq configurations d’alertes et cinq circuits d’escalade différents. La consolidation n’a pas besoin d’être immédiate ni absolue, mais elle doit constituer une direction clairement définie. Toute nouvelle intégration qui s’écarte de la plateforme standard devrait nécessiter une justification explicite.
Deuxièmement, définissez clairement les responsabilités de monitoring dans le document d’architecture de l’intégration. Qui monitore le système SAP émetteur ? Qui monitore le hub ? Qui monitore le système destinataire ? Qui doit être contacté lorsqu’un message échoue pendant son transit ?
Ces questions ont des réponses opérationnelles qui doivent être établies avant le premier incident en production, et non pendant celui-ci.
Troisièmement, imposez les alertes sur les DLQ et l’implémentation d’un correlation ID comme critères obligatoires pour chaque nouvelle intégration. Ils ne doivent pas être considérés comme des fonctionnalités facultatives. Leur mise en œuvre n’est pas particulièrement complexe. Pourtant, ces éléments sont régulièrement oubliés parce qu’ils ne figurent pas dans les exigences fonctionnelles qui déterminent les délais d’un projet.
Les intégrer aux critères d’acceptation d’une intégration, au même titre que les exigences fonctionnelles métier, permet de s’assurer qu’ils sont mis en œuvre avant le go-live et non ajoutés après le premier échec silencieux.
Une architecture middleware conçue avec ces trois principes n’éliminera pas les incidents d’intégration. En revanche, lorsqu’un incident se produira, la couche de monitoring disposera des données nécessaires pour le détecter rapidement et l’organisation saura qui doit intervenir. Dans un environnement SAP complexe, c’est l’objectif réaliste d’un bon monitoring des intégrations.
Redpeaks monitore les métriques d’interface côté SAP, notamment les statuts IDoc, la profondeur des files RFC et l’état des qRFC. Redpeaks prend également en charge l’intégration des données provenant des API Operations de BTP afin d’apporter une visibilité de bout en bout sur les intégrations, y compris au-delà de la frontière middleware.
