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.

Herding Cats -> OBI EE Deployments in 11G

If you've come from a 10G / Siebel Analytics background you could be forgiven for thinking that managing your 11G environment(s) is a bit like herding cats.

There's a new file over here, another service over there and any number of utilities scattered in the 11G directory forest; the trick is bringing them all together for a smooth deployment process.

Core development activity is mostly unchanged (Catalog or Repository, some Publisher), but security administration is much more comprehensive. Firstly, it is in at least 3 places:

• policy store,
• catalog,
• repository, then
• a fourth if you've OIM / OAM installed (user to group mappings)

Secondly, added security in the repository (repository password) means a straight replacement of this file on the <TARGET> is not always the correct option. Catalog privileges have always been in the '/system' subfolder of the catalog, but their location means there are specific considerations for deployment using web catalog utilities.


Industries with particular security requirements (banking, defence, security services) will welcome these added security features, but for release and deployment it means extra steps.

Recently my concentration has been on efficient deployment; scripting as many of these steps as possible to keep deployment time to a minimum, all the while keeping track of the deployed version on each of the target environments.

Venkat highlighted some 11G migration challenges a while back, while John M. put together samples of scripting with WebLogic (WLST). 

Getting deployment steps right is crucial to being nimble on large scale deployments. Key considerations are:

When dealing with a lot of environments get into some good practices around version management for your components (where possible). For example:

Rough steps for a core OBI 11G deployment process are outlined in the diagram.

N.B. Back-up of core components should be considered as part of any deployment process.These tasks are not depicted.

Midvision, for example, also think deployment shouldn't be a drag for any project and are successfully commercializing the deployment process.

What's this all got to do with front-end components?. Well, it's 'runcat', correct and efficient catalog deployment ('runcat')! We'll look briefly at 'runcat' in the next post.


Sorry this entry has been so long, unlike me...

DR. OBI

I'd like to Sh*t-Bag Exalytics, but...

Reading the sales literature for Exalytics you'd be forgiven for thinking your business data problems were a thing of the past. That's what good sales literature is for, so nothing new there. Imagining every user an analyst though, as the demo-app video claims, sounds like a business nightmare!


Exalytics goes some way to addressing the GUI shortfall that has been increasingly obvious in the Oracle Business Intelligence product suite. Nimbler organizations have been using similar visualizations for a little while now.


That Oracle uses such a powerful machine to accomplish these new visualizations is an indication they either couldn't, or they couldn't be bothered to, re-architect the core software components to cram them onto a much smaller hardware footprint.


One suspects its a bit of both, but falling hardware costs and a vertically integrated hardware business mean this kind of BI solution was a 'no-brainer' for Oracle. Plug it all together, chuck it all onto a big machine and watch it run fast.


At least one long-standing enterprise-level competitor claims to have re-architected its business intelligence software for analysis at the terabyte (billion+ records) level. It lacks the functionality users will come to expect from business intelligence at this level and the message is unclear when this will be achieved.


The Exalytics solution price-wise, however, is likely to be outside the budget of all, but the largest organizations. Absent hundreds of millions of rows of data to plug in, this is probably not a solution for your business. Of course, Oracle could pull the proverbial 'Pricing Rabbit Out of the Hat'; leaving all, but the specialist business intelligence products in the dust (?).


With Exalytics infront of you, however, its easy to convince YOURSELF you're an expert analyst; since its bigger and faster it must be better and more accurate! Its certainly bigger and faster...


Accuracy in analysis still comes from understanding your data set!


Anyways, call just in asking when I can implement the next Exalytics machine, so I better go (just kidding...)


DR. OBI

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

DB Functions 'Evaluate' and 'Evaluate Aggr' Bypass Cache

If super-fast performance using cache is your goal, the DB functions 'Evaluate' and 'Evaluate Aggr' will cause a request to bypass any OBI Server Cache. Look for an alternative that will populate your cache instead.

DR. OBI Open Letter Content Reminder

Dear Readers,

just a reminder of the ONLY content you'll find this blog:

• useful tips for getting the most from OBI EE front-end components
• descriptions are brief (you'll find a lot of wordy solutions out there!)
• a working knowledge of OBI EE is anticipated or
• at heart a desire to get more from your implementation
• references to fellow bloggers and colleagues highlight (in my opinion) good quality technical solutions or approaches

If you find the solutions helpful, I'm glad. To the best of my knowledge, blog posts do not repeat content found on other blogs!

All the best,

DR. OBI