OBIEE 10g Web Catalog "Best Practices"

Originally Posted by Ritman Mead Consulting.
 http://www.rittmanmead.com/2010/01/obiee-10g-web-catalog-best-practices/

I was working with an Oracle Partner last week who asked me to QA their OBIEE project. One of the areas I took a look at was their web catalog setup, and I was asked to come up with some “best practices” around web catalog design and maintenance. As my speciality is more the server and data-side of OBIEE, I asked around some of my colleagues and pulled together this list of web catalog best practices. Thanks to Pete, Ragnar, Mike and Borkur for their tips, and of course if you’ve got any other best practices, or disagree with what we’ve come up with, just add a comment and we’ll incorporate the feedback. Anyway, here we go…

1. When starting on a new project for a new client, make sure you create a new web catalog.

This goes for the RPD as well. As John Minkjan pointed out a few months ago, it’s not good practice to build off of the Paint or Sample Sales demo RPD, and the same goes for the web catalog. To create a fresh, new web catalog, first create an empty directory within the $ORACLEBIDATA/web/catalog directory where the BI Presentation Server is installed, like this:

Then edit the $ORACLEBIDATA/web/config/instanceconfig.xml file to point to this new directory.

Then stop and start the BI Presentation Server service (from the Services applet in Windows, or using the run-saw.sh script under Linux/Unix). When the Presentation Server sees the empty directory, it will create the necessary folder structure within it, giving you a nice, clean web catalog to work with.

You can now create reports, dashboards and so on in here, without any of the demo items from Oracle cluttering things up.

2. Create catalog groups and folders for each area of analysis within the web catalog.

In terms of the folder structure within the web catalog, we tend to leave the users folder to itself (the Presentation Server creates a folder for each user that registers in the web catalog), the system folder to itself (the Presentation Server looks after this), and concern ourself instead with the shared folder.

How you structure sub-folders under the shared folder really a question of how the system will be used. If you’ve got just a single user community for your system, you might create one folder per dashboard, and place all the requests used by that dashboard within that folder, keeping things simple for when you want to apply security. Typically though, you will have a number of departments or functions that are using OBIEE, and so you will usually want to create web catalog “groups” and “group folders” per department or function. The simplest way to create these groups is to use the Add/Edit Group function with the web-based Presentation Services Administration screen.

According to the instructions on this screen, it should also create the corresponding group folder as well, but when I tried it the folder wasn’t there. Therefore you may need to separately create the group folder using the Catalog Manager, just under /Shared, to hold that group’s dashboards and requests.

3. Create a “Corporate MI” folder for “gold standard” reports

If you have a “Corporate MI” portal where individual departments publish and maintain data, you might want to create another group folder to hold these dashboards. Then, departments can develop their own “private” dashboards and requests in their own group folders, and promote them to the Corporate MI dashboard using an approvals/change control process. These dashboards and requests can then become “gold standard” or “kite marked” authoritative sources within the organization, whilst giving departments the ability to create reports specifically for their own purpose (this blog post by Phil Wright contains some good suggestions around report governance, user acceptance and BI portals in organizations).

4. Enable drop-down menus for dashboards within each catalog group.

Each department can then set up it’s own dashboards, requests, alerts and filters within its own shared, group folder (or indeed, create subfolders for specific areas of analysis). If departments end up creating lots of dashboards, the Presentation Server will automatically show them in a drop-down list with the group folder as the menu name once the number of visible dashboards for a user is fifteen or more. You can control this setting by adding a <DashboardMaxBeforeMenu> tag to the instanceconfig.xml file; I typically set it to 1 on real projects so that all departmental dashboards are shown in drop-down menus.

Then when users view the dashboard, all of the dashboards are clearly grouped by function.

Note that dashboards can only normally be placed in these top-level, group folders (within the _portal subfolder), and you get the choice of which group folder in which to place your dashboard when it is initially created.

These group folders can then be used to hold the requests associated with each group’s dashboards. If you like, you can store saved filters either directly in these group folders, or in a special “Filters” sub-directory under the corresponding group folder.

5. Enable permissions and security within the web catalog.

