It’s a bear.
There, I said it. A bear.
Wrestle with OBIEE RPD Development and you’ll feel like you’re wrestling with a big ‘ol grizzly bear. It’s not that the OBIEE metadata layer is bad, or that it doesn’t work, or it should be removed. Far from it. But work in the RPD long enough and you’ll hit a few walls that are hard to scale, knock down, or get around. Here are the top 3 I see from customer to customer.
#1 Manage multi-user development
You knew this was coming, right? Everywhere I go, the #1 challenge that customers mention about development in OBIEE is how cumbersome it is to enable multiple people to develop in an RPD at the same time. Some companies deal with the locking headaches of multiple developers editing the RPD on-line directly on the DEV environment while other companies choose to develop off-line and can’t see the impact of their development until they deploy a new RPD. Some are brave enough to try OBIEE’s MUD, but routinely run into merge conflicts.
So what’s the alternative? I can sum it up in three bullets:
- Develop in a full-featured silo. All RPD developers need their own full virtualized OBIEE server to develop on so they can not only develop in the OBI Admin tool, but see the results of their development immediately in the front-end.
- Use source control to merge code. If you have a robust source control system, it will be much more effective at merging code than the OBI Admin tool. Git has the best merge techniques on the market, and you’ll need to source control the RPD as MDS XML instead of a binary .rpd file.
- Merge code in smaller chunks. If you’re not merging code at least once per day, you’re opening yourself up for headaches. Use a project task system to force you into small chunks of development and insure multiple people aren’t trying to build the same measure. Use task branches to isolate code more efficiently. Do this well and then you can…
#2 Cherry-pick features to migrate to PROD
A close second behind wanting multiple people to develop in the RPD at the same time is the desire to “migrate this to production but not that.” For most companies, it looks something like this: Project A and Project B both develop in DEV and migrate to the TEST environment at the same time in the same RPD with the intention of migrating to PROD simultaneously, but for whatever reason, Project B’s testing doesn’t go well. Maybe the business isn’t ready, maybe a bunch of things unexpectedly break (more on that in a moment), but the bottom line is that Project A is ready to move to PROD and Project B is not. Or worse, part of Project A is ready to move, but the rest is not. What do you do with your one RPD file without holding-up Project A?
Actually, cherry picking features to move to PROD isn’t that hard if you followed my instructions for #1. The secret is a smart source control branch design with a robust source control system — and keeping your task branches small and focused. If you do that, you can:
- Merge task branches into a mainline develop branch for report/dashboard development.
- Merge task branches (or a subset of them) into a test branch for system testing.
- Merge the cherry-picked task branches into a release branch for deployment to PROD.
While that may sound like a lot of merging, the good news is that a slick source control system makes this all very simple for you if you’re smart about how you use it.
#3 Don’t accidentally break stuff
Unfortunately, there is a bit of a disconnect in OBIEE RPD development between what you build in the RPD and what someone actually uses in the front-end. As an RPD developer, you have little visibility into how your development affects the end-product. Sure, you can run a consistency check, but that only tells you what the BI Server thinks of what you built.
With all of the metadata in one place, this challenge only gets compounded. Oracle BI Apps developers know this problem well, because not only is all of the metadata in one file, it’s mostly all in one business model — one gigantic business model that is very easy to break without realizing it.
How do companies handle this? They have giant test phases in their projects where test scripts are written and executed over and over and over again across project to project to project to make sure nothing breaks. Some savvy customers use testing tools, but most use humans, and the process takes time, and it costs money, and it slows down your time-to-market. All of those things frustrate your users, your sponsors, and decrease the value of what you have to offer.
What’s the quick fix? In a single word: automate. Automate, automate, automate. While every test can’t be automated, there are many tests that can be automated and most of them have to do with testing the RPD. How do you automate? In a single phrase: Continuous Integration.
Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily — leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly.
— Martin Fowler
The combination of a focused development methodology supported by task management tools, source control, and Continuous Integration can eliminate or significantly reduce the headaches you have with your OBIEE development. If you aren’t doing these things today, you aren’t taking full advantage of what’s possible. If you’d like to hear more about how Red Pill Analytics can free your development from the prison of OBIEE’s limitations, please email info(at)redpillanalytics.com.
