Skip to Content

Welcome to the BI Platform Auditing Blog on SDN. Firstly let me introduce myself, I am Adrian Westmoreland the Product Manager responsible for Auditing within the BI Platform team. This will be an occasional blog giving some insight into the current auditing capabilities offered by the SAP BusinessObjects system.

So let’s get down to business. The best place to start will be to explain how the auditing works in the context of the BI platform.

BI Platform Auditing allows you to keep a record of significant events on BusinessObjects Enterprise servers. These records give you a picture of what information is being accessed, how it’s being accessed, and who is looking at it.

We also need to define a couple of terms when discussing BI Platform auditing. An ‘auditor’ refers to any system responsible for recording or storing information on any auditable event. ‘Auditee’ refers to any system responsible for performing an event that is audited. There are some circumstances where a single system can be both an auditor and auditee. An ‘event’ will be a particular action that has occurred by an auditee, and that is set to be audited.

The Central Management Server (CMS) acts as the system auditor, while each SAP BusinessObjects Enterprise server that controls events that you can audit acts as an auditee.

As the auditor, the CMS is responsible for collecting events and writing them to the auditing database. When an audited event is triggered, the server responsible will generate a record and store it in a local temporary file. At regular intervals the CMS communicates with the auditee servers to request copies of records from their local temporary files. When the CMS receives these records, it writes the data to the auditing database.

The CMS also controls the synchronization of auditing events that occur on different machines. Each auditee provides a time stamp for the auditing events that it records. To ensure that the time stamps of events on different servers are consistent, the CMS periodically broadcasts its system time to the auditees. The auditees then compare this time to their internal clocks. If differences exist, they make a correction to the time they record for subsequent auditing events.

Its as simple as that. There are actually a number of slightly different workflows depending on exactly which auditee is involved. These are detailed along with a lot more information in the Business Objects Administrator’s Guide.

In the next couple of posts we will explore the auditing database schema.

To report this post you need to login first.

6 Comments

You must be Logged on to comment or reply to a post.

  1. Former Member
    We’re always worried about performance of our BOBJ products, specifically dashboards of course since users expect them to load quite quickly.

    We currently have auditing disabled since we were under the impression that it could potentially impact performance.

    Interested to hear your comments on this point?

    Obviously as we develop more dashboards, the auditing of the usage becomes more important but speed will always be king!
    -Alex

    (0) 
    1. Adrian Westmoreland Post author
      It depends!
      There will be a performance impact when enabling auditing but it should be minimal. The amount of impact will depend on the amount of overall load on the system, the actual audit events and details being captured and in the case of a dashboard the actual components within the dashboard.
      The only sure way is the try it on your particular deployment. I intend to cover a few of the performance implications in a future post.

      Adrian

      (0) 

Leave a Reply