After checking out projects or the entire repository and making changes in a local repository file, each developer can publish (merge) changes into the master repository or discard the changes.
During check-out, refresh, and publish, a copy of the master repository is temporarily copied to the developer's local repository directory, typically, ORACLE_INSTANCE\bifoundation\OracleBIServerComponent\coreapplication_obisn\repository by default.
This section contains the following topics:
Most types of changes that can be made to standard repository files are also supported for local repository files.
Developers can add new logical columns, add new logical tables, change table definitions, and change logical table sources. Developers might also work simultaneously on the same projects or entire repository locally. Oracle Business Intelligence assumes the individual developer understands the implications that these changes might have on the master repository. For example, if a developer deletes an object in a local repository, this change is propagated to the master repository when local changes are merged without a warning prompt.
To ensure metadata integrity, do not remove a physical column unless there are no logical table source mappings to that physical column. Because of this, if you use a multiuser development environment, you cannot delete a logical column and its associated physical column at the same time. Instead, you must first delete the logical column and perform a merge. Then, you can delete the physical column and perform another merge to safely remove the object.
In some cases, logical column types can change over the course of MUD development that results in unexpected logical column types. When this occurs, you can generate a list of logical columns and their types using the Generate Logical Column Type Document utility in the Administration Tool or biservergentypexml. Then use the Compare Logical Column Types utility for subsequent MUD versions to ensure that the logical column types match as expected. For example, you can generate a logical column type list for repository version 20, and use the Compare Logical Column Types utility to compare the list against repository version 30. See Generating a List of Logical Column Types and Comparing Logical Column Types.
Changes to physical connection settings are not propagated to the master repository upon merge and publish. This ensures that developers can apply settings for their local test data sources to perform unit testing of their model changes without impacting other developers.
In addition to physical connection settings, security settings and database feature table changes are not retained in a multiuser development merge to prevent developers from overwriting passwords and other important objects in the master repository.
After making changes to a local repository, the developer uploads the repository and tests the edited metadata.
Note:
DSNs that are specified in the metadata must exist on the developer's workstation.
These topics provide information on making changes in a multiuser development environment using projects.
The Oracle Administration Tool performs the following tasks during checkout.
The Administration Tool tasks include:
In the developer's local repository directory, the Administration Tool makes a temporary copy of the master repository.
Caution:
If a repository with that name exists in this location, the developer is asked to confirm overwriting the existing repository. If the developer clicks Yes, the existing local repository is immediately overwritten in the background and after the new repository is saved, the temporary master repository file is automatically deleted.
In the developer's local repository directory, the Administration Tool saves a local copy of the selected projects in a new repository such as Metadata1.rpd. The developer provides a name for the local copy. The developer makes metadata changes in this file. The number is incremented for each checkout for that session.
In the developer's local repository directory, the Administration Tool saves a second local copy of the new repository, adding original as the prefix, for example, originalMetadata1.rpd.
After the developer saves the new repository file, check out is complete. In the developer's local repository directory, the temporary copy of the master repository is automatically deleted.
Caution:
When the developer selects and saves the projects to a local repository file, the Administration Tool does not place a lock on the projects in the master repository on the shared network drive. Therefore, nothing physically prevents others from working on the same project. To determine if a project has been checked out, you need to look in the log file in the multiuser development directory on the shared network drive.
You can use the Oracle BI Server extractprojects utility to cut projects from a given repository without the overhead of the MUD environment.
The extractprojects utility is available for Windows and UNIX systems. You can use extractprojects only with binary repositories in the RPD format.
The extractprojects utility generates an RPD file that includes the set of projects that you specify. The utility does not perform the tasks that are performed when you check out projects using the Administration Tool, such as saving an original repository file or tracking the extract as a check-out in the MUD directory.
The extractprojects utility is located in the following directory:
BI_DOMAIN/bitools/bin
Syntax
The extractprojects utility takes the following parameters:
extractprojects -B base_repository_name -O output_repository_name {-I input_project_name} [-P repository_password] [-L] [-E project_list_file_name]
The variables are as follows:
base_repository_name is the name and path of the repository from which you want to extract projects.
output_repository_name is the name and path of the repository generated by the utility.
input_project_name is the name of a project you want to extract. You can enter multiple projects. Precede each project entry with -I, for example, -I project1 -I project2. If the project name contains spaces, enclose it in double quotes, for example, "project 1".
The repository_password argument is optional. If you do not provide the password argument, you are prompted to enter the password when you run the command. To minimize the risk of security breaches, Oracle recommends that you do not provide the password arguments in the command line or in scripts. The password argument is supported for backward compatibility only. For scripting purposes, you can pass the password through standard input.
- L enables logging. When logging is enabled, a log file with the name format, ProjExtr.YYYYMMDD.HHMMSS.xml, is created in the Oracle BI Server logging directory. For example:
ORACLE_INSTANCE/diagnostics/logs/OracleBIServerComponent/coreapplication_obisn/ProjExtr.20100616.082904.xml
-E is an optional argument that lets you print a list of all projects contained in a repository into a file. Specify project_list_file_name after the option to specify the file name and location in which you want to store the project names. -E is only used with -B and -P and does not actually perform a project extract.
The -U and -F are visible in the syntax list, but are for internal use only.
Example
The following example extracts project1 and project2 from my_repos.rpd and creates a new repository called extract_repos.rpd.
extractprojects -B my_repos.rpd -O extract_repos.rpd -I project1 -I project2 Give password: my_rpd_password
Note:
Provide the full path names to your repository files, both the input file and the output file, if they are located in a different directory.
Use the Refresh Subset option to update the local project extract with any changes that were made to the master repository.
This option also merges the latest changes with the local project extract. Perform this task as an incremental step during development before publishing your final changes at the end of your development session.
It is a best practice to refresh your local project extract frequently so that conflicts during merge can be identified and dealt with on an incremental basis. If too many changes are merged at one time, then making the appropriate merge decisions for conflicts can be confusing and error-prone.
The preferred method for making changes to a repository in a multiuser development environment is to use projects.
You might encounter situations during which you want to make changes that involve you accessing the entire repository at one time.
Use this method only when necessary, because system performance is likely decrease, especially during merges of large repositories.
You can perform many tasks from the Multiuser menu.
After the local developer makes changes, tests the changes, and saves the repository locally, the local developer can perform the following tasks:
Compare with Original. Compares the working extracted local repository to the original extracted repository. When you select this option, the Compare repositories dialog is displayed and lists all the changes that were made to the working extracted repository since you checked out the projects or the entire repository.
Refresh Subset. Refreshes the local project extract with any changes that were made to the master repository. The changes from the master are merged with your local changes.
If changes have been made to the master repository, then the old project extract file, originalfilename.rpd, is replaced with a new project extract file called currentfilename.rpd.
Publish to Network. Publishes changes made to the local project extract or the entire repository to the master repository. A lock is acquired to lock the master repository during the publish step. Publishing the changes automatically performs a Refresh Subset operation to merge the local changes with any additional changes from the master. Then, the merged changes are published to the master repository, the lock is released, and the local repository is closed.
Undo Publishing. Used when mandatory consistency checks are enforced during the publishing step, and errors occur. When you are notified of consistency check errors during publishing, you can choose to fix the errors immediately, as part of the publishing step. The master repository is locked during this process. If you need to release the lock on the master and fix the changes later, then select Undo Publishing to release the lock and return to the latest subset extract repository.
Discard Local Changes. Any time after check out and before publishing, you can discard your changes. When you select this option, the working repository closes without giving you an opportunity to save your work.
Caution:
If you select this option, there is no opportunity to change your mind. For example, no confirmation dialog is displayed.