Testing the OBIEE 10.1.3.x Multi-User Development Environment

September 2nd, 2008 by

Adrian Ward’s recent post on multi-user development in OBIEE, together with some questions I’ve received about the feature, prompted me to dig out the manuals and start working through this relatively new part of OBIEE on my laptop. The basic proposition with the Multiuser Development Environment is that you can have a group of developers all checking out, and checking in, various elements of a central BI Server repository project without tripping up over each other; Adrian’s post indicated that it more or less worked but that it took a bit of setting up. To work through this example then I’ve got a repository with a number of fact tables that share some conformed dimensions, I’m going to simulate a number of developers working on the repository and see how it handles the concurrent development. (UPDATE: Note that I’ve made a few corrections and clarifications to this article based on some subsequent testing, and based on some userful feedback from Adrian in the article comments. Thanks Adrian.)

The first step in getting multi-user development up and running is to open up a copy of the repository in question, in offline mode, making sure that it’s not also being used in online mode at the same time (you’ll find you can only open it read-only otherwise). Once you open the repository you can select Manage > Projects from the BI Administrator and start selecting presentation layer fact tables to make up your project.


Each project can contain multiple presentation layer fact tables, and selecting a fact table brings in the dimension tables that are associated with them (you don’t see these in the Project Manager folder though. You can also bring in users (a user needs to be listed in the project to be able to check the project out, these users need to be in the administrator group to be able to log in to the BI Administrator tool), initialization blocks and variables (for security, dynamic filters and so on). I ended up creating three projects, two of which were for separate fact tables that shared conformed dimensions (to see what happened when one project overwrote the dimension table design used by another project), one of which included two fact tables of which one was also listed in another project. The point of all this was to see how the Multiuser Development Environment dealt with presentation folders “owned” by more than one project and logical dimension tables that were been updated by separate projects. I also created some separate users to see how security works and how audit information was added to the project audit trail.


The next step is to create a directory on a shared network drive, and to copy this repository file to this shared location. The MDE process apparently makes changes to the file such that it’s not safe to leave it in the usual repository location ($ORACLEBI_HOME/server/repository) and so I copied it, for the purposes of this exercise, to a directory called “rpd_multiuser” on the root of my C drive. You can see a copy of the Paint repository that I’ve also copied there and worked with, as you can see the MDE process creates versions of the RPD file to support different checked-out releases of the file.


Once the file is copied to the shared drive, each individual developer then needs to go through the steps to enable their copy of BI Administrator to work in multi-user mode. This involves logging in to BI Administrator and then selecting Tools > Options, then entering the location of the shared directory into a dialog along with their name, that will appear in the audit trails for the various projects.


As this information gets stored in the Windows registry on the PC that’s running BI Administrator, it’s going to be tricky to simulate lots of different users accessing different projects as BI Administrator will only have one “Full Name” to work with, the one that’s stored in the registry. I’ll give it a go though and bear in mind that the full name is going to be the same for each user, at least in this simulation.

Once you’ve set up your projects, copied the repository to a share drive and configured each copy of BI Administrator to work in multi-user mode, you can start BI Administrator now and select File > Multiuser > Checkout Project to check your project out of the repository.


If there are multiple repository files in the shared directory, as there are in my case, you are presented with a list of available ones.


In my case I select the one that I just created, and then log in as “User1″, which should have access to the Orders Fact project. In fact when the user connects to the multi-user repository they are presented with a list of all projects, however if they select on that they don’t have permissions on then they can’t save the required local copy.


I pick a project that the user does have access to, and then am prompted to save a local copy of the repository file extract. I’m then presented with a repository that is just the presentation, business model and mapping and physical folders and table that I require to work on my project.


User2 has access to this project as well, and so I open up another BI Administrator session and log in as this user, again selecting the same project. The BI Administrator lets me open the project, which is already checked out by User1, and save a local copy of the project repository extract to my hard drive.

I then open up another BI Administrator session and connect as User1 again, this time opening the Orders and Appointments folder that has elements of the other project within it (the Product dimension) and some items that are unique to it. I finally open another session as User3 and open the Orders Fact project, which again shares dimensions with other projects, and save a local copy of the repository extract.

I now make an amendment, as User1, to the Order Returns fact project, and then select File > Multiuser > Compare with Original to see if it recognizes the change I made. This comparison is done using a copy of the original repository when I first checked the project out.


Looking at the comparison report it’s picked up the change I made.


I then make another changes as the User2 user, to the same project, adding another column to the Return Reasons Dim table. Running the comparison with original test again just highlights this user’s change, not the one carried out by the first user, as their change hasn’t been checked into the repository yet.

I switch back to User1 and select File > Multiuser > Merge Local Changes, to apply my project changes back to the main repository within the shared area.


The Multiuser feature then checks as to whether this project is locked, and if it’s not, it prompts me for some descriptive text to describe the update I’m committing, plus I can confirm or amend the Full Name that gets logged alongside the change. I use this opportunity to add a “User1″ prefix to my name, so that’s its clear which of my simulated users is making the change.


I then get presented with a Merge Repositories dialog. Now this dialog is prompting me to merge the changes in my locally stored repository with the master repository on the shared drive.


Once I press the Merge button, my local changes are applied to the master repository but not yet committed, and the Administration tool then displays the full multi-user project within the admin tool.

Now if I switch to User2 and try and merge their changes in, I get an error saying that “I am already trying to check this file in.” Switching to User3 I try and merge their changes in, to a completely different project, and I get the same error, and I’m not sure if this is because I’ve got several BI Administrator sessions open at one time all of which are trying to work in multiuser mode, or whether it’s because one has merged their changes into the master repository but not yet committed, or “published”, those changes to the master repository.

I therefore switch back to User1 which now has the multi-user repository opened (this happened after I merged that users own local changes in) and attempt to close the repository. I am then prompted to publish the changes I’ve made after performing the merge or discard them, this presumably releases the lock on the project and thereafter allows my other users to start merging their own changes back into the master repository.


Now one thing I’ve not been able to deduce is whether one project being locked then excludes any other project using that multi-user from merging and then publishing its changes; from looking at the screenshot above and the tests I’ve carried out, I suspect that (a) assuming each developer is working on their own PC, they can all independently merge changes they make on projects into the master repository, but that (b) if a single developer, working on any project using a multi-user developer takes a lock on that repository, in preparation for publishing their merged changes to it, then the others have to wait until that developer either publishes or discards the changes. Based on my test case I can’t be sure of this as I couldn’t merge any changes once one other user had done a merge, I’ll have to try and set up a multiple PC environment and see which one of these findings is actually correct.

Having said that, and no doubt there’s a few subtleties in the process and some niggles in the initial release of this feature, but on this superficial test all the bits you’d expect to see in a basic multi-developer environment are available, albeit with a bit of a complicated arrangement around the number of copies of the RPD file that you need and the multiple-step change committing process. To be honest, if Siebel had done the sensible thing and stored the repository in a relational database no doubt none of this faffing about would be needed, but then again OWB has just that and the multi-user features it has aren’t as complete as this. So all we need now is a repository that’s stored in a proper database, plus at some point in the future the ability to do proper source-control steps such as splitting and branching repositories, versioning them and so on, together with some sort of ability to include the web catalog and the BI Publisher catalog in the process, and I guess we’ll be getting there. I’ll update the posting once I know more about the master repository locking issue, but I suspect this is more down to me trying to run a test on a single PC rather than an issue with the process. Of course any feedback is welcome.


  1. Adrian Ward Says:

    Hi Mark,
    The network rpd is not locked for edits until you ‘Merge Local Changes’. This essentially just opens the network rpd in exclusive mode to you, and others cannot merge their changes in until you publish to the network (which releases the rpd).
    Try editing a dimension in two separate checked out local copies and then merge/publih in turn to the network. You can then overwrite someones work!

    Thats why I am still sceptical about the process, and where possible will always opt for a Repository ‘Master’ Developer. The gateholder who has control of the rpd at any one time. The only reason I can see it is worth the risk of multi user dev is when you have a team spread accross the world (as we do on my current client) and commnication is difficult.
    One problem is that the rpd can get quite large >15MB. When you get a local copy, and publish to a shared network, visible across the globe, it can take a very long time (20-30 mins on broadband). Also, each time you publish to the network, a copy is created. This soon eats up your disk space so you have to keep up the housekeeping.

    Avoid if you can.


  2. Mark Rittman Says:

    Hi Adrian

    Thanks for the feedback and the further info on the merge/publishing step. As I said in the posting I only had the one PC to test this out and so it was unclear whether the locking was due to this or due to the publishing process, as you clarify the locking only really starts to happen once one person starts merging their changes. One thing I’m not too clear on still is the relationship between your local copy of the RPD, used for local multiuser development, and the master copy of the multiuser repository on the share drive. I’ll have to work through this with more than one PC and track where the changes are getting written to.

    As you say, the model as it stands poses the risk of user 1’s changes overwriting user 2’s changes, but I guess that as changes are made at the column level it will only manifest itself if the two users try to modify the same columns, the most recent change will then apply. Also as you say the network and storage overhead is potentially quite large, again this points to using a proper database to hold this data rather than lots of (often large) RPD files. I think based on all this, as you say, the feature looks on the surface to be pretty useful but we need to be wary of how it actually works in practice.

    regards, Mark

  3. LJ Says:

    After merging local changes and choosing the publish to network option, the local server\repository directory which had the subset, original extracted rpd from master repository and the “original” rpd are deleted automatically. Not sure why this is happening and if it’s intended or not. I’m setup on my own pc and no network connections.

  4. Raman Says:

    Thank you very much for the postesvery useful for us also , i have some doubts shall can i post..? Need to Install the OBIEEplus in my sys my client req’ments. Partner,telemarketing contact center, teleservices,telecom services are requried. i think these are all different products with OBIEE fusion.what i need to do… pls help me out …


  5. Puneet Says:

    Thanks Mark for the above blog. I went ahead and followed the process stated and was able to successfully merge the changes from my local RPD to the network RPD. But after, the process was over, the network RPD is now opening only in Read only mode. The OBIEE services are not running on the server. Did I miss out anything???

  6. Scott Powell Says:

    I’ve never understood why more people don’t just do online changes. Each person can lock the one or two items they’re working on. Performance is good for the most part (although doing a validation check takes forever). And even in large deployments there usually aren’t 25 people who are trusted to edit the RPD.

  7. Mark Rittman Says:


    One thing to bear in mind, is that with the 10g release of OBIEE, only one concurrent online editor is supported. With 11g, up to five online editors are supported at any one time. So apart from locking issues and performance issues when you are editing online, the 10g product wasn’t actually designed with more than one online editor at one time, and you may therefore hit issues.


  8. AB Says:

    Hi,I am new to OBIEE and am having a problem merging my local changes.
    When I try to merge the project back into MUDE, I cannot see the option ‘Merge local changes’ in File>Multiuser.
    The options available are

    Multiuser > Checkout
    > Compare with Original
    >Refresh Subset
    >Publish to Network
    > Undo Publishing
    >Discard Local Changes
    Can you please point me to the right direction

Website Design & Build: tymedia.co.uk