Categories
Migrating Obiee 12c rpd (datamodels and subject areas) from oracle to snowflake
We are migrating Obiee 12c rpd (datamodels and subject areas) from oracle to snowflake in windows. If I create a new connection for snowflake, then it will over write the existing physical, BMM & presentation layer. I want both oracle and snowflake to exist pointing to oracle and snowflake respectively for reports and dashboards. So that I can test and compare in both environments. What will be best approach?
Answers
-
You can duplicate everything in your RPD (obviously you need a different name for the subject area and the business model). You create your new physical source, import/define your physical objects, map them to the copied business model, create a subject area on top of it.
The easiest would be a different server where you deploy the same catalog and RPD, and change the physical layer to point to your new source. In that way all your analyses and dashboard will work in one environment sourced from Oracle, in the other sourced from Snowflake.
If you choose to duplicate the content inside the RPD, you will need to rebuild analyses and other front-end objects on the new subject area.
0 -
Different servers mean, I need to build a new snowflake dev server right in order for the second strategy to work.
Please respond.
0 -
By different server I meant that you would need a second OBIEE 12c server.
OBIEE can use only a single RPD. If you want to test your existing catalog content with your current RPD model but sourcing from Snowflake, in parallel of having your environment sourcing from an Oracle database, you need a second OBIEE where to run a modified RPD.
The alternative is to work on the RPD to duplicate its full content (so your RPD has like 2 separate layers horizontally across the 3 vertical layers, physical - logical - presentation) and then rebuild front-end content to use the new subjectarea(s).
0 -
Hi,
The alternative is to work on the RPD to duplicate its full content (so your RPD has like 2 separate layers horizontally across the 3 vertical layers, physical - logical - presentation) and then rebuild front-end content to use the new subjectarea(s).
If I want to go with the above approach then what are the risks and challenges, as I said earlier we have oracle based reports based on OBIEE rpd and BI Publisher reports and dashboards, we need to point to snowflake.
Please provide your suggestions in this regard.
0 -
There are no risks as long as you don't touch the existing objects in the RPD, the new content will be fully separated, not sharing anything with the existing. They are inside the same RPD but do not interact in any way.
Then all your catalog objects will need to be edited or duplicated to point to the new subject area(s).
Of course all this is because you said you want to compare both sources, therefore you need to duplicate everything.
0 -
- 1) How do I test both reports from snowflake_reports folder and oracle_reports folder from front end, as there will be one rpd right in which we have separate folders for oracle and snowflake for 3 layers physical, Logical layer and presentation layer.
2) So, in my case I have to create everything from scratch for snowflake for eg: joins, star schema in physical layer if exists for oracle rpd I need to replicate both in physical and logical layer such as hierarchies, snowflake schemas for logical tables as well.
0 -
If you model your 2 sources in the same RPD, you will have exposed as SubjectArea1, the other one as SubjectArea2.
If you then want to compare an analysis, you can rebuild it using SubjectArea2 and then you can open the 2 analyses and you compare them. Or you duplicate an existing analysis and then point it to the new subject area (as long as everything else will have the same exact name).
There is no miracle "one click" solution for what you are doing. The simplest would be a second OBIEE instance somewhere, because it doesn't require to change anything on the front-end. But you need to define your own process for this task, because it depends on how much you trust your own modelling with a different source etc.
0
