|
Oracle® Business Intelligence Server Administration Guide > Completing Setup and Managing Oracle BI Repository Files > Setting up and Using the Oracle BI Multiuser Development Environment >
Checking In Multiuser Development Repository Projects
After changing and testing the metadata on a local machine, the developer needs to merge the local changes into the local master check in the projects into the master repository on the shared network directory. Only one developer at a time can merge metadata from a local repository into the master repository. Therefore, the master repository is locked at the beginning of the merge process. About Checking-In Projects
When the check-in process begins, the following actions occur: - The Administration Tool determines if the master repository is currently locked. If not, it locks the master repository, preventing other developers from performing a merge until the current merge is complete, and records the lock in the log file.
- For other developers, the Merge Local Changes option on the File > Multiuser menu will be unavailable until the current check-in process has been successfully completed.
- The Administration Tool automatically copies the current version of the master repository from the shared network directory to the \\Oracle BI\Repository directory on the developer's machine and updates the log files in the local and shared network directories. This is necessary because the master repository in the shared network directory might have changed after the developer checked out the projects.
About Merging Multiuser Development Metadata
The merge process involves the following files: - Original of the local (subset) repository. Contains the state of the projects as originally extracted. This repository name begins with Original. An example of the file name for this copy might be OriginalDevelopment2.rpd. This version is stored in the same location as the modified (or working) version of the local repository.
- 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 version of the local repository.
- Master repository in network shared directory. This may have been modified by other developers before this merge. (For example, Master_SiebelAnalytics.rpd.)
During the merge, the Administration Tool checks for added objects and if found, a warning message appears. The following list describes what happens during this step: - Warning about added objects. When a person checks out a project, they have 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 appears.
- 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 appears in the warning message to the user, not the tables, columns, dimensions, and so on.
When the developer closes the Administration Tool, the following actions occur: - The master repository on the shared network directory is overwritten with the master repository containing the developer's changes.
- The [master repository].lck file is deleted. If another developer checks out the changed project from the master repository, the changes made by the first developer are exposed to the other developer.
CAUTION: The Oracle BI Administrator needs to 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 then checks it in, the new object will not be visible in extracted versions of the project until it is explicitly added to the project definition. For instructions, refer to Creating Projects for a Multiuser Development Environment.
Tracking Changes to the Master Repository
A summary of the development activities on the master repository is in the [master_repository].log. This log contains a record of the following activities: - Projects that have been checked in and checked out and when these actions occurred
- The NT login name and computer name initiating the transaction
- When locks are created and removed
Differences Between the Multiuser Merge and Standard Repository Merge Processes
The multiuser development check-in process uses the same technology as the standard repository merge process with a few important differences. For more information about the standard repository merge, refer to Merging Oracle BI Repositories. The following list describes the differences that occur during a multiuser development merge: - Inserts are applied automatically. Because a subset of the master repository is being used as the original repository, most objects in the master repository appear to be new. This would result in many unnecessary prompts that the developer would have to manually approve. Therefore, inserts are applied without a prompt during a multiuser development merge.
- Conflicts that are not inserts but are resolved as a result of the automatic inserts are applied without a prompt during a multiuser development merge.
- The database and connection pool properties on the server take precedence over the same properties on the developer's machine. This precedence are applied without a prompt during a multiuser development merge.
About Closing a Repository Before Publishing It to the Network
If you attempt to close an unpublished, locked repository without selecting one of the options in the File > Multiuser submenu, the Closing MUD repository dialog box opens with the following options: - Publish to Network. Publishes the merged repository to the network share as the new master, releases the lock on the master, and the event is logged. This option is available after a Merge Local Changes event occurs. This option is also available on the File > Multiuser submenu.
- Discard Local Changes. Releases the lock on the master repository and records the event in the log. This option is available after a Checkout or Merge Local Changes is performed. available on the File > Multiuser submenu.
- Close repository and keep lock. This closes the repository leaving the master repository locked.
To check in projects to the master repository
- From the Administration Tool menu, choose File > Multiuser > Merge Local Changes.
- In the Lock Information dialog box, in the Comment field, type a description of the changes that you made, and then click OK.
- In the Merge repositories dialog box, verify that the Original local repository and Modified local repository file names are correct.
In the Merge repositories dialog box, it might appear that there are no differences between the repositories. However, what this means is that there are no decisions that have to be explicitly made by the developer to check-in changes.
- For an overview of the merge decisions that will take place, click Stats.
- In the Results dialog box, click close.
- Click Merge.
- If asked if you want to check global consistency, click Yes or No.
The changes are merged and the merged local repository file opens. In the developer's local directory, a CSV file is created that contains details of the merged changes.
- Verify that the changes made in the modified local repository are reflected in this merged local repository.
CAUTION: The merged repository has the same name as the shared repository, but this is still a local copy.
- After you confirm all the changes, click Save.
This saves the merged repository locally, and then, uploads this repository to the shared network directory with a 000 file extension. For example, Master_Sales.000.
At this point, the changes made by the developer are still not saved to the master repository in the shared network directory.
- To commit these changes to the master repository in the shared network directory, close the Administration Tool.
- In the Closing MUD repository dialog box, select Publish to Network.
The master repository on the shared network directory is overwritten with the copy of the repository containing the developer's changes. For more information about the options in this dialog box, see About Closing a Repository Before Publishing It to the Network
|
