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.
A more efficient development environment would permit developers to modify a repository simultaneously and then check in changes. This can be done by setting up the multiuser environment using the Oracle BI Administration Tool to support concurrent development.
The Oracle BI repository development process adheres to the classic Software Configuration Management (SCM) process, and utilizes a three-way merge to manage concurrent development. Changes are managed by merge and reconciliation.
Most of the merging process is automatic, and changes do not conflict.
Developers check out the file and make changes locally. Changes are then merged into a final, merged repository (rpd) file.
For example :
- after completing an implementation, the administrator may want to deploy Oracle BI to other functional areas of the company. In this example, multiple developers need to work concurrently on subsets of the metadata and merge these subsets back into a master repository without their work conflicting with that of the other developers.
- in other organizations, a single developer might manage all development. For simplicity and performance, this developer might want to use a multiuser development environment (MUDE) to maintain metadata code in smaller chunks instead of in a large repository.
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 (MutliUser Development) revolves around objects called as Projects. Projects are subsets of objects based on logical fact table 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.
Create a first project in the master repository
Typically when we start with a repository, we would not be having any Business Model or presentation layers.
So, to be able to assign objects to projects, we must create a dummy environment by :
- importing all the physical tables and creates the physical joins
- creating a dummy Business Model and then a dummy presentation layers
- creating Users, Init Blocks and Variables.
After performing this steps, we can finally create a project.
Setting up the master repository in a shared directory
For performing this step, you must :
- create a shared directory
- copy the repository just created above
- setting the options in the multiuser tab (the shared directory and your name basically).
In the Oracle BI Administration Tool, select File > Multiuser > Checkout.
You will see then the project where you have right.
Select on which project you want to work and the process purpose you to save it in a subset repository.
If you have a problem on this step
* check that you have all right
* you can create a dummy file
After saving the subset, you will see 2 repository files in your local repository directory (OBI_Home\server\Repository) :
- your subset
- the original file that have be automatically generated with the name original_your_subset_file_name
To ckeck in, you have to :
- merge the modifications
- verify the consistency of the new master repository
- publish or cancel your modifications according to the previsou step.
To merge the modifications, Select File > Multiuser > Merge Local Changes. This merges your changes to the shared repository.
Select ok. The next screen let you the possibilities to describe your modification. This information will be available in the history management.
A merge screen appears. You will may be have conflicts with other user and you must resolve them. See the merge process in detail to more details.
In the Shared directory, you can see that an additional file MasterRepository.lck appears in the directory; this is the lock file, which is created when the shared repository is locked. Also, when you navigate to OBI_HOME\server\Repository you can see that subset.rpd and subset.log are generated.
No other user can check in projects while the shared repository is locked. You must release it by publishing it.
If you try to close the repository (File > Close to close the repository). A warning appears indicating that you are closing an MUD repository without publishing or discarding your local changes, so the lock on the repository has not been released.
At this point, you have the option to :
* publish the repository (copy the local copy of the shared repository to the server),
* discard the local changes,
* or close the repository and keep the lock.
To publish (unlock the master repository, you must publish it (Select File > Multiuser > Publish to Network). The local copy of the shared repository is merged with the shared repository and then closed and deleted.
Select File > Multiuser > History. Log in. The several version of the master repository is opened and the history of changes is displayed.