MDS XML versus MUDE Part1: Introduction
The links below represent all the entries in this series:
MDS XML versus MUDE Part 2: What is MUDE?
MDS XML versus MUDE Part 3: Configuring MDS XML with Git
MDS XML versus MUDE Part 4: Using Branches with Git
This is my first blog post in quite a while... mostly because of all the planning and preparation that went into the Rittman Mead BI Forum, which is now sadly behind us. There's been a lot of other activity around Oracle BI as well. Of course, we had OBIA 11.1.1.7.1 PS1 release recently, and this has us very busy internally, preparing for our first implementation, and thinking about what the training course will look like. Mark covered the subject very well... but still expect something from me on the new OBIA in the not-so-distant future. I've also been busy with my upcoming Kscope New Orleans presentations. Edward Roske and I have a 2-hour, double-room presentation on Essbase and OBIEE integration; I have an OBIEE and Data Vault presentation that I'm presenting with Kent Graziano; and then, I have my only solo presentation concerning MDS XML versus MUDE as a way of doing multi-user RPD development.
I presented on the MDS XML topic already at Collaborate 13 this year, and what I noticed from discussions with the attendees is that most users don't understand where this feature fits in. Honestly... I wasn't too sure myself when the feature was first released, so I thought I would take a look and see how organizations might use it. I was planning on addressing Aggregation next on the blog (a subject I recently spoke on at Collaborate as well), but the MDS XML subject seems to have more momentum... so here we go.
If you aren't aware of what MDS XML is, or if you have an idea, but are still throwing your hands in the air, then let me try to explain first what it is. The OBIEE (and Siebel Analytics, and nQuire before that) metadata repository file has always been binary... that single RPD file that we deploy to the BI Server. But a single, monolithic binary file is a problematic solution for the OBIEE metadata layer... just as it is problematic for almost any deployment large or small. Microsoft faced a similar crossroads not so long ago with Office file formats: the world wanted non-binary, and at that time, XML was king. So Microsoft launched a file-format conversion project to produce a resulting Office file format based on XML and open standards (or at least... as open as Microsoft can allow itself).
The paramount issue with binary files in any technology project is their difficulty integrating with version control systems (VCS). Most of the efficiency capabilities of these systems, from merging functionalities, to cheap delta copies, revolves around the ability to do basic text diff'ing. We immediately lose all of this functionality when working with a binary file. But even a monolithic text file would be difficult to manage as well because it becomes impossible to track the granular changes made to individual objects. So what we've needed in OBIEE is the ability to store our repository as a collection of granular text documents, using a recognized format (such as XML) and having them all act together to form our metadata definition.
We have that capability now with the MDS XML feature in the Admin Tool. Whenever we "Create" a repository, "Open" a repository, or "Copy|Save As" a repository, we have the option to work instead with a directory of XML files using Oracle's standard MDS format.
The Admin Tool will ask us for a directory to serve as the "core" directory for the RPD... a container to hold all the subsequent subdirectories and individual XML files (I used "core" instead of "base" because there is actually a "base" subdirectory in the directory tree.) The core directory serves as the pointer to the RPD... we browse to this high-level directory when opening, creating or copying an RPD file stored in this way. In the below screenshot, the "gcbc" directory is the core directory I specified in the Admin Tool during metadata repository development.
In the next few posts, I'll examine this new file format and see what we can actually do with it. In all honesty, I put my first MDS XML abstracts forward at conferences before I even knew what was possible. I wanted to put this new feature through it's paces and see what (if any) holes it filled in the current project delivery paradigm. In the next post, I'll take a brief look at MUDE (I know, I'm sorry...) to see where the bar is currently set with repository multi-user development for OBIEE. After that, I'll take MDS XML for a stroll along with the Git version control system... arguably the most powerful VCS to date. Finally, I'm planning on taking a look at what a delivery methodology might look like using Git... including RPD migration and rollout.