[OBIEE 11g] Multi User Development Using SVN

Multi user development using SVN in OBIEE 11.1.1.6

To involve several consultants working on the same OBIEE repository. To cover this necessity OBIEE admin tool offered the Multi User Development option (MUD) .

However, since the release 11.1.1.6 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 11.1.1.6.0, 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 11.1.1.6.0 or higher, and that you have close at hand the SVN configuration file that you will find here:

$OBIEE_HOME/instances/instance1/config/OracleBIServerComponent/coreapplication_obis1/scm-conf-svn.template.xml

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.