Multi user development using SVN in OBIEE


In many of our projects we need to involve several consultants working on the same OBIEE repository. To cover this necessity OBIEE admin tool traditionally offered the Multi User Development option (MUD) that many of us equally hate and love.

However, since the release there is a new option available to achieve similar functionality and allow teams of OBIEE developers to work concurrently on the same repository. It’s based on the use of a source versioning control tool to track the new developments and highlights the conflicts that might arise.

Apart from being able to use this way to manage our OBIEE repository, this is not a replacement of the old MUD option as each one of these approaches has its unique pros and cons.

In this article I explain how you can have your dev team working on the same RPD using subversion instead of the MUD approach and also what features we gain and lose along the way.

A review on the MUD option

In order to understand the benefits and drawbacks of the new source control approach, we are going to review how the old MUD option works.

Basically, behind the stage, admin tool uses the merge and compare capabilities to enable multiple developers to work on subsets of the main RPD called projects. Each of these projects is then merged and published back to the master repository that is shared on a network location available to the developers.  The projects however, should be created beforehand by a MUD administrator that might be one of the developers or a project owner.

Working with MUD has the following advantages:

- Enhances the organizations of big repositories into different projects
- It “works” out of the box

On the other hand, after several projects using MUD we found some disadvantages too:

- Difficult set up,  complex to understand by new developers
- Working with shared dimensions between projects is cumbersome
- Sharing the RPD over the network is limited when teams are not in the same LAN

Now let’s see how we can make use of the new source version option to enable our dev team to work on the same RPD without using the MUD option.

Multi user development over source control

Before, the repository has always been treated as one single (and rather big) binary file with extension RPD. However, since this release, we have the possibility of managing the repository as a set of XML files. This means that each one of the first-class objects of the RPD (as presentation tables, hierarchies, physical tables…) is no longer part of one big file, but rather a XML text file on its own.  A repository treated this way is in MDS XML format.

Once the repository is in this MDS XML format, we can start source controlling the individual XML files as they are text based and no longer binary.  To start working in this way, we are going to need third party tools and some set up. We usually recommend subversion (svn) as the source control engine, particularly VisualSVN for the server side and Tortoise-SVN as the client.
In addition to these third party tools, make sure that your OBIEE instance is running or higher, and that you have close at hand the SVN configuration file that you will find here:


As part of the one-time set up, you’ll have to install the VisualSVN server and create your SVN repository with the contents of the RPD file on MDS XML format. This would be the same task as putting the RPD on a shared network location when using MUD. Notice however that when using SVN we don’t need to create separate projects.

After that, each one of the developers needs to install the Tortoise-SVN client on their development machines and checkout for the first time the master repository. This operation will transfer all the XML files to their workstations so they can open the repository using the new MDS-XML option.
The OBIEE Admin tool will allow you to select between the Standalone or Use Source Control options. Pick the second one and browse for the XML control file we mentioned before. After doing that you can go and start working under source control.

This step will be the equivalent of setting up the MUD options on each one of the development workstations. One of the advantages of MUD against the SVN option is that everything is built out of the box and you don’t need any third party tools or software. It’s also worth to say that the admin tool will work with any source control engine, not only SVN.

So, what is it happening under the covers here? The admin tool is opening the local working copy of the RPD that is stored as MDS XML on your hard drive. This means that when you add or modify objects in the repository and then save, you are just adding or modifying local files. On other words, admin tool won’t commit your changes to the master repository on the remote SVN repository; you’ll have to do it by yourself using the Tortoise-SVN client using the commit option.


It will be then, after committing your changes, when subversion will update the master remote repository and identify possible conflicts with modifications that other developers might have done. After that, you might want to update your local working copy to retrieve the latest changes from everyone else.

This methodology allows several developers to work in the same repository without worrying about overwrite other’s changes as the subversion engine takes care of everything.
As usual, in case of conflicts, the tortoise-SVN client will ask us to resolve it by choosing whose change is the correct one or allowing us to merge both changes in the same file. This resembles the way that MUD identifies and resolves changes.

Here in ClearPeaks, we’ve been testing this new approach to allow our consultant teams to work on the same repository. The experience overall has been positive and successful; however I’d like to address some challenges that we found along the way.

Thoughts after using SVN multi user development

