Un contrôleur financier ouvre le tableau de bord des revenus chaque matin à 07h30. Le rapport est toujours là, toujours alimenté, toujours basé sur les données de la veille. Jusqu’au mercredi où il est bien présent, mais vide. Aucun message d’erreur. L’instance planifiée affiche le statut Success dans la Central Management Console. Le rapport s’est exécuté, mais il n’a livré aucune donnée. La connexion à la source de données a expiré pendant l’exécution, la requête a renvoyé zéro ligne et BusinessObjects a considéré cela comme une exécution réussie.
Ce scénario n’a rien d’exceptionnel. Il illustre parfaitement ce qui se passe lorsque le monitoring BusinessObjects est mal pensé : le système indique un succès au niveau technique, alors qu’il livre un échec au niveau métier. La planification s’est lancée. Le rapport est disponible. Le tableau de bord est vide.
BusinessObjects occupe une place dans le paysage SAP qui le rend facile à sous-superviser. Ce n’est pas un système transactionnel. Ses incidents ne bloquent pas immédiatement les processus métier comme le ferait une panne SAP ERP. Les problèmes s’accumulent : rapports qui cessent silencieusement de s’exécuter, utilisateurs qui ne reçoivent plus les publications prévues, temps de rendu qui ont doublé en six mois. Lorsque le problème arrive enfin jusqu’à une personne capable de le corriger, il existe souvent depuis plusieurs semaines.
Cet article présente le monitoring qui permet réellement de détecter ces défaillances : les éléments à surveiller dans la couche de planification, la manière d’interpréter l’état des services au-delà de ce que montre la CMC, les métriques d’expérience utilisateur vraiment utiles et les sources de données de monitoring les plus précieuses dans un environnement BOBJ, souvent déjà disponibles mais rarement exploitées.
Pourquoi le monitoring BusinessObjects est différent du monitoring des serveurs d’applications SAP ?
La CMC est une console d’administration, pas un outil de monitoring
La plupart des administrateurs BOBJ utilisent la Central Management Console comme vue opérationnelle principale. Elle affiche l’état des services, les instances de jobs planifiés récentes, les sessions utilisateurs et la configuration système. C’est le bon outil pour administrer l’environnement. Ce n’est pas un outil conçu pour le monitoring continu.
La CMC montre l’état actuel, pas l’historique. Un service qui a planté puis redémarré à 03h00 apparaît comme Running à 09h00, sans trace visible du redémarrage, sauf si l’administrateur sait qu’il doit consulter la base d’audit ou les logs serveur. Un rapport planifié qui a produit un résultat vide apparaît dans l’historique des instances avec un indicateur vert Success. Un rapport qui échoue silencieusement une exécution sur deux depuis deux semaines affiche un mélange d’entrées Success et Failed dans l’historique, et le taux de réussite global n’est visible que si quelqu’un le calcule manuellement.
Un monitoring externe qui interroge en continu l’état des services BOBJ, les résultats des instances de jobs et la consommation des ressources système fait ce que la CMC ne peut pas faire : enregistrer la séquence des états dans le temps, corréler les événements entre plusieurs services et générer des alertes lorsque les conditions s’écartent de la normale, au lieu d’exiger une vérification manuelle.
L’état d’un service et sa santé réelle ne sont pas la même chose
BusinessObjects est composé de plusieurs services serveur : le Central Management Server (CMS), les File Repository Servers (FRS d’entrée et de sortie), l’Adaptive Processing Server (APS), le Web Intelligence Processing Server, le Crystal Reports Processing Server, l’Adaptive Job Server, le Connection Server et plusieurs autres selon la version et les modules déployés. Chaque service possède un état visible dans la CMC : Running, Stopped, Failed.
Running signifie que le processus du service est actif et répond au CMS. Cela ne signifie pas que le service traite correctement les requêtes. Un Adaptive Job Server en état Running, mais dont le pool de threads de traitement est saturé, ne prendra pas en charge les nouveaux jobs planifiés. Les nouveaux jobs s’empilent derrière les jobs existants, sans indication d’erreur sur le service lui-même. Un Web Intelligence Processing Server en état Running, mais sous pression mémoire, traitera les demandes de rapports lentement sans afficher d’état anormal dans la CMC.
La santé d’un service, distincte de son état, nécessite des métriques qui vont au-delà de la disponibilité du processus : profondeur de file d’attente par service, nombre de sessions actives, consommation mémoire par processus de service et taux d’erreur sur les requêtes entrantes. Ces métriques sont disponibles via l’API REST BOBJ et via la base d’audit. Elles ne sont pas visibles dans l’affichage d’état des services de la CMC. Une approche de monitoring limitée à l’état des services indiquera un système sain dans des conditions que les utilisateurs perçoivent pourtant comme lentes ou indisponibles.
Monitoring de la couche de planification : aller au-delà du statut réussite ou échec
Ce que signifie réellement le statut Success d’une instance planifiée
Un rapport BusinessObjects planifié atteint le statut Success lorsque le programme du rapport s’exécute sans générer d’exception et que le fichier de sortie est écrit dans le File Repository Server. Aucune de ces deux conditions n’exige que le rapport contienne des données. Un rapport dont la requête renvoie zéro ligne parce que la source de données a retourné un jeu de résultats vide se termine avec le statut Success. Un rapport dont la connexion à la source de données a expiré après trois tentatives, puis a réussi à la quatrième en produisant des données partielles, se termine également avec le statut Success si l’exécution finale ne génère pas d’exception.
Pour les rapports utilisés comme tableaux de bord opérationnels ou synthèses de direction, la différence entre un succès technique et une livraison réellement exploitable fait toute la différence entre un monitoring efficace et un monitoring qui indique ce que les utilisateurs savent déjà être faux. Une sortie à zéro ligne dans un rapport qui contient normalement des centaines de lignes est un échec de livraison. Pour le détecter, il faut monitorer le résultat produit, pas seulement l’exécution.
Le contrôle est assez simple pour les rapports dont la taille de sortie attendue est connue : comparer le nombre de lignes ou la taille du fichier de l’instance actuelle avec la moyenne historique du même rapport, au même horaire de planification. Un rapport qui produit normalement une sortie de 2 Mo et qui produit aujourd’hui 4 Ko ne constitue pas une livraison réussie, peu importe ce qu’indique le statut d’instance dans la CMC. Cette comparaison nécessite un accès aux métadonnées des fichiers de sortie FRS et aux enregistrements historiques d’exécution de la base d’audit, mais elle peut être mise en place sans développement spécifique.
Rapports à zéro ligne : l’échec silencieux que personne ne détecte
Les sorties à zéro ligne sont plus fréquentes que ne le pensent la plupart des administrateurs BOBJ, car elles sont invisibles pour la couche de monitoring standard. Elles apparaissent souvent selon des schémas précis. Délais d’expiration de connexion aux sources de données, avec des tentatives qui finissent par réussir, mais trop tard pour récupérer des données exploitables. Paramètres de filtre de date dans les requêtes qui étaient corrects lors de la création de la planification, mais qui ont dérivé avec le temps. Filtres d’univers ou de panneau de requête qui font référence à une invite dont la valeur par défaut ne correspond plus à aucune donnée.
L’approche de monitoring la plus pratique consiste à maintenir des plages de taille de sortie attendues pour les rapports de niveau 1, c’est-à-dire les rapports sur lesquels les parties prenantes métier s’appuient activement. Pour un rapport de ventes hebdomadaire, une plage attendue de 500 à 2 000 lignes, basée sur l’historique d’exécution, permet de détecter à la fois l’échec à zéro ligne et le résultat anormalement faible qui peut indiquer une récupération partielle des données. Toute exécution en dehors de cette plage doit être signalée pour analyse.
Il n’est pas nécessaire de monitorer tous les rapports de l’environnement avec ce niveau de détail. Il faut identifier les 20 à 30 rapports qui provoqueraient une escalade métier immédiate s’ils livraient des données vides ou incorrectes, puis appliquer le contrôle de taille de sortie spécifiquement à ces rapports. Les 80 % de rapports restants, souvent des requêtes opérationnelles à faible enjeu, n’ont pas besoin de ce niveau de surveillance.
Les planifications récurrentes qui cessent silencieusement de se répéter
Les planifications récurrentes BusinessObjects dépendent du CMS d’une manière facile à perturber. Un rapport planifié pour s’exécuter tous les jours à 06h00 repose sur l’Adaptive Job Server, qui doit récupérer l’instance en attente à l’heure prévue. Si l’Adaptive Job Server a été arrêté ou redémarré à 05h55 et n’était pas pleinement opérationnel à 06h00, l’instance peut ne pas avoir été créée. La prochaine exécution prévue est alors le lendemain à 06h00. La planification n’a pas échoué. Rien dans la CMC n’indique un problème. Le rapport ne s’est simplement pas exécuté.
Un redémarrage de service qui chevauche une fenêtre d’exécution planifiée crée un trou invisible, sauf si l’exécution attendue est monitorée par rapport à son horaire prévu. Un monitoring qui vérifie si une planification spécifique a produit une nouvelle instance dans une fenêtre définie après l’heure d’exécution prévue permet de détecter ce manque. Une planification configurée à 06h00 qui n’a produit aucune nouvelle instance à 06h15 doit générer une alerte, quel que soit l’état affiché des services.
La version la plus insidieuse est une planification mise en pause par un administrateur pendant une fenêtre de maintenance et jamais réactivée. La planification existe dans la CMC en état paused. Le rapport a été exécuté pour la dernière fois il y a trois semaines. Personne ne l’a remarqué, soit parce que la liste de distribution n’a pas réclamé, soit parce que l’absence du rapport n’a pas encore eu d’impact visible sur un processus métier.
Attention : la distribution basée sur les publications dans BusinessObjects ajoute une couche de modes de défaillance que le seul monitoring des planifications ne détecte pas. Une publication peut s’exécuter avec succès, générer les instances de rapports et échouer silencieusement à l’étape de distribution si le serveur SMTP est indisponible ou si les adresses email de destination sont invalides. Il est nécessaire de monitorer séparément le statut de l’instance de publication et le statut de génération du rapport pour confirmer que la livraison, et pas seulement la génération, a bien abouti.
Monitoring des services serveur : les composants qui déterminent la disponibilité des rapports
Disponibilité du CMS et cascade qu’il contrôle
Le Central Management Server est le hub d’authentification et de métadonnées de tout l’environnement BusinessObjects. Chaque connexion utilisateur, chaque accès à un rapport, chaque création d’instance de job planifié passe par le CMS. Un CMS indisponible ou dégradé ne produit pas des pannes partielles : il rend le système totalement inaccessible pour tous les usages.
Le monitoring de la disponibilité du CMS est le contrôle le plus critique dans un paysage BOBJ. Mais la disponibilité seule ne permet pas de détecter l’état dégradé qui précède souvent une panne CMS. Un CMS sous pression mémoire traite les demandes d’authentification plus lentement. Les temps de connexion passent de moins d’une seconde à plusieurs secondes. L’ouverture des rapports prend plus de temps que d’habitude, car les requêtes de métadonnées CMS sont lentes. Le système est techniquement disponible. Les utilisateurs vivent pourtant une expérience qui ressemble à une indisponibilité.
Les métriques CMS à surveiller en continu sont la consommation mémoire par rapport au heap Java configuré, le nombre de connexions actives à la base de référentiel CMS et les temps de réponse des demandes d’authentification lorsqu’ils sont accessibles via l’API REST. Un CMS qui fonctionne à 85 % de son heap déclenchera des cycles de garbage collection susceptibles de suspendre temporairement le traitement des authentifications. L’épuisement du pool de connexions empêche l’ouverture de nouvelles sessions. La dégradation du temps de réponse CMS est un indicateur avancé de problèmes de disponibilité à venir.
Adaptive Processing Server et Adaptive Job Server : capacité et profondeur de file d’attente
L’Adaptive Processing Server gère le traitement des documents, l’indexation de recherche et plusieurs types de rapports selon la version déployée. L’Adaptive Job Server gère l’exécution des jobs planifiés : il récupère les instances en attente, les affecte aux serveurs de traitement appropriés et suit leur exécution.
La profondeur de file d’attente sur l’Adaptive Job Server est la métrique qui révèle les problèmes de capacité de planification avant qu’ils n’affectent les délais de livraison. En conditions normales, les instances de jobs en attente sont récupérées et lancées quelques secondes après l’heure planifiée. Lorsque la capacité de traitement de tous les serveurs connectés est entièrement occupée, les nouvelles instances restent dans la file d’attente. Les utilisateurs dont les rapports étaient planifiés à 06h00 les reçoivent à 07h15, parce que la file ne s’est vidée qu’à 07h14.
Ni le retard de livraison ni la profondeur de file ne sont visibles dans l’interface standard de la CMC, sauf si l’administrateur ouvre la vue de la file de jobs et compte manuellement les instances en attente. Un monitoring externe qui interroge régulièrement la profondeur de file du job server et génère une alerte lorsque les instances en attente s’accumulent apporte la visibilité que les contrôles manuels ne peuvent pas garantir dans un environnement de production.
Connection Server et couche source de données
Le BusinessObjects Connection Server gère les connexions de base de données entre les rapports et les sources de données sous-jacentes. Il maintient des pools de connexions pour chaque connexion configurée, gère les tentatives de reprise et fournit la couche d’abstraction de connexion qui permet aux rapports de s’exécuter, quel que soit le serveur de base de données physique actif.
Les défaillances du Connection Server produisent un schéma précis : plusieurs rapports partageant la même connexion à une source de données commencent à échouer simultanément avec des erreurs de connexion base de données. La panne est concentrée sur une source de données, et non répartie de manière aléatoire dans l’ensemble du paysage de rapports. Ce schéma de concentration pointe vers le Connection Server ou la source de données elle-même, plutôt que vers un problème spécifique à un rapport.
Les métriques à surveiller sur le Connection Server sont les taux d’erreur de connexion par nom de connexion, le nombre de connexions actives par rapport au maximum du pool et le temps moyen d’exécution des requêtes par connexion. Lorsque le nombre de connexions actives approche le maximum du pool, les nouvelles exécutions de rapports devront attendre qu’une connexion se libère. Une connexion dont le temps moyen de requête a doublé au cours de la semaine précédente n’est pas encore en panne, mais elle montre une dégradation de santé de la source de données qui précède souvent les incidents.
Métriques d’expérience utilisateur : temps de rendu, sessions et cache
Le temps de rendu des rapports comme signal de qualité de service
Il existe une différence importante entre un rapport qui s’exécute en 12 secondes et un rapport qui s’exécute en 45 secondes, même si les deux restent acceptables pour un utilisateur isolé. Le rapport de 45 secondes occupe un slot de traitement sur le Web Intelligence Processing Server presque quatre fois plus longtemps, ce qui réduit la capacité disponible pour les autres utilisateurs simultanés. Si 10 utilisateurs demandent le même rapport lent en même temps, le serveur de traitement est occupé pendant une durée équivalente à celle de 40 rapports similaires à la référence de 12 secondes.
Le temps de rendu par rapport, suivi dans le temps, est la métrique qui permet de détecter les régressions de performance avant qu’elles ne créent des problèmes de capacité visibles. Un rapport Web Intelligence qui s’affichait en 8 secondes le trimestre dernier et prend désormais systématiquement 25 secondes a subi une régression quelque part : modification d’univers ayant introduit une requête moins efficace, croissance du volume de données ayant dépassé un seuil dans le plan de requête, index de base de données supprimé ou reconstruit de manière incorrecte. Détecter cette régression tôt, avant qu’elle ne crée des problèmes de capacité en aval, nécessite des données historiques de temps de rendu.
La base d’audit enregistre le temps d’exécution de chaque instance de rapport. Exploiter ces données pour suivre les tendances par rapport, plutôt que de regarder les temps de rendu moyens sur l’ensemble de l’environnement, permet d’identifier les rapports spécifiques dont les performances se sont dégradées. Les moyennes globales de rendu sur des centaines de rapports sont dominées par quelques rapports très rapides et quelques rapports très lents. Elles changent peu, même lorsque certains rapports individuels se sont fortement dégradés.
Utilisation des licences : la métrique qui provoque des blocages silencieux
Dans la plupart des déploiements d’entreprise, la licence BusinessObjects repose soit sur des licences utilisateurs nommés, soit sur des licences d’accès concurrent. Dans le premier cas, chaque utilisateur dispose d’une licence dédiée. Dans le second, un pool de licences est partagé entre tous les utilisateurs, avec une limite fixée par le nombre de sessions simultanées. Les deux modèles ont un plafond, et lorsque ce plafond est atteint, le comportement est silencieux.
Pour les licences d’accès concurrent, lorsque le nombre de sessions atteint le maximum autorisé, les nouveaux utilisateurs qui tentent de se connecter reçoivent un message indiquant qu’aucune session n’est disponible. Ils ne peuvent pas se connecter. Aucune alerte n’est envoyée à l’administrateur BOBJ, aucun email, aucun événement de monitoring. L’administrateur découvre le problème lorsqu’un utilisateur escalade. À ce moment-là, un nombre inconnu d’utilisateurs a déjà été empêché de se connecter pendant une durée inconnue.
Monitorer le nombre de sessions concurrentes par rapport à la limite de licence, avec une alerte à 80 % du maximum, donne le temps de demander une extension de licence d’urgence ou d’analyser si des sessions obsolètes consomment des licences sans utilisateur actif. Les sessions obsolètes, issues d’utilisateurs ayant fermé leur navigateur sans se déconnecter correctement, sont fréquentes dans les environnements BOBJ et s’accumulent avec le temps si la configuration du délai d’expiration de session n’est pas correctement définie.
Pour les licences utilisateurs nommés, le risque est différent : ajouter de nouveaux utilisateurs sans vérifier la capacité de licence restante. Une organisation qui a acheté 500 licences utilisateurs nommés et en a provisionné 498 dispose de très peu de marge pour ajouter des prestataires, des travailleurs temporaires ou de nouveaux membres d’équipe sans lancer un cycle d’achat de licences. Le monitoring du nombre d’utilisateurs provisionnés par rapport à la limite de licence permet de détecter ce risque avant d’atteindre le plafond.
Performance du cache et pourquoi les données obsolètes sont un problème de monitoring
Web Intelligence et d’autres types de rapports BusinessObjects prennent en charge un mécanisme de cache : les données d’un rapport récemment exécuté sont stockées dans le cache, et les demandes suivantes pour le même rapport sont servies depuis le cache au lieu de relancer la requête en base de données. Ce mécanisme améliore les performances lorsque de nombreux utilisateurs consultent le même rapport et que les données sous-jacentes changent peu.
L’invalidation du cache est précisément l’endroit où le monitoring apporte de la valeur. Un cache de rapport valide à 08h00 peut contenir des données obsolètes à 14h00 si les données sous-jacentes ont été mises à jour, mais que le cache n’a pas été rafraîchi. Les utilisateurs qui consultent le rapport en cache voient des données qui ne reflètent plus la réalité. Ils peuvent prendre des décisions sur cette base. Le système technique fonctionne normalement. L’information métier servie est incorrecte.
Monitorer l’âge du cache par rapport, en le comparant à la fréquence de rafraîchissement des données sous-jacentes, permet d’identifier les rapports susceptibles de fournir des informations obsolètes. Un rapport sur les ventes quotidiennes dont le cache a été rafraîchi pour la dernière fois il y a 36 heures ne fournit pas les données que les utilisateurs attendent lorsqu’ils l’ouvrent pendant les heures de travail. La réponse de monitoring appropriée consiste soit à déclencher une invalidation du cache, soit à alerter le propriétaire du rapport pour ajuster la planification de rafraîchissement.
La base d’audit : la source de monitoring que la plupart des environnements BOBJ ignorent
Ce que contient réellement la base d’audit
SAP BusinessObjects maintient une base d’audit qui enregistre tous les événements significatifs du système : chaque connexion et déconnexion utilisateur, chaque consultation de rapport, chaque début et fin d’exécution de job planifié, chaque envoi de publication, chaque tentative d’authentification échouée, chaque création et suppression de document. Dans la plupart des environnements de production, cette base fonctionne depuis des années et contient un historique opérationnel complet du paysage BusinessObjects.
La base d’audit est utilisée pour le reporting de conformité dans les organisations qui l’exploitent. Elle est presque jamais utilisée pour le monitoring, ce qui représente une opportunité manquée, car elle constitue la source de données opérationnelles la plus riche de l’environnement BOBJ. La plupart des outils de monitoring externes pour BOBJ interrogent l’API REST CMS pour obtenir des informations d’état en temps réel. La base d’audit ajoute la dimension historique que l’API REST ne peut pas fournir : non pas seulement ce qui se passe maintenant, mais ce qui s’est passé et comment cela se compare au fonctionnement normal.
Les tables de la base d’audit les plus pertinentes pour le monitoring sont le journal des événements, avec tous les événements par type, horodatage, utilisateur et statut, le journal d’exécution des jobs, avec les instances planifiées, les horaires, les succès ou échecs et les métadonnées de sortie, ainsi que le journal des sessions, avec les événements de connexion et déconnexion et la durée des sessions. Ces trois tables fournissent ensemble tout ce qui est nécessaire pour un monitoring basé sur les tendances : taux de réussite des planifications, schémas d’activité utilisateur et performance des rapports dans le temps.
Utiliser les données d’audit pour un monitoring proactif
La base d’audit rend possible une catégorie de monitoring que l’interrogation temps réel ne peut pas prendre en charge : la détection d’anomalies basée sur les modèles historiques. Si un rapport spécifique s’exécute chaque jour ouvré à 06h00 depuis 18 mois et ne s’est pas exécuté aujourd’hui, cette absence peut être détectée en interrogeant la base d’audit sur l’exécution attendue. Si un compte utilisateur inactif depuis 90 jours affiche soudainement 200 événements de connexion en 10 minutes, cette anomalie peut être identifiée à partir des données du journal de sessions.
Plus concrètement, la base d’audit permet de calculer les taux de réussite des planifications sur des périodes glissantes. Un rapport avec un taux de réussite de 98 % sur les 30 derniers jours se comporte normalement. Le même rapport à 72 % sur les 7 derniers jours est en dégradation et mérite une analyse avant que le taux d’échec ne devienne suffisamment élevé pour affecter les processus métier qui en dépendent.
Le chemin de mise en œuvre pour un monitoring basé sur la base d’audit consiste à créer une requête planifiée qui extrait des métriques agrégées depuis les tables d’audit et les transmet à une plateforme de monitoring. Ce n’est pas une implémentation technique complexe. Cela nécessite que les identifiants de connexion à la base d’audit soient disponibles pour la plateforme de monitoring et que l’équipe de supervision comprenne quels types d’événements d’audit correspondent à quelles conditions opérationnelles. Cette compréhension est le principal obstacle. Les données sont déjà là.
Remarque : la base d’audit croît en continu avec chaque événement système et nécessite une stratégie de rétention et d’archivage pour rester performante en tant que cible de requêtes. Dans les environnements à forte activité, la table du journal des événements peut atteindre plusieurs centaines de millions de lignes en quelques années. L’interroger sans indexation appropriée ni filtrage par plage de dates produit des requêtes lentes qui concurrencent l’activité normale du système. La plupart des administrateurs BOBJ savent que la base d’audit existe, mais ne l’ont pas maintenue pour une interrogation efficace. Avant de l’utiliser comme source de monitoring, il faut vérifier la stratégie d’indexation et définir une fenêtre de rétention des données qui équilibre profondeur historique et performance des requêtes.
Contre quoi le monitoring BOBJ doit-il protéger ?
BusinessObjects occupe une position spécifique dans le paysage SAP : c’est la couche où les données métier deviennent de l’information métier. Les données transactionnelles générées par les systèmes ERP ne deviennent utiles qu’au moment où une personne peut les voir, les interpréter et agir à partir d’elles. Lorsque les rapports ne s’exécutent pas, s’exécutent lentement ou livrent des données incorrectes, la valeur des systèmes transactionnels sous-jacents est compromise, même si ces systèmes fonctionnent parfaitement.
Le défi du monitoring vient du fait que les défaillances propres à cette couche ne sont pas des pannes d’infrastructure. Un serveur arrêté est évident. Un rapport qui s’exécute, mais livre des données vides, ne l’est pas. Une publication envoyée à la mauvaise liste de destinataires ne l’est pas. Un temps de rendu qui a doublé en trois mois ne l’est pas. Ce sont ces modes de défaillance qui s’accumulent silencieusement dans les environnements BOBJ sans déclencher les alertes d’infrastructure standard.
Les détecter exige un monitoring qui descend sous le simple niveau d’état des services : validation des sorties pour les rapports planifiés critiques, suivi de la profondeur des files d’attente sur les serveurs de traitement, tendances de temps de rendu par rapport, nombre de sessions comparé aux limites de licence et requêtes sur la base d’audit pour révéler les schémas invisibles au polling temps réel. Rien de tout cela n’est difficile à mettre en place. Ce que cela exige, c’est de traiter BusinessObjects comme un système doté de modes de défaillance spécifiques, et non comme un serveur simplement disponible ou indisponible.
Redpeaks supervise les environnements SAP BusinessObjects, notamment la disponibilité des services, les taux de réussite des instances de jobs, les tendances de temps de rendu et l’utilisation des licences, depuis une connexion unique sans agent au paysage BOBJ et aux systèmes SAP sous-jacents. Découvrez la couverture de monitoring BusinessObjects.
