We plan to segregate our development, test and production environments by using separate repositories, or a distributed repository [one security domain with multiple universe and document domains on different servers].
Everyone here is new to Business Objects, and I have hardly found any documentation on setting up repositories. So far, I have been able to set up separate BOMain.key files, but swapping BOMain.key manually to change environments seems troublesome to me. Any suggestions or documents on this topic would be greatly appreciated.
Steven Jones
Consultant to BT Office Products International sjones@btopi.com
We have a three repository environment (development, testing and production). We have a BOMain.key file for each of the repos. They are named BOMain.dev, BOMain.tst and BOMain.prd. We also have three separate SQLNet.ora files. They are named SQLNet.dev, SQLNet.tst and SQLNet.prd. We have a bat file for each repo. When the user double clicks on the prod bat file for example, it copies BOMain.prd to BOMain.ora and SQLNet.prd to SQLNet.ora. The user is then on the repo they want and will stay on that repo, until they run another bat file.
So at any given time, when you look in our bo/locdata file you will see BOMain.dev
BOMain.tst
BOMain.prd
BOMain.ora (this file placed as a result of the last bat file ran).
The same goes for the SQLNet.ora file in the ORANT/Network/admin folder.
This setup works very well for us. Hope this helps and good luck!!!
We plan to segregate our development, test and production environments by using separate repositories, or a distributed repository [one security domain with multiple universe and document domains on different servers].
Everyone here is new to Business Objects, and I have hardly found any documentation on setting up repositories. So far, I have been able to set up separate BOMain.key files, but swapping BOMain.key manually to change environments seems troublesome to me. Any suggestions or documents on this topic would be greatly appreciated.
Steven Jones
Consultant to BT Office Products International sjones@btopi.com
We plan to segregate our development, test and production environments by using separate repositories, or a distributed repository [one security domain with multiple universe and document domains on different servers].
So far, I have been able to set up separate BOMain.key files, but
swapping BOMain.key manually to change environments seems troublesome to me.
Steven,
I would go the distributed repository route. You are correct in saying that using multiple bomain.key files is troublesome. Yes, you can set up batch files to switch between them, but this is still a cumbersome process.
Simply creat multiple Universe & Document domains under one repository/security domain. You can then name your domains Development, test and Production. Each domain, and Universe within for that matter, can be pointed to different database instances/servers. Remember that for each Universe domain, you will need a document domain. From there, migrating Universes and reports is as simple as exporting and re-pointing to the correct domains.
We plan to segregate our development, test and production environments by using separate repositories, or a distributed repository [one security domain with multiple universe and document domains on different servers].
So far, I have been able to set up separate BOMain.key files, but
swapping BOMain.key manually to change environments seems troublesome to
me.
I would go the distributed repository route. You are correct in saying
that
using multiple bomain.key files is troublesome. Yes, you can set up batch
files
to switch between them, but this is still a cumbersome process.
Simply creat multiple Universe & Document domains under one
repository/security domain.
You can then name your domains Development, test and Production. Each
domain, and Universe within
for that matter, can be pointed to different database instances/servers.
Remember that for
each Universe domain, you will need a document domain. From there,
migrating Universes and
reports is as simple as exporting and re-pointing to the correct domains.
Hi,
We have a multiple repository environment and find that it works very well. I wouldn’t say switching BOmain.key files is cumbersome exactly - in fact it is all that is required to change repository and we have a very simple VB program to automate it. It could even be written into any network login scripts you have although we haven’t tried this. Creating new repositories is easy (with Oracle) by taking a database export of the existing repository and importing it into a new database instance. It is as simple as then deleting the existing BOmain.key and going into supervisor and doing a safe recovery to create a bomain.key file for the new repository. Be careful to also re-direct the universe and document domains to the new repository connection since only the security domain gets changed automatically during the safe recovery and when thinking you are modifying and exporting to the new repository it is easy to accidentally overwrite the universes/reports in the old repository. We are very pleased with this method and find it works well.
We originally thought that we could use multiple universe and document domains but encountered problems. If you store copies of the same universe and same reports (ie. the same names are used although the content may be different) in each of the domains then when running any report it does not know which copy of the universe (from which domain) to use and prompts the user if they have access to more than one domain (we didn’t want to restrict access like that). Also, BO won’t guarantee that universes/reports stored in a development repository with multiple or renamed (from the default) domains will install using files alone in another repository environment (we develop universes and reports and sell them to customers who install them using only the universe and report files).
