Serveur d'impression

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

Le 5 mai 2020 - 10 minutes de lecture

Objectif

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

Aperçu

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.

Contexte de l'initialisation SIA et CMS.

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. Lors de l'initialisation du CMS, il créera plusieurs connexions à la base de données du CMS (14 par défaut)
  2. En revanche, il ne fera qu'une seule connexion avec la base de données d'audit.
  3. Il se liera ensuite au port et demandera les ports définis (ou un port de requête aléatoire s'il n'est pas configuré)

Audit de l'opération en arrière-plan:

1. Chaque fois que le CMS démarre et lorsqu'il établit la connexion à la base de données d'audit, il entre / vérifie par défaut toutes les tables et tous les index par défaut.
2. Les tables de recherche sont les tables standard qui contiennent généralement des données statiques. (par exemple, ID client standard pour Webi, liste de tous les serveurs du cluster, recherches pour faire correspondre l'ID de type d'événement avec une chaîne (par exemple 1006 = Supprimer)
3. Il vérifie et les tableaux à chaque démarrage du CMS.
4. Par défaut, voici à quoi ressemblent les tableaux pour l'audit (tous sauf pour COMMENTARY_MASTER qui est destiné au service de commentaire)

Processus d'audit

Un seul CMS écrit les événements d'audit dans la base de données d'audit. C'est ce qu'on appelle l'auditeur – l'auditeur actuel peut être vu dans CMC -> Audit (voir ci-dessous)

    • Un serveur BO qui génère les événements est un audité – tous les serveurs BO sont audités
    • Un CMS qui est un auditeur est à la fois l'auditeur et un audité
    • Si ce CMS est arrêté ou perd la connexion à la base de données d'audit, un autre CMS prendra le rôle d'auditeur.
    • Les informations de connexion à la base de données d'audit, la période de conservation et les types d'événements à auditer, ainsi que les détails supplémentaires requis – tels que les instructions SQL pour l'actualisation des rapports – sont définis dans la page CMC-> Audit
    • En fonction des événements sélectionnés, les serveurs responsables de cet événement capturent les événements sous forme de fichier .txt dans le répertoire d'audit sur leur machine locale.
    • Par défaut, le chemin du répertoire d'audit, où sont stockés les fichiers d'audit intermédiaires, serait: C: Program Files (x86) SAP BusinessObjects SAP BusinessObjects Enterprise XI 4.0 Auditing.
    • La convention de dénomination est la forme de: audit (sous forme hexadécimale) donc tous les fichiers créés par le même serveur BO commenceront toujours par le même jeu de caractères. Vous trouverez ci-dessous un exemple de nom de fichier généré par l'audit (notez que les 5 premiers fichiers commencent tous par la même chaîne afin qu'ils soient générés par le même serveur de BI).

Pour vérifier quel CMS dans un cluster BI est un auditeur, nous pouvons vérifier les détails à partir de la page CMC -> Audit

Flux de travail en détail:

  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.

Commentaires

Laisser un commentaire

Votre commentaire sera révisé par les administrateurs si besoin.