I want to create a report that will help us keep track of the users of the Business Objects system. My user is asking for a report that would look something lie this:
Name of user, College/division, Business Objects full install, ZABO, Supervisor, Designer, Business Query
I would envision that all of my Business Objects users which are in the security system would be included in this report. I would put a 1 in the column where the person is using that tool. I could then run simple sums to get my total licenses (good for me) and the managers can see who they are paying for (good for them)
Although we have not yet created all of our classes within the security module I think that I will be able to identify the college/division by the class that the individual resides in. I have a guess that this type of report is available from within the Auditor package but I must admit , I do not understand all of the functionality that Auditor brings to the game yet. My goal is to create a report that I can schedule on a monthly basis which will be made available to those people that are responsible for approving who can access the system and who can not.
Is Auditor the tool to do this? Is there any other ways of creating this type of report?
Hey Douglas - I think you’ll need to set up an audit database to get everything you want, especially to breakout full-client, ZABO and Webi users.
I used to put people into divison/department groups in Supervisor but revamped that a couple months ago to put people into DWh groups. Each security group has a specific DWh universe - Financial, HR, Enrollment - however you have your DWh setup. But each user could be in many DWH groups. It seems to be working OK and login access is OK so far. It may not be the best way, but it avoids the problem of someone seeing universes they are not authorized for.
look forward to meeting you in Sept and sharing ideas - Scott
sorry - left this part out. I use the BO ID from audit table and join to a crosswalk table and then join to HR DWh table to get department and all that stuff. You can create your own audit universe and add these tables. You can also do the same thing in a repository universe. Audit would show use, repository would show who is registered and for what
You don’t need, and actually should not use, Auditor for this. Auditor won’t show you all your users, just the ones actually using the product.
The report you need is not difficult, and can probably be done by a simple query from two tables from the repository. You need to alias each table, as each is used twice. The following SQL is for Oracle only, as it uses the Decode() function. It’s used to translate the numeric values for the type of user into the text descriptions.
Note that there is no entry for ZABO; that’s a platform, not a role.
select u.m_actor_c_name user_name,
decode(ul.m_actl_n_actortype,
2, 'General Supervisor',
4, 'Supervisor',
8, 'Designer',
12,'Supervisor-Designer',
16,'User',
32,'BCA', 'Unknown') user_profile,
g.m_actor_c_name group_name
from obj_m_actor u,
obj_m_actor g,
obj_m_actorlink ul,
obj_m_actorlink gl
where u.m_actor_n_id = ul.m_actl_n_actorid
and ul.m_actl_n_fatlinkid = gl.m_actl_n_id
and gl.m_actl_n_actorid = g.m_actor_n_id
and u.m_actor_n_type <> 1
and ul.m_actl_n_actortype <> 32
I’ve done exactly that. My favorite setup is based on a document that Dave passed over that he CLAIMS he’ll post on his website some day ;-).
Let me set this up…
Since with the button permissions…green/orange/red module settings…most restrictive always WINS if there are conflicting settings, it is easiest to manage if each user is in only ONE group that has the buttons anything other than green. Hang with me…we’re getting to your real question.
Once you put people in these groups, you can use THEM to track your licensing AND to manage security without pulling out your hair.
The thing is…just because you have Reporter permissions, doesn’t mean you have used up a license. We have Webi users who have the Reporter permissions necessary to refresh full client docs via the web.
I typically set up groups like Reporter Novice, Reporter Power User, Webi Novice, etc. Since all users will be in one of those groups to manage permissions, you just report on their group membership to count licenses and the BEST part is you no longer scream every time you add someone to a new group and they suddenly lose an ability they had before. Who among us hasn’t had THAT problem?
Scott,
We have installed the Auditor package from BO. When you say that we might need to set up an audit database are you talking about something in addition to the Auditor package? As I said earlier, I am not very familiar with that package yet but I was told (by a sales person ) that all of the information that I would want with regard to this type of information already exists in the BO repository. The way they described the Auditor package was as a universe that points into that repository.
I got side tracked while I was writing my last response. After reading the responses that came in while I was working on my response I realize that my last question probably did not make sense . Thanks for the advice.
We couldn’t afford Auditor so it was left to me to set up the database tables and then a universe. It wasn’t hard. All I know is what I’ve read from the documentation, supplemented by the fine folks here, and then figured out. Being DB2, everything is a bit different than the default Oracle stuff but nothing we couldn’t resolve. Cindy has some postings in BOB and the old busob-L about tweaking the audit universe. I still think you need to turn on audit to find out who is full-client, ZABO or Webi. I have users that can be any or all of these.
I do have a thread here on auditing. Search for posts with audit or auditing in them. (or just look here ;-))
The audit tables will tell you about who USES BO, not who is AUTHORIZED to use it. Don’t know about auditor. Dave was thinking it didn’t provide any authorization reports…only usage ones. I’m making my own versions of both
, I do not understand all of the functionality that Auditor brings to the game yet. My goal is to create a report that I can schedule on a monthly basis which will be made available to those people that are responsible for approving who can access the system and who can not.
(BOB member since 2002-06-06)
) that all of the information that I would want with regard to this type of information already exists in the BO repository. The way they described the Auditor package was as a universe that points into that repository.