Your OBIEE Commentary and Collaboration Issues are a Thing of the Past...

As you start 2014 worrying over the issues that plague your BI programme, you can be somewhat comforted by removing one MAJOR headache from the list!

Working with clients since 2006 I've come across requirements for commentary and collaboration functionality native to the BI experience.

Now, for OBIEE, this has been truly solved thanks to a great solution from Christian Screen and the guys at Art of BI.

Not just an app for commentary BITeamwork is a true collaboration platform and since BITeamwork is deployed as its own WebLogic application, it might also be made compatible with other analytical applications in the Oracle Business Intelligence suite. There would be immediate use for BITeamwork in BIPublisher, EPM tools (e.g. Financial Reporting, Workspace) and SmartSuite; though clients will be more than happy with the OBIEE offering.

From OBIEE I've set a dashboard to be my landing page and the collaborative BITeamwork app shows up on the right hand side, ready for my input. It is context and user-sensitive; only my comments and comments shared with me are visible for the specific dashboard (view, cell) I'm currently working on.

Initially my thought is the 'Collaborative BI' app was a bit busy and takes up alot of space... I only want to post comments right??

Not so, I can create comments for dashboards, views and cells; alongside viewing comment history, replies and collaborative threads, as well as secure my comments for specific audiences. I can change the settings, minimize the app to the right, access the help, minimize the app to the bottom (which I really like... below) and sketch on the dashboard page - this last function is REALLY handy for collaboration sessions and web conferences.

For the full range of features, use the 'Comment' prompt at the top of the page, but I wonder if there'll be an auto-hide option in future...?

Entering dashboard comments are saved to the BITeamwork repository as standard, but you can also post to other well-known social applications, Yammer and Chatter. A recent banking client was using IBM Connections, so am sure this authorisation wouldn't be too difficult in future. The same applies for view and cell comments, you can also check a couple of boxes in the 'Settings' menu for comments to be posted to all of these platforms. This is certainly a useful feature, though the level of integration with social platforms could be given more consideration. For example, sharing a bookmark with a Chatter user currently requires the Chatter user to switch over to OBIEE to see the bookmark; passing more information, like 'Briefing Book' style content could avoid a switch between platforms. 

From any dashboard (page) choose the 'Cell or View Highlight' button; switching it on adds a border around the dashboard page sections. Mouseover reveals the options to add a view or dashboard comment.

From a table or pivot view, select an individual cell and a new cell comments box appears. Charts seem to disappear when creating comments for compound views containing charts, using this version, but I'm sure Christian and the team are on top of this. This is not so crucial at the view level, since the comment can be added successfully, but would be more important when / if BITeamwork is able to attach comments to chart data points in OBIEE. 

New administration pages have been added for BITeamwork, so as not to disturb a clients' core installation. This is a good design and couples tightly with the other administration functions in OBIEE. Privileges surrounding BITeamwork functionality are set right alongside OBIEE privileges on a new page tab.

Categories should be tightly controlled, like web catalog foldering, its an area that could get out of hand. They are extremely useful with the current version and might be even more useful if they were security sensitive (e.g. categories for specific application roles).

There's currently no need to use a separate application for BITeamwork administration, as Oracle slowly integrates administration capabilities from previous BI acquisitions into centralised Fusion Middleware utilities though (e.g. Enterprise Manager, Console), I'm sure the guys at ArtofBI will be ahead of the game here.

Overall, its an impressive amount of work that's gone into the application. Its been an area long neglected by Oracle and inadequately addressed by custom developments from numerous third parties.

As a BI consulting shop, or even an independent; if I were you I'd be putting BITeamwork through its paces. It's going to a rip-roaring success, you might just want to be one of those who knows how to install it for your clients.

I write a blog under the pseudonym DR. OBI. Feel free to get in touch with me about your programme. You can find me here Justin Townsend.

OBI EE runcat Usage Scenarios

If the only requirement is to transfer the FULL catalog from development to production, then a straight copy would be enough. Once requirements are more sophisiticated then 'runcat' gets it done efficiently.

Partial catalog change is the more likely situation with the catalog. A typical scenario:

1. Developers build requests and dashboards with final versions stored in the '/shared' subfolder, so for deployment purposes the '/users' subfolder on development might be ignored. Tag the <SOURCE> catalog, so newly created objects get a unique id.

./runcat.sh -cmd tag -appVersion "1" -patchSet "01" -offline <CATALOG_LOCATION>/<CATALOG_NAME> -skipFolder /users

• tag - gives each new object a unique id
• -appVersion - useful for tagging the new objects with the release number for which they're developed 
• -patchSet - useful for tagging objects created for the specific instance of the release, after a round of defect fixing for example. This is less important.
• -skipFolder - allows you to ignore any objects created under the '/users' subfolder.

Tagging is an important activity, without it 'runcat' can only compare objects in different catalogs based on name (since no unique ID is present).  'Duplicate' objects appear after applying a patch, where objects have been renamed.

2.  You've copied the newly tagged <SOURCE> version of the catalog to the <TARGET> and backed up the current <TARGET> catalog. Now you want to apply the differences between the two catalogs as a patch on the <CURRENT_TARGET>.

./runcat.sh -cmd diff -baseline <CURRENT_TARGET> -latest <SOURCE> -outputFile <DIFF_FILE> -skipFolder /users -verbosity detail

• diff - determines the differences between two catalog files
  
• -baseline - the currently deployed catalog, before the new changes are applied
  
• -latest - the new catalog with the latest changes from step 1
  
• -outputFile - file created with all the differences between the catalogs (except for explicit -skipFolder items)
  
• -skipFolder - again, no need to compare '/users' subfolder
  
• -verbosity - the detail is important here, especially if developers have made significant changes to compound objects, dashboard pages for example.
  

 ./runcat.sh -cmd createPatch -inputFile <DIFF_FILE> -outputFile <PATCH_FILE> -production <CURRENT_TARGET>

• createPatch - creates a patch to be applied 
• -inputFile - uses the previously created <DIFF_FILE> as input
  
• -outputFile - creates an output file of patch 'instructions'
  
• -production - determines the catalog against which the patch will be applied
  

./runcat.sh -cmd applyPatch -inputFile <PATCH_FILE> -outputFile <PATCH_LOG> -persistNewApplicationRoles

• applyPatch - applies the patch to the <CURRENT_TARGET> catalog 
• -inputFile - uses the previously created <PATCH_FILE> as input
  
• -outputFile - creates a log file output
• -persistNewApplicationRoles - forces newly created application roles to be persisted from the <SOURCE>. An optional tag, but important when development is used to build application security, 'Manage Privileges' for example.

3. Script all of these steps and you're 'automatically' patching the catalog with all the changes from development in under a minute (dependent on catalog size).

Finally, a couple of other points worth mentioning:

• archive / unarchive switches from 'runcat' are not used since they currently rely on permissions (therefore application roles) being the same between catalogs. It is also not possible to specifically archive the '/system' subfolder where privileges are stored (see previous post)*
• Oracle provided OBIA web catalogs will have tags in place. Think about tagging objects once you start creating your own. Tag objects from the outset if you're creating a catalog from scratch
• Working with Linux (OEL) just now, but these commands of course work with the windows version of the utility.

Hope this helps.

DR. OBI

*Functionality of these utilities may be subject to change in future releases.