Help with Report Usage Auditing

[jburchill]

Hello, I set up the Report Usage Auditing and it is working.  I've set up the url_xml and modified the xml docs already and ran the build file.
However the maintaince for it can be annoying in my case.  At my company we have to change our passwords like every 60 days. So that would require to modify the build file with new password and run the build and restart service.

I'm looking for a way that I can use a user that doesn't need to change passwords, but if they are in Active Directory they will have to change password.
Or if I could some how read in username and password somehow so when it is updated in AD it will reflect in the build files.

We don't allow for anonymous login for our application, so I am not sure if the anonymous login will work for the audit report usage where the instructions say to comment out the bind.logon in the build file.

So if anyone has an idea how to get around the issue of the password changing in that build file would be great.

[prikala]

Do you really need information about reports that are not used at all? I think url_xml is needed only for that.
If not, You could roll your own reports based only on report execution data available in audit database.

[emarshah]

As suggested by prikala, you have the tables in the database defined, have the data available about accessing the reports. Go through it and create your own report.

[jburchill]

I guess I could create my own report.

Then that points out another question, if the url_xml is just to see what reports aren't used and can write the report without the url_xml.  Why wouldn't IBM just have the report already created and push that out with the rest of the audit reports. :o

[pumccg]

As in earlier replies, the XML DB is only needed if you want to find out if a report has never been used, not even run or tested once. I never bother trying to keep track of these as it's a lot of work for little return.

The Cognos Audit reports are too detailed, and don't provide enough stats or trends. It's usually better to create your own summary reports. We also build our own Audit cube so that we can get all audit activity consolidated into one place - the cube. Makes for much better analysis of audit info.