OBIEE: Enabling Multi-User Development

Thanks to Venkatakrishnan J for a large portion of the content for this entry. His original entry was published on March 27, 2008.

Enabling Multi-User Development (MUD) to work with the pre-built out of the box repository is the same process as if you are working with a custom built rpd. Typically one implements this solution when there are many data sources and lots of tables; it would make sense to distribute the repository development work to multiple users. In our example we will introduce MUD as a basic feature because we will have many developers between multiple project iterations. The MUD solution is a feature of the OBI EE admin tool wherein multiple users can work on the repository at the same time. The concept of Repository Merging was actually introduced in the product in order to facilitate MUD.

Let’s start with a simple diagram from Oracle below.




The above diagram illustrates how the MUD works. To implement the solution we need to follow the pre-requisites

1. A shared drive to host the Master Repository
2. All developer workstations should have access to the master repository.
3. All developer workstations must have the admin tool installed.
   

For the MUD to work, the repository that is shared by developers should be kept in a shared directory (Samba share if on Linux). The shared directory should be accessible by each member of the development team. In each of the client’s Admin tool, enter the Shared Directory path.

Now, open the Master repository in offline mode. In MUD each object in the repository will be organized into Projects. So, from within the Admin tool navigate to Manage - Projects.



This will open up a project window. Projects are basically subsets of objects within the Admin tool that can be assigned each developer. The idea being that each developer has his/her own objects assigned to different projects to work on. Typically, each of these projects contains one or more Logical Fact tables from the BMM. As soon as a logical fact table is included all the other dependent objects would automatically be part of the project. It is recommended that one import all the physical tables and create the physical joins in the repository first before implementing MUD. Since we are using the pre-built Financial and Procurement Analytics we don’t have to worry about this. Good news is we can assign Users, Init Blocks and Variables to a project.



After creating and assigning objects to a project, the next step is to save the master repository in a shared drive. Now, open up the Admin tool and navigate to File - Multiuser - Checkout. This Check out process does 2 things

1. Copies the Master repository from the shared drive to the local drive (This will serve as the developer’s local master repository).
2. Allows you to choose the project that you have the authority to work on.
3. Creates a subset repository which contains only the selected project related objects for that developer.
   

For our example the idea is to work on the subset repository (like creating Financials – GL, Procurement) and then after developer completes their unit tests merge the changes back to the local master repository. The merge process will lock the master repository in the shared drive until it’s complete and then release the lock by selecting “Publish to Network” which will copy the modified and merged local master repository to the shared drive. The process would be the same for the other developers.