OBIEE - Connection Pools

Apart from creating your connection pool, filling in the type of database, username and password, do you give much thought to the connection pool.

If you have heavy usage, you should increase the maximum number of connections from the default of 10.
You will definately need a connection pool seperate from the others to set your session variables.
You will also need a separate connection pool for usage tracking.
Keep a separate connection pool for write back.

Just a few thoughts

OBIEE Lockdown - Part 1

Security Recommendations in Oracle Business Intelligence Installations

There are three key security recommendations for installing and securing OBIEE in your enterprise environment.

1.       Be serious about password management.

It is important to lock down the OBIEE environment and changing default passwords after installation.

The passwords for weblogic user should not be simple to guess or widely distributed. The best practice is to have different passwords throughout the environments. Moreover, I’d recommend replacing “weblogic user” with another obfuscated username. The username and password combination should be different throughout the environments (at least the password).

Change the default passwords for the RPD, as everyone knows “Admin123.”  If you are promoting an RPD, your password for Dev, Test, and Prod RPDs should be different as well to avoid a possibility of a developer making changes in a wrong environment.

Do not use the administrative account to present reports to the users and avoid providing it to users, there is high risk of breaking/deleting something by accident. Consider automating deployments to avoid having to deal with passwords manually.

2.       Take the authentication and authorization outside of OBIEE

Use whatever is standard in your organization for managing authentication (be it OID, Active Directory, or some other sort of LDAP). Not only does it improve user experience by removing the need to memorize yet another username/password, but it also saves time for the development team. Remember: They are not in the user management business. Another great use case is the ability to push this functionality further by automating users’ authorization by managing LDAP groups’ memberships and mapping them to the OBIEE’s application roles.

3.       RPD Security Objects

Unfortunately, the Administration Tool does not allow development separation within the repository objects (one needs to be an administrator to edit the RPD file – no way around it), hence anyone with the RPD/Admin password can do pretty much anything within the RPD. At this time, there are limited built-in options to audit or keep track of the RPD development changes. One must rely on a custom developed solution if this functionality is important. An easy and practical option is to keep an XLS spreadsheet of the major development milestones. It’s simple; however, its disadvantage is, that there is an overhead associated with maintaining it, especially during active development periods. Another option would be to use an Administration tool utility to create metadata repository document on a regular basis and track deltas. Finally, more advanced options would include MUDE (multi user development environment) projects and XML export.

OBIEE Repository Variable Report

You can create a report to show what your repository variables are set to by doing something like below:

Create a 'dummy' report with a static text view and enter something like below and make sure you have selected the contains HTML Markup box.

[u][b]Predefined Presentation Variables[/b][/u][br/]
[b]session.language:[/b] @{session.language}[br/]
[b]session.locale:[/b] @{session.locale}[br/]
[b]DISPLAYNAME:[/b]@{biServer.variables['NQ_SESSION.DISPLAYNAME']}[br/]
[b]USER:[/b]@{biServer.variables['NQ_SESSION.USER']}[br/]
[b]GROUP:[/b]@{biServer.variables['NQ_SESSION.GROUP']}[br/]
[b]ROLES:[/b]@{biServer.variables['NQ_SESSION.ROLES']}[br/]
[b]ROLEGUIDS:[/b]@{biServer.variables['NQ_SESSION.ROLEGUIDS']}[br/]
[b]PERMISSIONS:[/b]@{biServer.variables['NQ_SESSION.PERMISSIONS']}[br/]
[b]USERGUID:[/b]@{biServer.variables['NQ_SESSION.USERGUID']}[br/]

Update: See more on System Variables here.

OBIEE RPD Repository Report

Hidden away in a dusty corner of the OBIEE Admin tool is the Repository report.

This is pretty useful for a knowledge transfer. Click on tools -> utilities and then select "Repository Report".

This will give you a csv file detailing the information from presentation layer through the BMM and then the physical layer.

Columns are

Subject Area,
Presentation Table,
Presentation Column,
Description - Presentation Column,
Business Model,
Derived logical table,
Derived logical column,
Description - Derived Logical Column,
Expression,
Logical Table,
Logical Column,
Description - Logical Column,
Logical Table Source,
Expression,
Initialization Block,
Variable,
Database,
Physical Catalog,
Physical Schema,
Physical Table,
Alias,
Physical Column,
Description - Physical Column

I am currently experimenting with exporting this data and including it in management dashboards, tying it in with the catalog and usage tracking.