OBI EE Skins & Styles. Yawn, Yawn...

Plenty of public information about manually deploying new skins and styles as a WebLogic application (e.g. SampleApp v107, section 8.1). It's a bit time consuming, so why not script it using the WebLogic scripting tool (WLST).

To see the new skin almost instantly, use the sequence below to deploy online:

    # Invoke wlst (weblogic scripting language)
    ./wlst.sh
    
    # Connect to WLST
    connect('<WEBLOGIC_ADMIN>','<PASSWORD>','t3://<IP_address>:<PORT>',adminServerName='AdminServer')
    
    # Change directories to the list of servers.
    cd ('Servers')
    
    # Deploy new skins and styles
    deploy('<APP_NAME>','/<LOCATION>/custom_skin_style','<BI_SERVER>')

The skin / styles only needs re-deployment if you change the directory structure. Its not needed if you're adding new files only.

Hope this helps,

DR. OBI

P.S. WebLogic and WLST are important for nimble application deployments, it helps to use it where you can. John Minkjan has some informative blog posts on this area.

Tableau, Spotfire, Panopticon and when these applications might be right for your business...

Charts work in almost any sales pitch, time and again! Animated charts in many products have just taken it to the next level.

During a 2010 OBIEE Masterclass Kurt Wolff, an nQuire original (if you care to remember that far back), made exactly this observation. They'd built a great query engine back in the 1990s, but were finding it tough to sell the product so they added charts!

When it comes to generating software sales, Tableau, Spotfire and Panopticon clearly know how that story works. Simple user interface with fantastic looking charts. Stephen Few has some posts on their visualizations, but dare I say it (sorry guys), they all offer pretty much the same proposition!

As an individual, I like these products because they give you a feeling you're in control. And we all want a bit more control in our lives right?

You can connect to the data, you can load the data, you can run really fast queries locally, you can nurture your data set until you have it just right; then you can really WOW people with a good story and those fantastic charts to back it up!

Great, you get some praise, you look like an expert, it might even help you get your bonus. Who wouldn't want that?

Problem is, unless you're an analyst, somewhere along the way you became an analyst. Effectively you stopped doing your job to study charts in attempt to throw a bit of insight into the decision making process that may or may not be relevant. Just because everyone now has the ability to contribute with these software packages, doesn't mean they should!

And so here's the rub, most employees in companies are do-ers, very few are decision makers. Management requires certain key performance indicators to make decisions. These indicators rarely change, why not present them simply and effectively?

Large organizations function most effectively with well defined business processes. These processes are supported by standard reporting that gives employees the latest information in an effective, recognisable layout. Now, as a user I might not be able to control reporting, but since I'm not the analyst this doesn't concern me.

As an independent consultant, I often get this question from executives 'What tool is right for my business?'. Since there are so many options, this will come up. It helps to be prepared with an answer, but mine goes something like this...

"The larger an organization becomes, the percentage of users who need more flexible tools like [BLOG TITLE] falls away. Since your company is looking to implement reports that support business processes, it pays to consider a solution that provides simple reports effectively to the largest number of employees."

My answer would normally contain other considerations, as appropriate to the situation. For example, for a business to persist in achieving rigorous business process, supported by reporting software, these products must not compete for executive mindshare at each opportunity. This leads to confusion.

The sales representative who first sold you the product will almost never know the best way for the product to be used in your company, so it helps to pay for some independent advice from time-to-time...

DR. OBI

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