Envisn's IBM Cognos Blog

Building a Cognos Audit Monitor

Written by The Envisn Team | September 24, 2010

By Rick Ryan - Envisn, Inc.
In our recent posts to the Envisn blog one of my colleagues, Eugene Marcotte, shared some of his learnings on the Cognos audit logs and the data tables. Our work with them goes back a while since we use this data in some of our current products. Recently though we took on another challenge dealing with Cognos audit data. Our customers have been giving us feedback on their needs in terms of managing change in their Cognos BI environments. This includes capturing change data with a level of detail around change type, date/time, who, etc. Much of this is driven by audit or compliance requirements for SOX, HIPPA, etc. or simply to mitigate security risks.

A short disclaimer. We make a conscious effort not to use the Envisn blog to tout our Cognos BI admin solutions. Our feeling is that our blog should be a place to share knowledge about the challenges faced by Cognos BI administrators, authors and those whose primary role is to support the Cognos infrastructure. We will continue to do this but feel it’s worth sharing some of what we learned in the process of developing the Audit Vault capability within our NetVisn product.

Scoping the Project

Working with some of our customers we came up with goal statement around capturing changes within Cognos BI. The list includes the following:

  1. Capture every action on every object in the Content Store
  2. Identify when it was performed and by whom
  3. Do this with 100% accuracy
  4. Make this information easy to use and consume
  5. Retain object change history for and beyond the active life of the object

Other things could be included in the list but these are the overarching goals for what they wanted to be able to do.

Reality Check

The Cognos audit log Action table has 18 columns that among other things contain the following:

  1. Date/Time
  2. Action type (add-delete-modify and others)
  3. Display path
  4. Session ID
  5. Request information
  6. Error status field
  7. Dispatcher information

User name comes from another table in the audit log.

It may or may not be obvious to you but something important is missing from this list. The name of the object is not part of it. Arguably the single most important thing you need to know and it’s not on the list of what’s available. This presented a major challenge. There are three action types that are important from a metadata change perspective.

These are: add, delete and modify. It’s obvious that most of the action is in the modify area. There are literally hundreds of possible changes that can take place on objects since Cognos offers such a broad set of attributes and options. Plus, some actions that relate to an object are not captured by the Cognos audit log but yet need to be identified and captured for a complete object change history. This became the second major challenge.

We found ourselves in a situation where what we were trying to do was conceptually very simple, but difficult and challenging in terms of execution. This then led us to a long and deep process of discovery of what could be used to offset the gap between what is provided by the audit logs and what was required to meet the goals we set. Where a number of alternatives were possible we had to find the “best one” which in nearly every case was not the easiest one.

Outcome

The solution to closing this gap led us to focus on the following areas:

  1. Fully maximize the data we do have available to work with, how it is currently being used and how it can be extended. We had to create processes that fill in the blanks in terms of completeness without compromising accuracy.
  2. Focus development on building a platform that is rock solid in terms of change capture. Traceability had to be part of the process.
  3. Keep overhead to a minimum in terms of any additional processing. Where additional steps were required they should serve multiple needs if possible.
  4. Think both in terms of both current goals and likely future needs. This is always hard to do but knowing how it can be used in other ways is always helpful.

This helped us address both of the major challenges we faced; uniquely identifying every object and capturing all actions that occur. The first one had to be resolved successfully before we could proceed with the second one. But what was interesting was thinking we had completed the first one was less true than we initially thought since the learnings from capturing all change actions helped us come up with an even better process of uniquely identifying objects.

Were we successful? At this point we have essentially met all of the goals we set for the project. Alpha testing is currently in progress as this is being written and beta testing will commence in two to three weeks. The feedback so far from the customers we have shown this capability to has been very positive.

© Envisn, Inc., All Rights Reserved.