I've just spent the last week reading this impressive book by Adrian Ward, Christian Screen and Haroun Khan. Having worked professionally with two of these guys, I can vouch for their depth of knowledge and commitment to doing a professional job.
OBIEE 11g is a big topic, so its an enormous achievement to pull together such a comprehensive review of the software. The book is written in an approachable, conversational style that should really encourage newcomers to the already strong OBIEE development community.
The core architectural topics (BI Server, BI Presentation Server) are handled thoroughly, making them easy to understand and fun; while a good proportion of the book is spent illuminating readers of the significant changes in architecture between 10g and 11g.
If you're new to this topic, this is a great read. It will inform your developers, help your Business Analysts really sell the capabilities of the software, improve your deployments and make for a smooth transition to comprehensive business intelligence suite.
Get involved with the informative appendix on 'Useful Resources'.
A great job guys. Keep up the good work.
DR. OBI.
DR. OBI OBIEE Leading Practices Blog.
Sunday, September 9, 2012
Thursday, May 31, 2012
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:
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.
Saturday, March 17, 2012
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
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
Thursday, January 5, 2012
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.
- 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.
Subscribe to:
Posts (Atom)