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.