Pages

Friday 24 January 2014

Smooth(er) OBIEE Administration

I am one of those people who likes to know how things work. I'm constantly digging through the Oracle guides for OBIEE and trawling the net to find those nuggets of information that will make my life easier.

I have a confession to make at this point. I will go out of my way to avoid doing repetitive (boring) work. Like most people I would rather do  something new and exiting rather than push the same buttons in the same sequence day after day.

OBIEE administration is one of those jobs that could suck up hours and hours of your day unless you think smart. Unfortunately, most environments expect you to 'get stuck in' and then before you know it ......... the same thing day-after-day. Every OBIEE site has common issues that they struggle with; migration across environments, performance, testing, development, lineage.....

Part 1. OBIEE Documentation: 


Not the most glamerous of suggestions surely, but your boss and sysadmin will love you. Start by documenting where to find stuff middleware home, logfiles, config files (instanceconfig.xml etc.), the URLs used for administration.

Then move on to documenting the config changes made after the install, what settings were changed and if known what the default values were before and what they are now. What are the connection details for your RCU schemas (BIPLATFORM and MDS). Capture things like server names and directory structures.

Now comes the living documents which you can generate periodically and version. Run off a repository report and catalog reports. This will give you (and your colleagues) a better understanding of what the repository looks like and also what in the catalog is where on the dashboards.

As an added benefit you can now work backwards from the catalog reports through the repository reports to see where data comes from to fill reports, and vice-versa, from a physical column work your way through the repository to the catalog report to see where the data is used.

Remember, having no documentation means a risk to your business. View sample documentation here.

Part 2.  OBIEE Automation:


You don't already? You will need to think of all those tasks you do and tackle them one-by-one. It may take you some time to get to a state where executing a single script will do an entire day's work, but you can certainly make a start by taking simple startup and shutdown tasks and automating them. Join them together shutdown then startup, there you go you have a script to 'bounce' the environment. How much time did that save?

You will need to have scripts to help with testing connection pools and migrating RPDs and catalogs. You can generate scripts that 'auto-correct', they start up an environment if it is down or restart components of OPMN. How about migrating users and groups across environments.

When you create a script you put all the effort in up front and reap the benefits in the days that follow.

Part 3. OBIEE Procedures:


There is nothing wrong with doing all your tasks in an ad-hoc manner for a Proof of Concept Project. The nature of the POC is to rapidly change things to reflect the change in your customer's requirements.

But what ad-hoc work does is distract you and eats up your time. Before you know it, you've spent an entire day ad-hoccing (is that a word?) and have nothing to show for it.

If you have a thread of automation or a deployment script for promotion across environments then with a little planning and communication you can ease the workload.

So what do you need to know to deploy? What are you deploying, from where to where and what are the configuration details and security settings?

This doesn't have to become something heavy and cumbersome with reams of documentation, a couple of lines and provides project history and documentation as a byproduct.

Each project will have it's own lifecycle and demands but setting up a process and schedule for releases, do you absolutely have to release the latest developer build to test immediately or can it wait until an agreed time where several pieces of work can be batched and planned in. Immediately the level of distraction for you has dropped.

In conclusion, as you start to fill in some of the parts of administration, you start a feedback cycle that will over time reduce your workload, increase your inderstanding of OBIEE and make you more productive

No comments:

Post a Comment