Skip to Content

BI Platform Auditing – The Basics

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.

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