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.

Compare Items Using Dashboard Pages

Ideas for blog entries using OBI EE come up all the time and I should really post them straight away, but something work-related usually gets in the way ;-)

On a lunch break I was reading Stephen Few's blog entry about OECD visualizations. I don't always agree with him, but his writing is interesting; always encouraging readers to strive for high standards!

Now OBI can't display flowers yet, but it was the 'interactive comparison' that got me thinking. Hmmm, how can I achieve something similar with a dashboard? Let's get the most out of what we have in OBI EE, here's the steps:

1. Create a new dashboard page with multiple sections and columns (e.g. 'Compare Items')

• layout relates to how you want to compare the request contents (see example below)
• one section for the 'Compare Prompt', remaining sections are for the request(s) being compared

From DR. OBI

2. Create a page prompt for the dashboard page with a single column holding a list of numbers. You could use:

    SELECT CASE WHEN 1=0 THEN "Table"."Column" ELSE 0 END FROM "Subject Area"
    UNION
    SELECT CASE WHEN 1=0 THEN "Table"."Column" ELSE 1 END FROM "Subject Area"
    UNION
    SELECT CASE WHEN 1=0 THEN "Table"."Column" ELSE 2 END FROM "Subject Area"
    UNION
    SELECT CASE WHEN 1=0 THEN "Table"."Column" ELSE 3 END FROM "Subject Area"
    etc...
3. Add a presentation variable for the column (e.g. dp_comp).
4. Uncheck 'All Choices', Save, then add the prompt to your new dashboard page.

From DR. OBI

5. Create a new request with the layout you need. You'll be comparing items in one request with others, consider adding some dynamic elements for more interest (e.g. view selector, pivot page prompt).
6. In the request, create a filter that directly references your @{dp_comp} presentation variable:

    - add ANY column as a filter criteria
    - select the 'Filter Options' then 'Edit Column Formula'
    - replace this column with your presentation variable reference @{dp_comp}

7. Return to the 'Filter Options', then 'Edit Filter...'. Set filter criteria @{dp_comp} >= 1 (see below). Save the request.
8. Repeat steps 5-7 for each new comparison request, changing the value in the filter each time. I've created 5:

    - filter criteria @{dp_comp} >= 2
    - filter criteria @{dp_comp} >= 3
    - filter criteria @{dp_comp} >= 4
    - filter criteria @{dp_comp} = 5

From DR. OBI

Running these requests directly will give an error, don't worry about it... head back over to the dashboard page from step 1.

9. Add each new comparison request to one of the sections previously created. I've done this from left-to-right, but the order doesn't matter here.
10. Set the 'Guided Navigation...' for each request section:

    - Reference Source Request = Yes
    - Source Request = reference to request in section
    - Show Section = If request returns rows

11. Save the dashboard page layout.
12. Select a value from the page prompt and the same number of 'comparison' sections appear.
N.B. The usual limitations with 'Guided Navigation...' and large result sets apply. Be cautious with the size of your requests.

Give your OBI EE Request the Stephen Few Treatment...

Stephen Few has a couple of great books on visual display of quantitative information. Use these principles when you're building your requests.

1. Take this...

From DR. OBI

2. Then turn it into this...

From DR. OBI

Theory: Single Dashboard Prompt, Multiple Subject Areas

Frequently the requirment pops up to provide results from more than one subject area, using a single dashboard prompt.

From DR. OBI

OBI EE doesn't handle this situation directly, so the 'mid-request' concept can be used.

From DR. OBI

The steps briefly are...

1. Create dashboard prompt using subject area 1, including required columns.
2. Create a 2nd (mid) request listing columns and data returned from the prompt in Step 1.
3. Filter columns using 'Is Prompted' option. 
4. Create the 3rd and 4th requests, from subject areas 1 and 2 respectively, then make sure these requests are based on the results of the request in Step 2.

 A worked example in a future post...

Data Masking for Demonstrations

Dashboards / Answers demonstrations happen frequently. Data privacy is important, so masking data is a common request. Run demonstrations for any audience and mask data using:

• Presentation variables and
• Answers functions to manipulate request columns (strings and numbers)

Brief steps listed here:

1. Create a dashboard / page prompt with a Presentation Variable. Set masking on by default for privacy reasons...

MASK, or @{MASK}{'Mask'}

From DR. OBI

2. Answers request columns respond to the presentation variable value, example below:

CASE '@{MASK}' = 'Mask'
THEN FUNCTION MASK(FOLDER.COLUMN)
ELSE FOLDER.COLUMN
END

3. Mask data in any way you imagine, still a good demonstration ensures even masked data makes some sense. For example:

• Numbers - easily masked by introducing variation

• CONSTANT + - / * "Sales Facts"."Amount Sold"
• PERCENT * "Sales Facts"."Amount Sold"

• Strings - masked by replacing characters (simple and more complex examples)

REPEAT('x', 5)||RIGHT(Customers."Cust Last Name", 5)

REPEAT('x', (LENGTH(Customers."Cust Last Name")/2))||RIGHT(Customers."Cust Last Name",(LENGTH(Customers."Cust Last Name")-LENGTH(Customers."Cust Last Name")/2))

4. Add the functions into a CASE statement, example:

CASE WHEN '@{MASK}' = 'Mask' THEN (5 * "Sales Facts"."Amount Sold")
ELSE "Sales Facts"."Amount Sold"
END

5. Add sophistication to your data masking capabilities by ensuring the 'Mask' prompt is available only to 'Power Users' on the dashboard page. 

From DR. OBI

Complex string replacement routines in Answers can increase processing time, so keep this in mind. This is a simple alternative to masking routines at the data source and can get your demonstrations up and running quickly.