MDS XML versus MUDE Part 3: Configuring MDS XML with Git

In the previous installment of this series, I gave an overview of MUDE (multi-user development environment), and described it's strengths and weaknesses, hopefully presenting a fair assessment on both sides. For a recap, here are three properties that I think any metadata layer development (and really... any development period) should adhere to:

Multiple users should be able to develop concurrently… but we need to be clear exactly what we mean by this. Having all the developers login to a shared online repository is one way to do multiuser development… but this equates to multiuser development using serialized access to objects. Whether explicit or not in the requirements… what most organizations want is non-serialized access to objects… meaning that multiple users can be making changes to the same objects at the same time, and we will be able to merge our changes together, and handle conflicts.
Our VCS should give us the ability to rollback to previous versions of our code, either for comparative purposes… or because we want to rewind certain streams of development because of “wrong turns”.
Our VCS and supporting methodology should provide us the ability to tag, secure and package up “releases”… to be migrated to our various environments eventually finding their way to production.

Although I gave MUDE a passing grade, no one is making the honor roll. I wasn't pleased that MUDE is siloed: it is a VCS applicable only to the metadata repository. I want an all-in approach... a standard SCM methodology that could be applied to the RPD, the web catalog, ETL artifacts, etc. Additionally, I want to decouple the development process from the conflict resolution process: having our own changes to publish to the master repository does not qualify us to determine whether our changes should override those of other developers. That's a job for the role I defined as the source master. So now, I want to see if an approach using a VCS (specifically Git) combined with MDS XML could match or surpass the grade I gave MUDE.

So I'm going to introduce MDS XML first of all. I won't spend too much time on this, as Mark presented the case for it very well in a previous post, although he used Subversion as his VCS. Also... Christian Screen in his OTN article describes how to install Git, and get it configured with the Admin Tool. As I described in the introduction to this series, MDS XML is an XML-based standard, not unlike XUDML (but certainly not the same either), using Oracle Metadata Services as a standard instead. Flavius Burca provides a very good non-OBIEE primer to MDS, where he describes the MDS schema's role in Fusion Middleware proper. So Oracle already heavily utilized the MDS standard, and being that OBIEE is technically Fusion Middleware, the product management team didn't have to look far for a replacement for the binary structure in the RPD file, or the UDML/XUDML API that accompanies it.

We can use MDS XML by creating a brand new metadata repository specifying XML from the beginning, or converting an existing binary RPD to XML using Copy As|Save As in the Admin Tool:

Notice that when we create an MDS XML metadata repository, we specify a directory location (what I defined as the "core directory" in my introduction) instead of a file location. That's because we are defining the repository as a series of strongly related XML files organized tightly within a directory structure underneath our core directory. We can see this in the screenshot I first shared in that same introduction:

After we have created an XML repository, we can open it normally, just as we would with a binary RPD. So instead of navigating to an absolute file location, we navigate to the core directory location, as demonstrated below:

The first time we open an MDS XML repository, we are prompted with a dialogue that defines our source control strategy. So the Admin Tool is interested in how we want to develop with MDS XML... whether we want to register this metadata repository with a VCS or not. This amounts to providing the Admin Tool the capability of issuing particular commands for our selected VCS to make it a little easier to work with. We also provide the configuration file--or SCM template--that provides the Admin Tool the logic necessary to work with a specific VCS.

The scm-conf-git.template.xml file specified above is a custom configuration file, as OBIEE only ships with support for Subversion and something called ADE (which I've been told is the version control system that Oracle uses internally). So we don't get Git support (pardon the pun) right out of the box?

There are two solutions to this problem. First and foremost... we don't need the Admin Tool configured with a template to work with a VCS at all. When the product of our metadata development process is XML, we can be our own proxy to Git, using the command-line tools, or any number of supported Git clients. But secondly... the OBIEE development team was smart to provide an API for allowing us to connect with different VCS providers. Creation of the scm-conf-git.template.xml specified above is demonstrated in Christian's Screen's OTN article that I mentioned above, and you can see the specific mapping logic pictured below.

Whenever the Admin Tool creates, modifies, or deletes individual XML files as part of the repository development process, the Admin Tool keeps Git tuned-in to these changes with the commands configured in the SCM template. This is nice... but the Admin Tool will only do so much. It doesn't handle the initial registration of the MDS XML repository with our VCS. So we can do that either with a client, or the command line, which is demonstrated below. The git status commands I issue are only for informational purposes and not required:

Also, the Admin Tool is not configured to do an actual "commit" either, which is noticeable when viewing the SCM template listed above. I assume this was a design decision by the development team at Oracle... though I have to admit: it's not one I agree with. It's the safe choice I guess... keeping their hands (and consciences) clean by not getting involved with VCS commits. But in the end... it's a silly decision, as the whole point of a VCS is to be able to rollback to particular commits, or even undo them completely. Regardless... no matter what VCS we choose, we have to use an external process of some kind to issue our commits:

So there we have it. I've gotten through all the precursors. In the next post, I can finally start demonstrating how we can do multi-user development using MDS XML and Git.