SAP BusinessObjects Business Intelligence: workflow détaillé de la fonction d'audit – Business Intelligence (BusinessObjects) – Serveur d’impression

Le but de cette page est de clarifier la compréhension de la fonction d'audit et du flux de travail détaillé.

L'audit vous permet de conserver un enregistrement des événements importants sur les serveurs et les applications, ce qui vous donne une image des informations auxquelles vous accédez, comment elles sont consultées et modifiées, et qui effectue ces opérations. Ces informations sont enregistrées dans une base de données appelée Auditing Data Store (ADS). Une fois les données dans l'ADS, vous pouvez concevoir des rapports personnalisés en fonction de vos besoins.

Au démarrage du SIA:

1. Il vérifiera d'abord tous les CMS du cluster pour voir s'ils fonctionnent.
2. Si l'un est en cours d'exécution, il récupérera la liste des serveurs et leurs lignes de commande (y compris le CMS local s'il y en a un) et les démarrera.
3. Si aucun CMS n'est en cours d'exécution, le SIA démarrera le CMS local. Lorsque le CMS est initialisé, le SIA récupère la liste des serveurs qui lui sont liés, ainsi que leurs lignes de commande, puis les démarre (à l'exception du CMS qui est déjà en cours d'exécution).

Lorsque CMS est démarré:

1. Chaque serveur individuel écrira ses propres informations d'audit dans un fichier temporaire sur sa machine locale (c'est ce que nous trouvons dans le dossier d'audit sur chaque machine.
2. Le CMS Auditor conserve une liste de tous les serveurs enregistrés (en cours d'exécution).
3. Ce CMS d'auditeur envoie une demande au premier serveur enregistré de la liste: Envoyez-moi tous les événements en attente d'écriture dans la base de données d'audit.
4. Le serveur accuse réception de la demande, puis envoie tous les événements d'audit et les détails qui doivent être écrits (l'audité lira les données dans les fichiers d'audit qu'il a précédemment écrits dans le dossier d'audit)
5. Le serveur pour ex: serveur de traitement Webi, recherche chaque événement à partir des fichiers .txt, puis envoie les détails au CMS dans un format structuré. Tous les serveurs enverront tout événement au CMS en utilisant la même structure «standard».
6. Auditor CMS traite ensuite chacun des événements retournés dans l'ordre.
   1. Si l'événement existe déjà dans la base de données d'audit, l'événement est ignoré et l'auditeur passe à l'événement suivant.
   2. L'auditeur vérifie si l'objet lié à l'événement (par exemple le rapport d'actualisation Webi ou l'utilisateur qui se connecte) existe toujours dans le référentiel CMS (ou s'il a déjà été supprimé).
   3. Si l'objet se trouve dans le référentiel CMS, les données sont utilisées pour transformer le CUID de l'objet (qui est tout ce qui est stocké lorsque l'événement d'audit est écrit dans le dossier d'audit) en nom d'objet réel et chemin d'accès au dossier dans BO.
   4. Comme il y a toujours un délai entre l'événement d'audit et sa transmission à la base de données d'audit, il est toujours possible que l'objet référencé n'existe plus et que cette information se connecte.
   5. Dans le cas où l'objet n'existe pas dans le référentiel CMS et plus longtemps (il a été supprimé depuis la création de cet événement), soit l'événement de suppression aura été inséré, soit il ne l'a pas encore été (mais le sera bientôt).
      1. L'auditeur vérifie la base de données d'audit pour voir si un événement de suppression existe dans la base de données – s'il le fait, il copie le nom et le chemin du dossier de l'événement d'audit de suppression dans la base de données et l'utilise.
      2. S'il n'existe pas (encore) dans la base de données d'audit, il écrira l'ID d'événement et le CUID de l'objet dans la table INCOMPLETE_EVENT de la base de données d'audit.
      3. Lorsque l'événement de suppression arrive, il vérifie si des événements l'attendent (c'est-à-dire en regardant les entrées de la table INCOMPLETE_EVENT pour tous les événements avec le même CUID) et remplira ensuite les détails des événements manquants avant d'insérer l'événement de suppression .

Par exemple:
1. Si le rapport nommé (abc) a un événement View. Il vérifiera si le rapport ABC (objet) est présent dans la base de données CMS et prendra ensuite des mesures en conséquence.
2. Une fois qu'il a trouvé l'objet (rapport), il écrit les détails dans la base de données d'audit avec l'événement associé.
3. Une fois les détails écrits dans la base de données d'audit, le CMS demandera aux serveurs de supprimer le fichier .txt qu'il avait audité.

Toutes les 3 minutes, le CMS interroge tour à tour les données de chaque serveur. Il s'agit d'un cycle d'interrogation.

L'utilisation des unités d'exécution indiquée dans la page CMC-> Audit est la suivante:

• • • • Temps nécessaire pour effectuer le cycle d'audit * 100 / Durée du dernier cycle d'interrogation = Utilisation du thread d'audit (%)
      • La «Durée du dernier cycle d'interrogation» est de 180 secondes ou le temps nécessaire pour effectuer le cycle d'audit (la plus longue des deux). Cela signifie que l'utilisation du thread d'audit (%) ne peut jamais être> 100%

Notez que l'utilisation du thread d'audit n'est PAS liée à l'utilisation du processeur du thread d'audit – elle est juste liée au temps qu'il faut

• • • • Lorsque nous voyons 100% d'utilisation des threads sur la page d'audit, cela signifie: que le CMS a pris 3 minutes ou plus pour terminer le cycle précédent. (Le problème peut être n'importe où, obtenir des détails des serveurs, envoyer les détails à la base de données d'audit ou au CMS en attente de toute opération) – par exemple grand nombre d'événements à importer, accès à la base de données d'audit lent (en lecture ou en écriture), performances du réseau, etc.
      • S'il y a un problème lors du traitement des événements d'audit d'un des serveurs, l'auditeur passera ensuite au serveur suivant (il ne supprimera pas les fichiers dans l'événement de dossier d'audit s'il en a inséré certains).
      • S'il n'y a aucune donnée à écrire et aucun événement d'audit déclenché depuis le dernier cycle d'interrogation, il invite toujours le serveur à partager les données à écrire. Et le serveur répond sans données à écrire.

Vérifiez ci-dessous le INCOMPLETE_EVENT:

• • • • La prochaine fois que le CMS recevra un événement de suppression.
      • Le CMS vérifiera dans la table INCOMPLETE_EVENT pour voir si un événement incomplet a été stocké.
      • Et puis écrivez-le dans la base de données.
      • Plus tard, il supprime l'entrée pour INCOMPLETE_EVENT

TRACÉ

1. Définissez le niveau de suivi sur Moyen
2. Idéalement, nous pouvons capturer les détails du CMS pour l'audit sur la priorité Moyenne
3. Modifiez le paramètre keep_num à 50 ou plus. De SAP BusinessObjects SAP BusinessObjects Enterprise XI 4.0 conf BO_trace.ini
4. Une fois que nous avons les journaux, redéfinissez le niveau de suivi sur non spécifié et le keep_num sur la valeur par défaut.