One of the great new features in XI 3.1 is the auditing capabilities. The following new capabilities have been included in :
- Provides client auditing for all two- and three-tier clients.
- Captures IP address and machine name, if the name can be resolved.
- Tracks which service triggered an event, rather than the server.
- Audits the folder path so that, even if you have multiple reports with the same name, you know to which report the event refers.
- Audits the parent-child relationships and parent CUID, which enables you to build reports that aggregate all operations to the level of a common parent.
What is the benefit of auditing – it brings BI administrator of the BOE environment enabling them to understand how the system is being used and make improvements in areas such as unused reports, long running reports etc. that need additional focus.
The first step is to turn on auditing and set the location of the audit database. The DSN for the audit database can be set on the CCM
You can verify the configuration in the “Configuration” tab for the SIA.
With the auditing database set, now you can logon to CMC and enable auditing for logon events by enabling auditing in the CMC properties.
Similarly you turn on auditing for other applications such as Desktop Intelligence, WEBI as shown below.
Note: You need to restart the services after you enable auditing
You can view the audit events in the auditing tables in the database. The key tables to watch are :
| Table |
Purpose |
Description |
| APPLICATION_TYPE |
Metadata |
Applications |
| EVENT_TYPE |
Metadata |
English description of the event types |
| DETAIL_TYPE |
Metadata |
English description of the event detail |
| AUDIT_EVENT |
Data |
Table that captures all the events |
| AUDIT_DETAIL |
Data |
Detail table for Audit events |
To test whether it is working open up Desktop Intelligence and see how it shows up in the audit trail.
For example the code below shows all the user generated events on my system
select AUDIT_EVENT.Event_ID,
Event_Type_Description,
User_Name,
Detail_Type_Description,
Detail_Text,
Object_Type
from AUDIT_EVENT, AUDIT_DETAIL, DETAIL_TYPE, EVENT_TYPE
where
AUDIT_EVENT.Event_ID = AUDIT_DETAIL.Event_ID and
AUDIT_DETAIL.Detail_Type_ID = DETAIL_TYPE.Detail_Type_ID and
AUDIT_EVENT.Event_Type_ID = dbo.EVENT_TYPE.Event_Type_ID
and User_Name <> 'System Account'
The CMS acts as the system auditor; the BusinessObjects Enterprise server that you monitor is an auditee. As the auditor, the CMS controls the overall audit process. Each server writes audit records to a log file local on the server. At regular intervals, the CMS communicates with the auditee servers to request copies of records from the auditee’s local log files. When the CMS receives these records it writes data from the log files to the central auditing database.
The CMS also controls the synchronization of audit actions that occur on different machines. Each auditee provides a time stamp for the audit actions that it records in its log file. To ensure that the time stamps of actions 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, the auditees correct the time stamps that are recorded in their log files for subsequent audit actions.
In a next post I will describe how you can use WEBI to generate reports and perform analysis on this data.
Ananth Sridharan
Hemanta Banerjee
Random Thoughts 