The official list of bugfixes included in 11.1.1.6 is out:
Month: February 2012
wlst.sh – where to execute it from
Yes, I have quite a backlog of topics I should blog and thanks to Robin for pointing it out.
A quick reminder about using the right wlst.sh.
In a normal OBIEE installation, you will find multiple wlst.sh in the MIDDLEWARE_HOME:
./wlserver_10.3/common/bin/wlst.sh
./Oracle_BI1/common/bin/wlst.sh
./oracle_common/common/bin/wlst.sh
Make sure to always start your wlst scripts from
./oracle_common/common/bin/wlst.sh
in order to prevent erroneous behaviour. Running them from a different location will yield interesting errors like the one below – taken from a migrateSecurityStore example:
TypeError: cannot concatenate ‘str’ and ‘NoneType’ objects
Cheers!
Updated: OBIEE 11.1.1.6 Link Library
OBIEE 11.1.1.6 became available yesterday evening (CET) first on edelivery and in the meantime on OTN as well. Here’s a link library of the most important and interesting sources.
Overview and explanatory blog posts:
PeakIndicators
“New Features with OBIEE 11.1.1.6”
RittmanMead
“OBIEE 11.1.1.6 Now Available for Download – Release Highlights”
“OBIEE 11.1.1.6 : MDS XML Repositories, and Integration with Source Control”
Michael Verzijl
“OBIEE 11.1.1.6 Released – Short overview”
Addidici
“OBIEE 11g R1.6 New Admin Feature”
Alex Hansal
“OBIEE 11.1.1.6 is here”
Fiston
“OBIEE 11.1.1.6 new features/enhancements”
Official Documentation
Documentation Library
New Features OBIEE 11.1.1.6
New Features OBIEE 11.1.1.6 for Users
(h/t @lex!)
This is just a first list and will grow over time. If you have new, interesting links to add, please put them in the comments and I’ll update the list.
Cheers!
OBIEE 11g: Login hangs with “Signing In”
I recently deployed a new RPD to one of my BI servers and after restarting the coreapplication, wasn’t able to log on anymore – the login process hung at “Singing in…” indefinitely.
After some investigation, I found out what had happened:
1.) The new RPD used connections to a datasource situated on a different database (other than the primary DWH) which were utilised in new initialization blocks which fired upon login (no “deferred execution”).
2.) The TNSNAMES on the BI server machine had contained all necessary connectivity information until the night before, but had been reset to a default configuration during the night for some reason and only retained the primary DWH.
3.) This caused the login process to hang indefinitely without any meaningful errors being logged and hence nothing was visible in Enterprise Manager.
4.) Restoring the TNSNAMES with all relevant DB entries removed the error and login was possible again.
Conclusion: never assume that your infrastructure setup is a “given” and won’t change.
Cheers,
Christian