Multiple Configurations and MDL between systems
By Jean-Pierre Dijcks-Oracle on Jun 05, 2007
As a quick follow up thought on the Multi-config post from today, multi config can be a nice way to ensure moving MDL between systems (lets say dev -> prod) in a simple way.
First of, everyone should really script these "go to production procedures" so the operations staff can run a single command line file to "get the new version and deploy to the database". All of this is possible and yes we should write it up for all to use, but no time... it will come though, promise!
So if you have 2 configurations, one is the default one, the other is called prdconf, you will have 2 control centers linked to them. You will also create two sets of locations for each of the systems. So this latter part is different from 10.1! In 10.1 you would change runtime connection and reregister the locations, that is something I would definitely change with multi-config.
Those locations can be production locations, and I would completely set them up. I would then use security to restrict access to the locations (to make sure the data viewer cannot be used against production sources from within OWB). Either disallow usage of the metadata object location (right click - properties - security) or by not sharing passwords (preferences - security settings / only available for repos admin users).
Now if someone changes configuration (to prdconf) and would try to run the data viewer they would either get an error (saying no access) or they would be prompted for the password (which I hope they do not know for the prod system).
Back to multi-config, setting up the configurations to hold the object configurations per system will allow you to export the entire thing and not change any configuration nor location upon arrival in the production system.
So lets say we did all of this, we have:
- 2 configurations
- 2 control centers
- 2 sets of locations attributed to the correct control center
- Set security as desired
Now you do the export and you get the entire project, its locations and BOTH configurations to come across...
To get the deployment in production to work, you go into the repository (or script it) and you make the prdconf the default configuration for the user that will do the import and deployment in production. That way, once you import the MDL it will be directly in the right configuration. That in turn means it has the correct control center set, and the correct locations. So you will "never" deploy to the wrong place...
Once you got this working, like I said, use experts and scripting to build an install shield like process... Should make life a lot simpler...