After changing and testing the metadata on a local computer, the developer must publish local changes to the master repository in the multiuser development directory.
The Oracle BI repository development process uses a three-way merge to manage concurrent development. Metadata merges are done first on local environments and then merged with the master repository. A three-way merge identifies local changes based on the following repository characteristics:
The Master RPD
The Baseline RPD or Master RPD snapshot at time of project extraction
The current locally developed and changed RPD
Changes are managed by merge and reconciliation. Most of the merging process is automatic, and changes do not conflict. In case of any conflicting metadata sources, developers can locate and resolve them.
An administrator can also merge the changes from multiple repositories manually, or import objects from different repositories outside of a particular MUD environment.
Ensure that you merge changes frequently. The merge process is very complex and can become difficult if there are too many changes. See Merge Rules for how objects are merged during the merge process.
It is a best practice to refresh your subset repository regularly to identify conflicts early. Refreshing your subset performs a subset remerge with the latest version of the master, then leaves the repository open for you to continue making changes until you are ready to publish.
This section contains the following topics:
The topic describes the multiuser development merge process.
The merge process involves the following files:
Local (subset) repository, either original or current (refreshed). The local subset repository is one of the following:
If no subset refresh has been performed, contains the state of the projects or the entire repository as originally extracted. This repository name begins with original, for example, originalDevelopment2.rpd.
If a subset refresh has been performed, contains the state of the projects or the entire repository since the last merge that occurred during the subset refresh. The repository name begins with current, for example, currentDevelopment2.rpd.
Modified local (subset) repository. Contains the extracted projects after being modified by the developer. This version is stored in the same location as the original or current version of the local subset repository.
Latest master repository. The latest master is copied locally for the merge, then published to the multiuser development directory after the merge. Other developers could have made changes to file before this merge.
During the merge, the Administration Tool checks for added objects and if found, a warning message is displayed. The following list describes what happens during this step:
Warning about added objects. A developer who checks out a project has the ability to modify that project in any way and check it back in. Deletions and modifications are ways in which the integrity of the project is maintained. However, adding objects might introduce objects into the repository that do not belong to any project. Therefore, all project-related objects are checked and if a new object is found, a warning message is displayed.
You must add newly created metadata to the project definition in the master repository for it to be visible in future extracted versions of the project. For example, if a developer checks out a project, adds a new object, and checks it in, then the new object is not visible in extracted versions of the project until it is explicitly added to the project definition. See Creating Projects for instructions.
Aggregation of related objects. In the warning message, only the parent object is reported. The Administration Tool aggregates all the objects to make the message more usable. For example, if a developer added a new business model, only the business model name is included in the warning message to the user. The names of the tables, columns, and dimensions are not displayed to the user.
When a developer publishes changes to the network, the following actions occur:
The master repository in the multiuser development directory is overwritten with the repository that contains the developer's changes.
The master_repository.lck file is deleted. If another developer checks out the changed project from the master repository or checks out the entire repository, then the changes made by the first developer are exposed to the other developer.
The multiuser development publishing process uses the same technology as the standard repository merge process with a few important differences.
For example, for MUD merges, you typically do not want to retain changes to security settings and data sources, to prevent developers from overwriting passwords and other important objects in the master repository. Because of this, changes to security settings and data source connections are not retained when you perform a MUD merge. In addition, inserts (created objects) are applied automatically.
When the publishing process begins, the Oracle BI Administration Tool automatically copies the current version of the master repository from the multiuser development directory to the local repository directory on the developer's computer.
The published location is similar to
ORACLE_INSTANCE\bifoundation\OracleBIServerComponent\coreapplication_obisn\repository. The publishing process also updates the log files in the local and multiuser development directories. This is necessary because the master repository in the multiuser development directory might have changed after the developer checked out the projects, or since the last subset refresh.
A lack of conflicts does not mean that there are no differences between the repositories. Instead, it means that there are no decisions that have to be explicitly made by the developer to publish changes. See How Are Multiuser Merges Different from Standard Repository Merges? .
A CSV file is created in the local directory that contains details of the merged changes.
The master repository in the multiuser development directory is overwritten with the copy of the repository containing the developer's changes.
You can enforce a mandatory consistency check during the Publish to Network step by setting the Mandatory Consistency Check option to Yes in the multiuser development options file.