Publish Changes to Multiuser Development Repositories

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 Oracle BI repository
The Baseline Oracle BI repository or Master Oracle BI repository snapshot at time of project extraction
The current locally developed and changed Oracle BI repository

Changes are managed by merge and reconciliation. Most of the merging process is automatic, and changes don't 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's 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're ready to publish.

This section contains the following topics:

About the Multiuser Development Merge Process

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 don't belong to any project. Therefore, all project-related objects are checked and if a new object is found, a warning message is displayed.

Important:

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 isn't visible in extracted versions of the project until it's explicitly added to the project definition. See Create 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 aren't 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.

How Are Multiuser Merges Different from Standard Repository Merges?

The multiuser development publishing process uses the same technology as the standard repository merge process with a few important differences.

In multiuser development merges, you shouldn't want to retain changes to security settings and data sources, to prevent developers from overwriting passwords and other important objects in the master repository. Changes to security settings and data source connections aren't retained when you perform a MUD merge. In addition, inserts (created objects) are applied automatically.

See Merge Rules and Behavior for Multiuser Development Merges.

Publish to the Network

When the publishing process begins, the 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 doesn't 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?.

In the Administration Tool, from the File menu, select Multiuser, and then select Publish to Network.
Click Yes if prompted to save changes.
In the Lock Information dialog, in the Comment field, type a description of the changes that you made, then click OK.
If there are any conflicts, then the Merge Repository Wizard opens and the Define Merge Strategy screen is displayed. Make merge decisions about whether to include or exclude objects by selecting Current or Modified from the Decision list. When you select an object in the decision table, the read-only text box below the decision table describes what changes were made to that object in the current repository. You can also click View Change Statistics to see a summary of changes. Click Finish when you're finished making merge decisions.

A CSV file is created in the local directory that contains details of the merged changes.
After you confirm all the changes, click Save.

The master repository in the multiuser development directory is overwritten with the copy of the repository containing the developer's changes.

Enforce Consistent Repositories When Publishing 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.

See Set Multiuser Development Options.

If consistency errors occur, do one of the following:
- Click Yes to fix the consistency check errors immediately; the master repository remains locked.
- Click No to cancel the publishing step, fix the consistency check errors later, and unlock the master repository.
- In the Administration Tool, from the File menu, select Multiuser, and then select Undo Publishing to release the lock on the master, or when fixing the changes is more complex than you anticipated.