Multi-User Development Set Up Using OBIEE Administration Tool

Introduction

Multi-user development (MUD) provides a mechanism for concurrent development on overlapping code bases. Oracle Business Intelligence provides a MUD environment that manages subsets of metadata, in addition to multiple users, by providing a built-in versioning system for repository development. By default, the Oracle BI repository development environment is not set up for multiple users. However, online editing makes it possible for multiple developers to work simultaneously, though this may not be an efficient methodology, and can result in conflicts, because developers can potentially overwrite each other’s work. That’s when MUD is useful to the developers to work simultaneously on a single RPD.

The Oracle BI repository development process adheres to the merge and reconciliation technique to manage concurrent development. Most of the merging process is automatic, and changes do not conflict. When they do developers need to take decision which change to keep and what to neglect. Developers check out the file and make changes locally. Changes are then merged into a final, merged repository (rpd) file.

Concept:

The MUD environment is done by creating Projects in the repository file in the BI Administration Tool and then copying this repository file to a shared network directory. Developers can check out projects, make changes, and then merge the changes into the master repository. The entire concept of MUD (Multi User Development) revolves around objects called as Projects. Projects are subsets of objects based on logical fact table/ subject areas that can be assigned to individual users. So, the idea is to assign different projects to different users. Also, each of these projects can contain one or more Logical Fact tables. As soon as a logical fact table is included all the other dependent objects would automatically be part of the project. This post will describe the entire process of how to create the projects in a repository, to save the repository file in a shared location, and the remaining steps of working in MUD environment for multiple users/developers. For that let’s assume there is a master repository on which multiple developers will be working.

To set up MUD, we need to follow the below mentioned steps:

Step 1: Open the master RPD offline and go to Manage -> Projects

 

Step 2: As the project manager window pops up click on Action -> New Project.

 

Step 3: Click on ‘Subject Area’ radio button in Group Facts by option and name the project (e.g. HR_WORKFORCE_PROFILE). Double click on the subject area which needs to be included in this project.

 

Step 4: Similarly select necessary Application roles from the left to right panel.

 

Step 5: Similarly add corresponding Users, Variables, Initialization Blocks, Presentation (Subject Areas) to the project and click on OK.

 

Step 6: See the project being created.

Step 7: Create another project HR_COMPENSATION following similar steps. Like this multiple projects can be created for different subject areas. It is best to create projects driven by subject areas rather than anything else.

Step 8: Move the master RPD to a shared drive location in the network.

Step 9: Open Oracle BI Administration Client from a machine within the network and go to Tools -> Options.

Step 10: Put the path of the shared directory (where the master RPD is kept) as shown in the picture below, put full name of the user accessing it and click on OK. MUD set up is now complete.

Step 11: To start working on MUD, click on File -> Multiuser -> Checkout.

Step 12: Enter the repository password and click on OK.

Step 13: It will give you a message Opening Repository “repository name”……Loading Objects.

Step 14: Select the project (one or more) one would be working upon and click on OK.

Step 15: Save the checked out portion of the rpd into the repository directory of the oracle bi client / server as shown.

Note: The rpd has to be saved in repository directory and not any other location (such as desktop etc.). Or else this portion can not be published to the network.

Step 16: The saved part of the rpd opens with only a single subject area and its BMM components.

Step 17: Create a new column in the Time Presentation folder named Date 2.

Step 18: Select Refresh Subset.

Note: This process refreshes a developer’s checked out repository with any changes that have been made and checked in by other developers since the developer checked out his or her own version from the main RPD. This is a very important step in the MUD process. If not performed, there is a possibility that the changes checked in by other developers will be lost.

Step 19: Click Ok on Refresh is not required because no changes have been checked in by any other developer.

Step 20: Click on Multiuser -> Publish to Network.

Step 21: Add some comment describing the changes that the user has made (audit purpose) and click on OK.

Step 22: It gives a message Opening Repository ….. Loading Objects.

Step 23: Once more check out the same project from the master repository and check that the change is available.

Step 24: The above mentioned steps are appropriate only for the cases when two or more users are checking out independent subject areas/ projects. That means when there is no common piece of objects between two or more checked out versions of the same master RPD there will not be any issue while refreshing the subset / publishing to the network. There can be another scenario where Developers Work on the Same Subject Areas. Suppose,

• Developer 1 checks out HR_WORKFORCE_PROFILE project
• Developer 2 also checks out HR_WORKFORCE_PROFILE project (before Developer 1 publishes his changes to the network).
• Developer 1 modifies an object in HR_WORKFORCE_PROFILE subject area.

• Developer 1 refreshes subset. It shows refresh is not required.

• Developer 1 publishes to network.

• In the meantime developer 2 updates an object within the same subject area.

• Developer 2 selects Refresh Subset and the Merge Repository Wizard window appears. Decisions on which changes to keep have to be made at this point before the developer can proceed.

• Select “Modified” radio button after selecting ‘By Property’ from the decision column to keep the changes made by Developer2 (Age Band Minimum Months_Updated_By_Developer2)

Note: There are three windows at the bottom of the Merge Repository Wizard Window.

1. Original Repository: Shows the object name in the repository at the time of check out
2. Modified Repository: Shows the change made to the repository by this developer
3. Current Repository: Shows the changes in the current repository after refresh (contains the changes published by Developer 1)

• For the object modified by Developer 1 select “Current” to keep the changes. Click on Finish and check consistency.

• Publish to Network.

• Changes from the two developers will now be available in the Repository. To verify, check out the project one more time and confirm.

Migrating MUD Repository Online: This process should be performed by the Lead Developer or a gate keeper.

1. Copy the MUD repository to a staging folder.
2. Rename the MUD RPD to the online RPD name.
3. Upload the RPD to the online folder using the Enterprise manager.