Skip to Content
Technical Articles
Author's profile photo Rajdeep Marathe

SAP BusinessObjects Business Intelligence Platform Auditing Application Background Process

This Blog post contains Details on the background of Auditing Application.


Below are some basics of the auditing application and the CMC> Auditing page details.

  • Only one CMS will write audit events to the Audit database. This is called the Auditor – the current auditor can be seen in CMC -> Auditing (see below)
  • A BO server that is generating the events is an Auditee – all other BO servers are Auditee’s
  • A CMS which is an auditor is both the auditor and an Auditee
  • Just in case the CMS which is stopped/ down or loses connection to the Audit database, another CMS will take over the auditor role.
  • To check which CMS in a BI cluster is an auditor, we can check the details from the CMC -> Auditing Page

  • The Audit database connection information, retention period and types of event to be audited, plus extra required detail – such as SQL statements for report refresh – is defined in the CMC->Auditing page
  • Based on the events which have been selected, the servers responsible for that event capture the events in the form of .txt file in the Auditing directory on their local machine.
  • By default the path for Auditing directory, where intermediate auditing files are stored, would be: C:\Program Files (x86)\SAP BusinessObjects\SAP BusinessObjects Enterprise XI 4.0\Auditing.

Naming Convention:

  • The naming convention is the form of: audit<EncodedServerName><Event_ID> (in hexadecimal form).
  • Therefore all files created by the same BO server will always start with the same set of characters. Below is an example of file name generated by auditing (Note that the first 5 files all start with the same string so they are generated by the same BI server).


Workflow in Detail:

  1. Each individual server will write its own Auditing information into a temporary file on its local machine (these are what we find in the Auditing folder on each node)
  2. The Auditor CMS maintains a list of all the registered (running) servers.
  3. This Auditor CMS sends request to the first registered server in the list: Send me any events that are currently waiting to be written to the Auditing Database.
  4. The server acknowledges the request and then sends all the audit events and details which need to be written (the Auditee will read back the data in the auditing files it previously wrote in the Auditing folder)
  5. The Servers for eg: Webi processing server, looks for each event from the .txt files and then sends the details to the CMS in a structured format. All servers will send any event to the CMS using the same ‘standard’ structure.
  6. Auditor CMS then processes each of the events returned in order.


If the event already exists in the auditing DB, the event is skipped and the auditor moves onto the next event.

The Auditor checks if the object related to the event (e.g. the refresh Webi report or the user that is logging in) still exists in the CMS repository (or it’s been deleted already).

If the object if found in the CMS repository, the data is used to turn the CUID of the object (which is all that is stored when the audit event is written to the Auditing folder) into the real object name and folder path within BO.


Assigned Tags

      Be the first to leave a comment
      You must be Logged on to comment or reply to a post.