About the Multiuser Development Environment

Oracle Business Intelligence multiuser development facilitates creating application metadata in enterprise-scale deployments.

Application metadata is stored in a centralized metadata repository (RPD) file. The Administration Tool is used to work with these repositories. You do not use a multiuser development environment with MDS XML-format repositories.

Master repository refers to the copy of a repository in the multiuser development directory

The following are examples of how you might use a multiuser development environment:

  • Several developers work concurrently on subsets of the metadata and then merge these subsets back into a master repository without their work conflicting with other developers. For example, after completing an implementation of data warehousing at a company, an administrator might want to deploy Oracle Business IntelligenceOracle Business Intelligence to other functional areas.

  • A single developer manages all development. For simplicity and performance, this developer might want to use the multiuser development environment to maintain metadata code in smaller chunks instead of in a large repository.

In both examples, an administrator creates projects in the repository file in the Administration Tool, then copies this repository file to a shared network directory, called the multiuser development directory. Developers are able to check out projects, make changes and then merge the changes into the master repository. When developers check out projects, using the Administration Tool, files are automatically copied and overwritten in the background. Your administrator must perform setup tasks. Developers must pay close attention to the Administration Tool messages that appear during check-out, merge, and publish procedures.

When developers check out projects, repository files are not automatically copied or overwritten. Instead, the Administration Tool creates two new files when projects are checked out: one to hold the original project data, and one to hold the project changes.

For example, when a repository developer checks out project A from master.rpd in the C:\multiuser development directory, the Administration Tool extracts all metadata related to project A and prompts the developer for a new file name to save the data. When the developer chooses a new file name, for example Mychanges.rpd, the Administration Tool creates two new files:

  • A file called MyChanges.rpd that contains the changes made by the developer

  • A file called originalMyChanges.rpd that contains the original project data

The Administration Tool determines the developer's changes by comparing the Mychanges.rpd with the originalChanges.rpd. The information about what has changed is required during the multiuser development merge process.


To reduce storage needs, repositories in Oracle Business Intelligence Enterprise Edition 12c are stored in a compressed format. You might notice that the size of an RPD file opened and saved in this release is significantly smaller than the size of RPD files from previous releases.

About the Multiuser Development Process

Multiuser development presupposes a clear understanding of customer technical and business objectives.

It also requires that you follow clearly defined development processes and adhere rigorously to those processes, including consistent merging and reconciliation practices.

The following procedure shows the general steps to follow when deploying a multiuser development environment. The first three steps are usually performed by an administrator, and the remaining steps are usually performed by one or more developers. See Creating Projects.


Oracle recommends merging changes as soon as possible and as often as possible. Frequent merges makes conflict resolution easier and simplifies the merge.

  1. Define projects to organize voluminous metadata into manageable components. Consider these tips:

    • Use smaller RPDs to shorten and simplify development effort and unit testing.

    • Organize development resources by projects to spread workload and reduce inconsistencies and overwrites.

  2. Set up a shared network directory to use as the multiuser development directory.

  3. Copy the master repository to the multiuser development directory.

  4. Extract one or more projects or the entire repository for local development.

  5. Merge repository objects and resolve conflicts.

    • Because metadata objects are often highly interrelated, several developers could be working on the same objects.

    • You can perform regular subset refreshes to merge your local changes with the latest version of the master. When configuration conflicts occur during the merge process, developers are prompted for the correct process.

  6. Publish changes to the network.

    • A final subset refresh (merge) is performed during the publishing step. Many developers can simultaneously work on the same objects, but only one can publish at a time. The repository is locked during the publishing step.

  7. Use Logging and Backup features to identify points of erroneous or incorrect configuration.

    • The log file tracks multi-development activity, along with comments.

    • The master repository and developer repositories are automatically backed up for future reference and for use in manual rollback.