Does anyone have an experience on how to implement full auditing using vba? I mean, in output .xls file the client would like to see a list of the reports, objects, tables those objects built upon, classes, contexts.
Thanks a lot, Marina
It can certainly be done, in fact there are several commercial products available that will do just that. But you should be aware that there are some limitations, due to limitations in what BusinessObjects considers an “event”.
For example, if a user creates a new query and runs it from the query panel, there is no record of that event. If they then refresh the document from the main toolbar, then there will be. So even though you can capture some of the process / steps that a user takes, there are some loopholes.
If you want to see a sample of what can be done, there is some code that is posted on the Integra web site that can get you started. Here is a link to take you there.
The original author of that code is not supporting it any more, at least to the best of my knowledge, because of the limitations I already mentioned. But it might be interesting / educational to give it a look.
Dave is absolutely right you have to depend on the BO SDK and there are some very silly things that are just not there.
You can probably build your own but be prepared to live with some limitations and a lot of frustrations:
New queries are not captured
How do you centralize the information?
How do you know what repository they are using?
What are the user doing in offline mode
and many many more
We have spent the last 3 years fighting every single problem and when ever we get a step closer to a solution there are 5 new features/issues surfacing.
Dave,
It is always pleasure talking to you.
What the client would like to see is auditing of “canned” reports prepared for the user community. It seems only development team creates reports. They basically have a transactional DB and by nature of the universe, it is not easy to create a report, so no users are doing it. Since development group does heavy testing of all reports once universe has been modified, they would like to keep records of classes, objects, condtions, classes for the condidions, tables, table fields, contexts, and perhaps joins in one excel file. Is it something that you might have any experience with?
Thanks a bunch,
Marina
Marina: As I mentioned, there are commercial products that you can look at to do full client auditing. Klaus works for one of the vendors that makes a commercial product… and seemed to have been quite honest and open about the challenges in his post. Thanks, Klaus. 8)
The bottom line is that while it can be done, the product was never written to support that feature, and any attempt to add something on later is going to face problems. BusinessObjects provides for auditing of the server-based products (Webi + ZABO), and even then there are some differences as to what is captured.
In this environment, you have a lot more control. What I would consider doing (very rough approach)…
Have the report developers document everything that you require (classes, objects, conditions, tables, etc.) when they publish a report.
Each of the published reports would have a simple VBA program that logs an entry, either to a database table or a simple flat file.
The log would include user name, date+time, action taken (open, refresh) and possibly supplemental information (how many rows were returned on a refresh).
The log file would contain transactions only. Since you have collected the other data at the report level, there is no need to collect it again. And since there are no “new” reports being created, you don’t need to log those. You can even revoke the ability to use the query panel to prevent someone from opening the query and clicking “Run”, which would not be audited.
So in the framework that you outline, yes, there is probably something that could be done. Essentially you would set up a database of report info, and then at the client level simply record the fact that the report was used.
I had the feeling of it, dealing with different modules of BO last few years, I know how frustrated it could be. I didn’t do extensive vba though…
Thank you very much for your comments and help
Agree with the Step 1 a VBA macro, which will document the report when it is exported to the repository or manually by the developer if you trust them.
Step 2 I have a lot more problems.
Depending on the user settings and where they refresh the reports it may fail because of a VBA error. (Zabo is different from BO)
You will need a connection from every Client to write directly into your log database
How do you identify the report as being the right one (DEV or Production)
What happens if users make minor changes to the SQL/Report you may get
What happens when user use the “save as” function …
The Run from the query panel as you mention is one of the nastiest things in BO because it does not exist. We have created our own events to get around some of the limitations.
Dave,
Thanks again. The client wouldn’t like to have vba in their published reports, since they are distributing the report using InfoView and not confident that reports and vba will work in this environment…they are not using ZABO.
Since each report has it’s own code, I don’t see this as a problem. Part of the migration process (DEV to Prod) would involve changing the value of the “report ID”.
In the scenario Marina outlined, I was treating the users as Infoview users, and therefore neither of these would apply.
By revoking access to the query panel, you could avoid this.
Marina seemed to have a very specific case. The solution I outlined was just a suggestion, not a final product. 8) Obviously there are questions to be answered, but in her case, it seemed that since the users never create their own reports, and (in theory) would never make alterations to the standard reports, then something a bit more basic could be done.
By distributing the reports via Infoview, the concern that Klaus raised about connections is a moot point… since all the reports are run on the server, you can guarantee that there is a connection. And since you are on the server, you already have half of the solution… don’t write your own, just use what is already there!
Simply turn on the standard Webi auditing process. It will log which reports are opened and refreshed. By comparing this log to the report documentation that I suggested earlier, you can capture what you need. The Webi auditing does not capture class and object information for full client reports. But by setting up that information on your own, you should be able to get what you need.
And since you are using Infoview, you can guarantee that nobody is going to use the query panel.
Actually, I don’t think this is the case. I believe that you only get that level of detail for Webi reports, not full client reports refreshed under Webi. Also be aware that even for Webi reports you only get details about result objects, not condition objects.
Create a query in webi, and review the data collected in the audit tables. Create the same query in ZABO and see what you get. I don’t think you will see the same level of detail… unless they have improved the collection process since I last looked at it. What version of Webi / ZABO are you running?
You do not have to purchase Auditor. If you are using Webi / Infoview to distribute the reports, then you can simply turn on the Webi auditing feature. The data is logged to a database, where you can then do whatever you want with it.
Auditor - the “product” - is a pretty front-end that BusinessObjects has created to provide a reporting framework. The data is there if you want it.
Thanks, I do not have administrative rights to WEBI server to turn on this feature. I basically have no access to the server. I can only propose that to one who has “a power”.