Multiple Configurations and MDL between systems

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 go to export and you choose to export a project (just for the sake of the example). You must check the little box to export related objects! That will bring locations across... You also need to decide up-front whether to use match by UOID or name. Either is ok, but you must use them consistently for ever and ever on this set of systems!

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...

Comments:

Post a Comment:
  • HTML Syntax: NOT allowed
About

ETL, CDC, Real-Time DI and Data Quality for the Oracle Database from the inside.

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today