Maybe the best improvement that we noticed when using the SVN approach is that we didn’t have to setup the cumbersome MUD structure in terms of projects and network administration for the shared repository. It’s more familiar to us, as software engineers, to work with the well-known SVN repository structure and also to install the VisualSVN server or the tortoise-SVN clients.

Also we found these additional major improvements:

- Having the remote repository on a VisualSVN server allowed us to access the RPD contents via https easily and secure from different countries.
- The ability to create branches that SVN offers was really helpful to develop new requirements once the main project was deployed.

On the other hand, we found several issues when using it:

- The parent-child hierarchies cause the consistency check to fail. Hopefully this will get fixed soon by Oracle
- For big repositories it takes longer time to load the repository into the admin tool (our latest RPD took around 5 minutes to load in MDS XML format while taking just 10 seconds on offline mode)
- In case of conflicts it’s really hard to read through the XML source files to know what is going on.  In this matter MUD is better as it will show you exactly which object changed and how.

In this article we saw another effective approach to allow multiple developers to work concurrently on the same repository using subversion as the version control system instead of the MUD option.

If you have any questions related to this topic don’t hesitate to leave us a comment!

5 Responses to “Multi user development using SVN in OBIEE”

  1. Soren says:

    Hi ClearPeaks, Good article – but what about the Catalog part of a project, how to you handle that? Do you know which file I have to control in SVN to versioning my Catalog, if we use OBI

  2. Antonio says:

    Hi Soren,

    Unfortunately the Catalog can’t be versioned as it’s because some of the files within it are binary files. You could however version the text files (sort of XML files) and that should work. Probably best if catalog is in a shared and replicated location.

    It’s a very interesting question though.

    Thanks for your comment,

  3. Krishna says:

    Nice article. Thanks for Sharing.
    You mentioned that this approach is not a replacement for old MUD option. Is it because of it’s inability to provide clear message when conflict arises?
    Is it a good idea to combine MUD with version control or you think it;s a overkill?

  4. admin says:

    Hi Krishna, thanks for your comment.

    Indeed, one of the biggest drawbacks that we are facing when using SVN to allow multiuser development is the inability of resolve properly the code conflicts. Thanks to a good methodology and to the good work of our developers we maintain such cases to the minimum, but when they appear it´s a pain to resolve the conflicts by just reading the XML files. In that regard MUDE is better than SVN.

    On the other hand, we work with teams dispersed geographically, so accessing a share network location is not always possible. Here SVN works fine for us.

    Using the two methods at the same is something we don´t contemplate at the moment, the MUDE setup is too taxing for our teams structure and the benefits are simply not worthy.

    I hope that helps! Any further question feel free to ask and I´ll follow up.

    Best Regards,

  5. Johan says:

    Hi all

    I am trying to save a OBIEE repository in XML format to a directory which is controlled by SVN so that I can Commit it back to the SVN Server repository. I however get the following error:

    Admintool> Creating directory oracle\bi\server\base\LogicalDisplayFolder

    Admintool> Creating file oracle\bi\server\base\LogicalDisplayFolder\6cda10b0-0cbe-1000-806e-0a6797b70000.xml

    > ade.exe add oracle\bi\server\base\LogicalDisplayFolder\6cda10b0-0cbe-1000-806e-0a6797b70000.xml

    [nQSError: 46105] Error executing process: “ade.exe” add oracle\bi\server\base\LogicalDisplayFolder\6cda10b0-0cbe-1000-806e-0a6797b70000.xml

    The system cannot find the file specified.

    The project (BI repository XML files) has been imported into a VisualSVN repository and I am able to to use SVN Update and SVN Commit on my client machine to sync files and commit changes to the SVN Server using TortoiseSVN.

    My BI Admin source control config file has been configured as follows:

    Add file: ade.exe add ${file} (Note: ade.exe mkelem -nc -recursive ${file} also does not work)

    Pre-Delete: ade.exe unco ${filelist}
    Delete: ade.exe rmname -listfile ${filelist}
    Check-out: ade.exe co -nc -list ${filelist}
    Rename: ade.exe mv ${from} ${to}

    Any suggestions would be appreciated.

    Thank you.

privacy policy - Copyright © 2000-2010 ClearPeaks