Discoverer 4i to OBIEE migration methodology - Oracle Recommended Way

Question

Hi,
We are looking into a scenario where we are required to migrate large number of Discoverer 4i reports to OBIEE. We have good number of custom reports(approx 200) and views too that are to be migrated.
Am aware about the migration assistant that comes along with OBIEE 10.1.3.4. It's a very useful tool, BUT we need to consider the following facts before proceeding:
1. The tool is not for migrating Oracle E-Business Suite Discoverer reports (BIS).
2. The minimum version of Discoverer EUL that can be used with the Assistant is 10.1.2.n.
3. The version of the RPD file that is generated is dependent upon the installed version of Oracle BI EE that the Assistant is run against but must be a minimum of 10.1.3.4.
What is the Oracle recommended approach... complete rebuild of the repository in OBIEE/ Migration from 4i -> 9i ->10g and then to 10.1.3.4/...?
Appreciate inputs from the product gurus and experts.
Regards
KSK
Edited by: user633620 on Sep 30, 2008 10:04 PM

Answer 1

Ok firstly I'm not sure there is an Oracle recommended approach for migration,.
However based on my experience at an eBS client - the Discoverer workbooks were very different from what we wanted to achieve with our new OBIEE dashboards. The Discoverer folders were based on complex views which joined relevant OLTP tables together and contained both Dimension attributes and Facts in the same folder. They were used by our users mainly to extract data at the transaction level into Access databases, this is something we were keen to move away from, and adopt a more Analytic top down approach, drilling into the detail as in Disco. This did require some additional work with our user base to see what they were actually doing in Access and if we could do this in OBIEE, which in most cases we could (although we did use Apex in places too).
We looked at the migration tool, and it seemed to do a decent enough job technically, however for the reasons above ie. the move towards a top down solution we decided on a manual build approach.
The model for OBIEE had to be different, we broke down the views into their component Dimensions and Facts for - whilst the Physical model was 3NF, we ensured the Business model was a pure Star Schema (this was recommended by Oracle). The Subject Areas were kept quite small, and aligned to the business process, no more than 10-12 logical tables with a couple of fact logical tables, and most of all our dev teams had a set of guidelines to follow to ensure we had consistent repositories (Object Names, Ordering, Logical Levels etc..)
If you are using eBS i would have a look at some of the BI Applications Oracle have produced, you may get a good idea for best practise and standards for producing a repository from them. Also the new 10.1.3.4 dashboard has some examples of good layout, and some nice tips (ie. One Answer per Dashboard page, Prompts at the top etc...etc..)
Good Luck.