CAF = Migration Utility? Use Caution!

There has been a lot of chatter recently in the OBIEE blogosphere regarding the Content Accelerator Framework (CAF) and its use in the process of migrating OBIEE content from dev/test to production. Despite the CAF being available for quite a while now, it is suddenly being heralded as the new way to migrate OBIEE content to production. In this blog post, I'd like to talk about reasons why this may not be a good idea and why caution should be used in adopting CAF as the crux of this critical process.

Background

Before we get into that explanation, though, let's talk about what CAF is really meant to be/do. In the documentation for CAF, the utility is described in the following way:

Content Accelerator Framework V1 (CAF V1) is designed to help OBI EE power users deploy template reports and RPD constructs from any source environment into their own OBI EE environment. The key functionality of CAF V1 allows easy duplication of any existing reports or logical RPD construct from one OBI EE environment to another one. Both, source and target environment could have nothing in common and be completely different. The only prerequisite is that the target environment already has at least a basic logical model designed within its RPD.

CAF V1 clones any report existing in any Webcat, there is no specific property that makes a report be a template eligible to cloning by CAF V1. From a list of existing reports or dashboards (any kind of reports, including a highly formatted layout with different views, including various Webcat calculations), a functional user is able to select analysis of his interest and can clone this analysis to his environment.

In those two paragraphs, the concept of "template reports" is mentioned. This concept is the thrust of CAF and explains what CAF is really meant to do.

Back when OBIEE 10.1.3.4 was released, Oracle switched the out-of-the-box demo content from "Paint" to "Sample Sales". Sample Sales also included brand new sample reports and dashboards that really showcased the capabilities of OBIEE in a way not shown before. The reaction to the Sample Sales content was very positive, with many customers asking Oracle, "How can I get reports like those in my own environment?" CAF is the answer to that question. It allows a customer to take the Sample Sales content and "map" it into their own environment, replacing Sample Sales columns for their own, while all the rich formatting, report structure, and logical metadata comes along for the ride without the user having to do any development at all.

I was actually shown a very early version of CAF when it was an Excel-based tool that leveraged macros to do its thing. The thrust was all about accelerating content development (hence the name) for users with Sample Sales as the template for the new content. It was thought, at the time, that this somehow might be the beginning for having template capabilities in OBIEE, but ultimately it was all about taking a desired Sample Sales report and push it into a customer's environment without doing all of the manual development work. Since then, the tool has evolved into the Catalog Manager add-in that it is today.

Why Does OBIEE Need A Migration Utility?

Now that we understand the background behind why CAF was developed and what its intended use is, it's important to understand why this buzz about CAF as a migration utility is even occurring. The only reason for people to get excited about a new option for migrating OBIEE content is due to the fact that current options are less-than-desirable on an Enterprise level. For the customer supporting a lot of content in OBIEE across hundreds or thousands of users, the existing options for migration to production are difficult to swallow. I'm not going to get into those options here and discuss why they are inadequate, but it's safe to say that experienced implementers know the challenges, experienced customers know the challenges, and even Oracle understands the challenges (and hopefully 11g offers some improvements as a result).

Why CAF Shouldn't Be The New Best Way To Migrate

So now that I have all of that background material out of the way, let's get to the heart of the matter. CAF was not designed as a full-blown migration utility. Nowhere in the documentation will you see "migrating to production" as one of its purposes. While I love applying creativity and using software in outside-the-box ways, there are some very good reasons why CAF should not be considered the new best way to migrate OBIEE content to production. They are:

1. It's still not automated
2. It's more labor intensive than the other ways
3. It can only migrate certain content
4. It's not a supported product

So let's look at these in more detail.

1. It's Still Not Automated

This is the weakest of my reasons, but I'm going to list it anyway. The biggest challenge I see customers having with OBIEE production migrations is the fact that it is very, very difficult to automate the migration of catalog content to production. Again, I'm not going to go into the reasons why, but the bottom line is that the thing that I hear customers wanting most is not present in this solution. That's not a reason by itself to forego CAF as your migration solution, but it's worth mentioning.

2. It's More Labor Intensive Than The Other Ways

One of the selling points of CAF as a report template mechanism that you can take a report you like, clone it, and quickly map the columns on the report template to the columns you want to use in another subject area instead. This is a great feature, until you want to do this for dozens if not hundreds of reports, like you might do in a production migration. While CAF offers the ability to select multiple reports or entire dashboards, you still have to map all of the distinct columns across all of the reports to the same columns in the target RPD (because presumably in a production migration, the source RPD and target RPD will be the same). But wait - it gets even harder than that, because to do this mapping, you first have to select the target subject area, which means if you have dozens or hundreds of reports that span multiple subject areas, you have to do this needless mapping step subject area by subject area, one batch at a time.

If all that extra mapping mess weren't enough, there are other extra steps to consider. If there are columns used in filters that aren't displayed in the criteria, you have an extra mapping step for that. If there are columns that require level definition (AGO, TODATE), you have to map the levels for them (even if they are the same). You have to specify the target catalog folder path, which implies you can realistically only clone one parent folder at a time. You have to specify whether to create a dashboard or not, implying you can only clone one dashboard at a time. All of these steps add-up to extra effort that far exceeds the current migration techniques. While it's true you can save mappings for future re-use, that only helps if you're going to migrate new content against the same unchanged metadata, which is only a portion of all possible production migrations.

3. It Can Only Migrate Certain Content

The CAF documentation lays out the known limitations of CAF:

• Cannot clone reports using set operations (UNION, MINUS, INTERSECT)
• Cannot clone reports with aliases
• Does not carry forward saved filters that are used to filter reports
• Only carries forward the default column in a column selector
• If a dashboard is cloned that contain reports from multiple catalog folders, they will be cloned into a single folder
• Any link to a report will reproduce the link, but not clone the target report
• Cannot clone any report if the source or target RPD contains Essbase metadata
• Command line utilities may cause problems with parsing a specific RPD syntax

While each of these are show-stoppers in their own right, there are other undocumented limitations when considering CAF as a migration utility:

• Does not migrate any object security, groups, or privileges(!!!)
• Does not move reports or dashboards to another folder location
• Does not delete reports or dashboards from the catalog

All of these limitations narrow the scope of migration scenarios very quickly, making it impossible to recommend using CAF for all production migrations.

4. It's Not A Supported Product

If I still haven't swayed you, the coup de gras is the fact that this utility is not an officially licensed product, which means no maintenance or support. The very first page of the CAF documentation spells it out plainly:

CAF V1 is a free utility code, not maintained by Oracle as a licensed product.

A migration to production is a critical event in the administration and use of OBIEE. If the migrations don't happen successfully, accurately, and timely, that can be a very big deal. While free utilities have their place, I would not want to rely on one to carry the weight of something as heavy as a migration to production on a regular basis. With no options for support if something goes wrong, and no guarantee that Oracle will continue to enhance the utility, it's hard to recommend it, regardless of whether the utility does the job or not.

Conclusion

So as you read all of the chatter on the blogosphere that advocates using CAF to perform your mission critical migrations to production, make sure you proceed with caution before doing so. Perform plenty of testing, consider the risks, and make an educated decision. If you find that CAF works as a migration solution for you, drop me a line. I'd love to hear that I'm wrong on this, as we're all looking for a better way to migrate.