If you followed the process above, you will have web catalog groups and corresponding group folders in which you will store their dashboards. reports, alerts and filters. To secure access to these groups, ensure that their names correspond to your groups in the RPD or your LDAP server, and then the presentation server will assign them to the corresponding web catalog groups when the user is authenticated using the BI Server. If you’ve organized your web catalog content into these group folders, applying security should be reasonably straightforward as you’ll assign the same permissions to all objects within each group folder. Use the Catalog Manager to set permissions, where you can select “Apply Recursively” to set these permissions on all objects within the group folder.

Make sure you only ever assign permissions against groups, rather than users, to keep things managable. Even so, setting up web catalog security can get quite complicated, especially once you get down to individual dashboard pages and the like. This posting by Kurt Wolff goes through some of the options and suggests some approaches to make it work.

6. Set subject area permissions using the BI Administration tool, not the Presentation Services Administration screen.

The Presentation Server Administration screen can be used to set access to subject areas, stopping users from creating reports using these subject areas or running reports that reference them.

My preference though is to set these permissions at the RPD level instead. This keeps all data access permissions in one place (row-level and subject/table/column-level security) and also makes it easy to control access through the groups in your RPD or LDAP server. When you change permissions on these RPD objects you may need to restart the Presentation Server before the restrictions pass through correctly to the Presentation Server – until you do this users who don’t now have permission may still see the subject area listed and may be able to see the table listing, but each of the tables will be empty of columns.

7. Control access to Presentation Services functions using the Presentation Services administration screen.

Subject area security excepted, the Presentation Services administration screen lets you control whether a user or group can access Answers, Delivers or much lower-level items of functionality, such as which particular views they can include in their requests.

Again, define groups in the catalog for profiles of users, and use these groups to assign privileges in the web catalog. You can also assign permissions on BI Publisher functionality using the Presentation Server administration screens. Also, as Jeff McQuigg points out, if you’re currently only providing dashboards to users and someone suggests turning Answers on for them, be aware that this might mean that your RPD might need some additional thought before you let users loose on it.

8. Back up your web catalog regularly, and use the Catalog Manager for archiving/restoring catalog entries

You can back-up your whole web catalog by zipping it up and storing it on a backup device. To restore it, unzip the backup and copy it back in its entirety. If you want to archive or backup individual requests, dashboards or group folders, use the Catalog Manager application and select the Archive / Unarchive options.

Whatever you do, don’t filesystem copy elements of the web catalog and then try and copy them back, as you may hit problems around permissions that only manifest themselves some time later. Also consider using the Content Accelerator Framework (CAF) plug-in to the Catalog Manager to copy reports, dashboards and RPD calculations from one dashboard to another, although as Kevin McGinley points out, this doesn’t make CAF an environment migration tool.

9. Implement the Usage Tracking subject area and reports to monitor web catalog usage

OBIEE 10g now ships with a set of scripts, a predefined RPD and web catalog that you can import into your project to provide statistics on dashboard and request usage. This Oracle by Example article sets out how to install Usage Tracking and once you’ve done so, you can get a good handle on what requests are used most and which users might be having problems. Combine the usage tracking data with ibots and time-series functions, and you can start to generate alerts when key reports are taking longer to run that normal, letting you fix problems with performance before users can report it to you.

10. Implement an “impact analysis” system for your web catalog entries

One thing that’s lacking “out of the box” with OBIEE 10g is any way of measuring the impact, on web catalog entries, from changes to the RPD. You can export a list of reports, subject areas, columns and tables from the Catalog Manager, which gives you a central list of what RPD items are used by what reports.

You can then view this list on screen, or output it to a file.

From this list you can then at least see what reports are going to be affected by an RPD change. Within Rittman Mead we have developed an ApEx application that takes this file as an input, parses the RPD and allows us to do an automatic impact analysis; when we get a moment we’ll post details on here together with details on how you can use it on your projects.

So, there’s my “starter for 10″ in terms of web catalog best practices. Do you have any others that you can share? Do you disagree with any that we have come up with, or have a better way to achieve their aim? Have we missed anything off? Just add a comment and we’ll incorporate it into the posting.