For one of our departments we are creating two security domains. One domain will be on the test machine, one on the production machine.
Besides that, on the test machine we will create a universe domain for the universes which are being developed. On the production machine we will have a universe domain for the universes which are to be tested on the production data base and a universe domain for the live universes.
We are using BO411 on an Oracle 7.3 database (same for both test and production).
Does anyone have any (positive or negative) experiences with this construction? We are espacially interested in migrating universes from one to the other security domain.
I personally don’t like having 2 repositories. It is difficult to work with since you need multiple BOMAIN.KEY files. It’s easier to have 2 Universe Domains in the same repository. You can then secure each Domain so that only the developers have access to the Developement Domain.
No matter what you do, be careful with lists of values. Although things work fine for the end user, it can be confusing for the developers when you have the same universe in 2 domains.
In a message dated 98-08-16 14:34:32 EDT, you write:
I personally don’t like having 2 repositories. It is difficult to work with
since you need multiple BOMAIN.KEY files. It’s easier to have 2 Universe Domains in the same repository. You can then secure each Domain so that only the developers have access to the Developement Domain.
I second this comment. There is no practical advantage that I can think of, and many potential major problems that can occur with two separate security domains. First big problem is that this scenario is not – as of yet! – directly supported in the product. Therefore you are caught trying to work around something that does not fit a standard mode.
As Steve suggested, setting up a single security domain with multiple universe domains should give you the same “staging” ability that you are probably looking for by having two security domains.
If your administrator insists on total separation between test and production, you may not have any other choice but to set up separate repositories. But be aware that coordinating the two will not be a simple task. Universe connection information is not stored in the “Universe” domain but in the “Security” domain instead. The “Magic ID” table is also in the security domain, and it controls unique key information for users, groups, universes, documents, and assorted other pieces of information. All sorts ot things can get out of sync, and that can (and probably eventually will ) cause problems.
My DBA is insisting on total separation between test and production – he wants separate repositories on separate Sybase SQL servers on 3 different boxes and he doesn’t want the BO administrator to even touch the production repository. This is the “turnover” scenario he wants:
3 separate BO repositories which means 3 different BOMAIN keys - DEV, UAT and PRD (created by doing a SAFE RECOVERY after copies were made of the initial repository)
BO administrator exports reports/universes to UAT repository DBA unloads the UAT repository and packages it up to have the change management group load it onto the production server
One problem I see with this is that the unload of the UAT repository will have the UAT server name somewhere in one of the repsitory tables which means that I may need to recreate the security domain each time the UAT repository is “turned over” to production.
After I mentioned this to the DBA, he wanted to know if it was possible to “turn over” to production just the repository tables that were affected by the export. But this can be messy because there are several tables whic make up the universe and document domains and isolating them does not appear to be an easy task. Also, I’m not sure BusinessObjects would support us copying and loading only some of the repository tables from one repository to another.
I suggested that if we must have 3 separate repositories, then the BO administrator can export to UAT using one BOMAIN.key and then export to PRD using the production BOMAIN.key. But, his point is that no one but change management (for audit purposes) should touch the production repository. And, he wants completely separate repositories on separate boxes for backup/recovery purposes (i.e. if we only had 1 repository and the box it was on crashed, all of our users would be unable to get to BO).
How have others implemented a DEV/UAT/PRD/DRP environment? Does anyone get change management involved in “turning over” to production?
Thanks for any ideas!
If your administrator insists on total separation between test and
production,
you may not have any other choice but to set up separate repositories.
But be
aware that coordinating the two will not be a simple task. Universe
connection
information is not stored in the “Universe” domain but in the “Security” domain instead. The “Magic ID” table is also in the security domain, and
it
controls unique key information for users, groups, universes, documents,
and
assorted other pieces of information. All sorts ot things can get out of
sync,
and that can (and probably eventually will ) cause problems.
We have three repositories currently on three separate machines; Dev, Test and Prod. It is working pretty well for us and our main problem is just keeping up with where things are!
We have three different bomain.key files. They are named bomain.dev, bomain. tes and bomain.pro. We have three different .bat files on our desktop and we label them dev repo, test repo and prod repo. We have a bat file for each repository and bomain.key file. When we run that .bat file, it modifies our c:\orawin files and copies whatever bomain file we are using to bomain.key file in our locdata folder. So of course, at any given time there is only one bomain file in our loc data folder and that is the bomain for the machine we are working on at the time. We do not have to recreate security domains or anything like that.
When we move from dev machine to prod machine for example, all we have to do is edit the connect string in the universe to the database on prod. As long as the database exists on prod, everything works fine! I hope this helps a little. We have had few problems with this setup. You do have copies of tables and databases on different machines which can cause problems just in keeping the databases in sync but…
My DBA is insisting on total separation between test and production – he
wants separate repositories on separate Sybase SQL servers on 3 different
boxes and he doesn’t want the BO administrator to even touch the production
repository. This is the “turnover” scenario he wants:
3 separate BO repositories which means 3 different BOMAIN keys - DEV, UAT
and PRD (created by doing a SAFE RECOVERY after copies were made of the
initial repository)
BO administrator exports reports/universes to UAT repository DBA unloads the UAT repository and packages it up to have the change management group load it onto the production server
DBA’s that insist on total separation need to be made aware of something before the final decision is made.
When you create other Domains (either Universe or Document), you can create them in a different physical databases. These different databases can be on a different boxes. What you end up with is “virtual central repository”. The security domain, production universe domain and production document domain could be the only thing in the “production” repository. The development universes and documents can exisit on a development database on a development machine. You have true separation of the data tables, but are able to have central administration.
This is the best of both worlds, since you don’t have to worry about synchronization or multiple BOMAIN.KEYs
– directly supported in the product. Therefore you are caught trying to work around something that does not fit a standard mode.