OWB - Snapshot (Version Control)


The version control of OWB is implemented with the concept of snapshot because they want to have the difference for one object but also for all the process (with the option cascade). It's directly linked with the lineage and impact function. And you can't have this kind of comparison with a CVS software because it focus on one object (text file) and not on the process.

Warehouse Builder supports the following types of snapshots:

  • Full snapshots provide backup and restore functionality.
  • Signature snapshots provide historical records for comparison.

Oracle point of view on Version control


Oracle Warehouse Builder 10g provides the capabilities to store a copy, snapshot in Warehouse Builder’s terms, of the current definitions at any point in time, at any level in the repository. Once captured, the snapshot may be used to compare and/or restore definitions.

Oracle Warehouse Builder 10g provides metadata management capabilities on top of the metadata store. Version management is an important feature that helps you to compare different situations in time, restore previous situations or restore old versions. Multi-language support can be extremely valuable in multi-language environments. Finally, the investment of storing data into a metadata repository pays of, for example in the graphical data flow impact analysis and lineage diagrams that Warehouse Builder provides. All these and other components enable metadata life cycle management.

Concept of Cascade with Snapshot

There is the concept of cascading dependent objects. Imagine you capture a process flow definition that sequences a number of individual ETL jobs as well as other activities. Even though the process flow is self-contained in the sense that it knows which activities to perform according to which dependencies, it may contain references to mappings and transformations. Perhaps you want to capture those mappings and transformations also in order to capture a fully contained set of definitions that can be deployed again. Mappings may refer to table definitions, which may have references to other table definitions via foreign keys, etc. With the snapshot capabilities of Warehouse Builder you specify the depth of dependencies to indicate how many levels down you want to capture definitions. Because mappings depend on database objects to be available and process flows depend on mappings and transformations being there, you can capture a consistent set of object definitions that could be restored and deployed again, even though definitions may have deleted and/or changed once you restore.



From Linkedin

What works best for me is to export your code (mappings and process flows only, other objects are migrated better with SQL scripts in my opinion) out to an MDL file, and then check it into source control, such as Subversion or whatever, along with the SQL scripts used to modify other objects. This will allow you to maintain your revisions very easily. I actually make use of OWB collections (not to be confused with PLSQL collections) for this as well. OWB allows you to group objects together in “kits”, which for you would be the objects involved with each version.

So when it comes time to move code to QA or production, I make sure my collection has all the relevant objects in it. I then export the MDL for that collection and check it into source control, as well as making a Change Manager snapshot that I name according to my revision number in Subversion. Now, all your QA team or Production support individuals have to do is check out the latest version from Subversion (or whatever), and import the MDL from the “kit”.

You could also make use of multiple control centers and deploy your code straight from the design repository straight to all the affected environments: dev, QA, production. With multiple control centers, you could really manage the entire versioning process with Change Manager. Many people use this method and it works for them… I just prefer keeping a copy of the MDL versioned along with everything else.

Software OWB Version Control

Building versioncontrol within OWB using OMBPLUS and OWB experts.

With a right mouse click you lock an OWB object and check it out. Finish your work you can check it in. If your are done with a complete change you can build you collection automatically based on the change number.



Powered by ComboStrap