As far as I’m aware there’re no any OBIEE books published on paper (I know about one book in production by Mark Rittman, that got delayed to arrive along with OBIEE 11g release). As I wrote about it, I found one it’s “Oracle BI Enterprise Edition Dashboard & Report Best Practices” from BI consulting group (a respectable company to my opinion). Has anyone read it by any chance? It seems from table of contents and preview that it’s primarily targeted towards dashboard designers, report users and super users.
I’ve decided I’m going to put review of the most useful and most hot topics from the Oracle’s discussion.
OBIEE Kenobi is giving a good amount of resources for starters, including Mark Rittman’s blog. Definitely worth giving a look, if you’re new to bi solutions or obiee.
#2. Calculations using Physical Tables vs Logical Tables asked by Mark Thomspon
Kishore Guggilla and wobiee1 answered the question almost at the same time. I really liked the short and consise description of ” The Physical vs Logical has an impact as you already described:
Logical will first aggregate and then calculate. This is the case with a lot of measures just as your example sales/profit.”
This is one of the most common questions – setting up time series functions. Few experts are giving their few to what they consider to be time series in OBIEE. They also portray examples of such functions as AGO and TODATE. OBIEE has several options for implementing time , however, I recommend canonical time – it’s slightly more difficult to implement – but is more beneficial for your bi system.
Sometimes, the challenges get to us from where we don’t expect them to come from. Imagine, your OBIEE application has been developed and tested – and you’re ready for production. And this is definitely the area that your biggest challenge might come into play. I’ve worked on numerous OBIEE projects where security was a paramount priority for production servers. Deploying OBIEE was a big pain for various reasons, such as:
1. Restrictive access (or no access at all) to production server for OBIEE team. This is definitely a killer issue, since it’s inviting so many things to go wrong. You might not be able to troubleshoor repository, check DB connections, run various OBIEE scripts, and a lot more. Also, you need to train the infrastructure team on being OBIEE server admins, which is a challenge (unless you have a dedicated OBIEE team). A big risk factor is timing – your work might get delayed, because your request for services restart takes a few days to complete.
2. OS / Software / Platform issues. Your application might work fine on your test and development servers, however, in most cases you loose any control leverage once you move to the production. OS patches, Database patches, restrictive firewall policies might cause many things to break (some of the things I can think of – LDAP Authentication, Ibots). Worst thing is that you might not even be aware of any changes if you’re not on the technical infrastructure priority list. Usually, the server people are overworked – having to provide support to hundreds of web applications in a large enterprise, so you might want to develop good working relationship from the start.
3. Network connectivity. This might happen at large projects, as well as small ones. Due to today’s networking complexities and proliferation of cloud computing, your related servers (authentication, data-sources) might be located in a different building / state / country (I’m not joking). As such, the network lagging issue might be affecting your OBIEE application in the worst ways possible. Always check this immediately after deploying and make sure that you don’t see any increases in ping times.
This is it for today. Please come and read again