Categories
- All Categories
- 15 Oracle Analytics Sharing Center
- 15 Oracle Analytics Lounge
- 208 Oracle Analytics News
- 41 Oracle Analytics Videos
- 15.7K Oracle Analytics Forums
- 6.1K Oracle Analytics Idea Labs
- Oracle Analytics User Groups
- 76 Oracle Analytics Trainings
- 14 Oracle Analytics Data Visualizations Challenge
- Find Partners
- For Partners
Is there a way to run 2 RPDS in OBIEE 12C
Hi Experts,
I am trying to find out if we can deploy 2 RPDS in OBIEE, we are running 12C version. Can anyone of you throw some light on this if they tried implementing this , what are the pros and Cons of it.
Thank you.
Answers
-
Short answer is no. One instance per Rpd. What is your use case?
0 -
A little longer answer than Joel: it was supposed to be something coming with 12c, multiple instances support. In practice there isn't anything like that for now, therefor the short answer was "no" and the longer one is still "no".
If really needed you would need to merge the 2 RPD into 1 or have 2 separate OBIEE instances running.
If you give more info on your use case, as asked by Joel, other alternatives could exist.
0 -
Make 2 connection pools and then create model for each, that can be your workaround, You will have two subject areas and you can work like that.
0 -
Thanks for all the replies. My use case is we currently have a single environment for 15 groups. Now the 2 groups are split into separate groups and for the new group we are looking for faster code release process for 1 group and normal restrictive process for other group. So in order to achieve this we are looking for options, either we split the MUD RPD or to see if we can deploy 2 rpds into the same OBIEE instance.
I read from some communities back in 2008 that this is an option but could not find any documentation.
0 -
We already have the connections pools separated by database.
0 -
Based on your needs, assuming the 2 groups will not try to destroy each other work, you can adopt normal multi development processes (and I don't mean MUD )
Concurrent developments with source control and you then enforce the rules about releases processes internally (one being on a fast release mode while the second group on a more restrictive process).
The comment about 2 connections pools and 2 subject areas doesn't apply because an RPD is a bit more than just that. You can still go for full RPD merges, the problem is you need to enforce strict naming conventions to avoid conflicts.
That's why I imagine you could have a smoother process with just a proper multi developer approach, with some regression testing etc. to alert the members of each group if they are impacting something which isn't their business.
0 -
Thank you.
0
