Related:
OBIEE Software Configuration Management by Mark Rittman
- Part 1 : Initial Deployment from DEV to PROD
- Part 2 : Subsequent Deployments from DEV to PROD
- Part 3 : Version Controlling the Project
OBIEE Enterprise Methodology Group Discussion
- OBIEE development, test and deployment
- Multiple RPDs/WebCats
Those deal with more of the software side of things. I want to explore the physical set up a little. I don't have the definitive answer, just thinking out loud perhaps.
The client is considering a ramp-up of development efforts (good thing). We were asked to think about an environment to allow parallel development. This is no easy task in OBIEE as the RPD can be a bottleneck.
While talking about it though, it sounded a lot like classic software development and source control. You pull down the code locally, fix/create/update it, and then merge that up into your trunk (subversion lingo anyway). You merge it up into a common repository.
What if you physically separated your environment? Here's my thinking:
- Find the common code (init blocks, connection pools, etc) shared by all subject areas. Especially relevant if setting some variables or something for security.
- Create virtual (or physical) machines with the full OBIEE environment (services, rpd, web cat) set up for each subject area and only that subject area. Of course this would include all components identified in step 1.
Pros
- Allows for parallel development
- Easier to identify changes
- Easier to import than merge?
- ????
- Separating RPD into sections, scary
- How do you handle physical tables shared across subject areas?
I don't know if this has merit or not, but I wanted to put it out there. Good or bad, I'm OK with. The goal is to give the client the most reasoned, researched, supportable analysis that I can.
3 comments:
Hey chet,
Your line "the RPD can be a bottleneck" sums it up for me - it just doesn't play well with the typical dev/SCM methodology.
This is Déjà vu for me -- we have the exact same problem here and I spent several weeks a few months ago scratching my head over it. Aside from the hair loss, the conclusion I came to was that merging RPDs is to be avoided. We're also upgrading OBIA and the upgrade process includes a merge, and boy, it HURT.
Maybe you could hack something together now with an nqxudmlgen of each RPD and a diff and then nqxudmlexe but it's majorly unsupported and I'm not sure if the hacking necessary would be worth it (or even work). OBIEE 11g is supposed to have an XML(?) API for the RPD, maybe this will be the answer to our prayers.
I'm interested in your idea though. Maybe you should try a POC with it, because just as with Merging not being as simple as its functional name suggests, perhaps there'd be some serious Gotchas using Import to join the RPDs into the DEV stage.
Plus as you say -- shared dimensions etc would be difficult to maintain across multiple development instances.
Chet:
The link you mention from our blog, http://www.rittmanmead.com/2009/12/02/obiee-software-configuration-management-part-3-version-controlling-the-project/, does explain one way to do merges into the RPD, but it's not nearly as powerful as using Subversion on a text file.
There are some ways to mitigate the bottleneck issue, but not solve it completely. You can have the RPD in online mode on a dev environment, using the multi-user development functionality to lock portions of the RPD while they are worked on, and the unlocked once those pieces are complete. This just constrains multi-user development for all intents and purposes... but it does keep users from squashing changes created by others. Then, the COPY AS option in the Administrator can be used to write the current RPD file to a Subversion local directory periodically, and checked in.
There are partially-supported ways of merging using UDML. This is outside my area of expertise... but I now of clients that are doing this. Perhaps some one with information on this could post... but if it sounds interesting, I could get a little more detail and pass it on to you.
i like this
Post a Comment