Rittman Mead - Delivered Intelligence

For any large OBIEE project the normal set-up would involve having a development machine, a test machine, Production machines and some form of disaster recovery. These normally need to be on separate physical machines, mainly for access rights reason and of course the DR machines need to be in a separate building (hopefully in a separate city!)

Did you know that you can have multiple OBIEE environments, but without buying new boxes?

Why do I need multiple Environments?

I am not suggesting that development and Production are on the same box, but there are situations that demand environments, such as:

Multiple Projects - The success of many a good OBIEE project will often lead to other departments in the organisation wanting in on the action. Rather than build a whole new development, UAT and Production box you can just add more services to the existing one.

Clustering - although you often cluster for performance, you should also cluster for availability. The normal process is cluster over two or more boxes, but you can also cluster on the same box across users.

Development Cycles – Sometimes you need to create and test a version of your config (rpd /webcat) for a particular release, but carry on developing for the next release. This calls for multiple development environments.

Integration Testing - You can create your repository, but will it work in UAT and production, particularly if they have SSO and your dev environment does not? I prefer to have a pre-UAT environment in place for Developer testing, or internal testing teams to use.

Sandbox - The last thing you want is for all developers to use the same master development repository to implement new models or methods. Get the developer to work on their own copy, or new one, in a separate area to prove that it works.

Worldwide Development – I am not a big fan of MUD. It will work in certain situations, but you normally find that someone hogs the lock on the master repository. The main issue is new business models. One way around this is to have a master repository and have developers around the world use a copy to build their sections, then merge in their changes when they are tested.

Production Support – In a controlled environment the developers do not have access to production (I normally set the production rpd to read only just in case!)

Demo Site – To help your users understand what is possible you can install the sample sites and give all your potential users access.

Training Site – To support training you often need to build a separate environment. You may not want the hassle of whole box to do this on.

How Do I Create Multiple OBIEE Environments?

Linux

On a Linux box you can install multiple environments into individul user accounts. There is no need to use vitualisation.

When you install a new OBIEE into a separate user you need to make sure that OC4J is not running. Other than that it is a normal simple installation.

After install you have to update all the ports in the system, making sure that you have the correct settings for BI Server, Presentation server, Javahost and graph server. The most important thing is to make sure you do not create spaghetti! Keep a central document on the environments and all their ports.

You can then update the cluster settings as normal, and put the webcat into a shared area for clustering.

We have created a script that does a silent installation and updates all the ports numbers.

Windows

Now there’s another story! My advice is stick to Unix or Linux for now. In theory you can create multiple services to run but I havn’t tried it yet. The simple solution would be to use virtualisation.

If you give it a go let me know how you get on.

Posted in Uncategorized | 4 Comments »