Please look at the Discoverer Metadata Migration Assistant - DOMA
You can find great details here: http://www.oracle.com/technetwork/developer-tools/discoverer/disco-metadata-migration-user-guide-1908439.pdf
Thanks for your reply.
I am following the same PDF which you mentioned. I am accessing the OBIEE server through the OBIEE client which was installed in my local system.
I have run the Migration Utility in the local system.There is no MigrationConfig.Properties file existing in the bin directory of OBIEE client.
Where is the Migration Utility Assistant supposed to run, either in the local or in the server?
1 person found this helpful
Afraid I can't help and Oracle may not help you either. Unfortunately, Oracle state quite clearly in the document that they do not provide any support for DOMA beyond what is covered in the comprehensive document. My discussions behind the scenes lead me to understand that you probably won't get any help from Oracle Support - although you could always try.
I have included a section on DOMA in my new 11g Handbook (which will be out at the end of the year). My conclusion is that most companies will probably have to start from scratch when converting from Discoverer to OBIEE.
There is a tremendous paradox here that I'm hopeful Oracle is aware of in that:
- A small company with relatively few business areas and reports could start from scratch with OBIEE in a short space of time.
- A large organization with upwards of 100 business areas and tens of thousands of reports would find this an extremely daunting, and expensive, manual task.
However, it is likely to be the larger one that could justify the cost of buying OBIEE in the first place with the smaller mom and pop shops wanting just an entry point BI system which is what Discoverer gives them. Therefore, the companies that could re-implement in a short period of time are most unlikely to do so, whereas the organizations that would benefit the most will potentially find the manpower cost of building 100 business areas and tens of thousands of reports from scratch in OBIEE very burdensome.
Am I missing something in my observations?
1 person found this helpful
Your general observations and mention of the DOMA chapter in your upcoming handbook are a bit of a tease! If an advanced copy is available, I'd purchase it for that chapter alone. Bhaskar seems to have had some luck, but you conclude most will need to throw the baby out with the bathwater. I have assumed your conclusion all along, having read the DOMA document some months back, but would love to know the top few bullets of the "why" from your research.
At the very least, I'll look forward to the book.
PS I am working with a large org that has 100s, but not 1000s of business areas.
My conclusions were drawn from the too many to mention known issues migrating Discoverer to OBIEE. The problem for me is that for the most part really simple Discoverer workbooks would migrate. However, those organizations that use really simple workbooks, workbooks that do not take advantage of what Discoverer really can do, are not the organizations that would be interested in migrating away from it in the first place. The organizations that would benefit the most are those that have already invested millions into Discoverer and harnessed every bit of its capabilities.
Some of the things that will not migrate are: auto-generated names, metadata in the titles of reports (workbook name, worksheet name, conditions and so on), text formatting, workbook metadata (such as options, filter drills and n-pass filters), item classes (aka Lists of Values) and summary folders. For me one of the biggest drawbacks too is that OBIEE insists on a star schema whereas Discoverer does not. Now I totally agree that a star schema is the most cost-effective schema for reporting purposes, however not everything in this world can be pigeon-holed into a star schema.Discoverer's method of folder sharing to generate multiple, divers business areas will force OBIEE into creating a new model for each. I love the Discoverer approach of having a shared folder, maintain it once and have the same changes available throughout the EUL.
Notwithstanding the above there are also things that OBIEE can do that Discoverer cannot so forcing a Discoverer migration into BI Answers might also make some of the OBIEE features much harder to use.
I therefore came to the conclusion that there is another alternative to migrating and that is to install OBIEE clean and start anew. This will appeal to some organizations but will be a big turn-off for others. In short, Oracle has some way to go before Discoverer data can efficiently be migrated to OBIEE. Will Oracle ever get there? I am not so sure not because I am doubting Oracle's capabilities but more because some of the things that Discoverer takes in its stride (see above) simply do not translate into a star-schema, OBIEE model.
Please remember too that the book is a Discoverer book not an OBIEE book so other than commenting on the whys, the wherefores and the pitfalls I don't go into any great detail about the migration itself.
Much appreciate the detailed response!