Oracle^® Business Intelligence Server Administration Guide > Completing Setup and Managing Oracle BI Repository Files > Setting up and Using the Oracle BI Multiuser Development Environment >

Making Changes in a Multiuser Development Environment (Developers)

Before checking out projects, the developers need to set up to the Administration Tool to point to the shared network directory containing the master repository. This must be the multiuser development directory created by the Oracle BI Administrator. For more information, see Setting Up a Multiuser Development Environment (Administrator)

During checkout and checkin, a copy of the master repository is temporarily copied to the developer's local repository directory (\Oracle BI\Repository by default). After checking out projects and making changes in a local repository file, each developer can check in (merge) changes into the master repository or discard the changes.

To make changes in a multiuser development environment, perform the following tasks:

• Setting Up a Pointer to the Multiuser Development Directory
• Checking Out Repository Projects
• About Changing and Testing Metadata

Setting Up a Pointer to the Multiuser Development Directory

Before checking out projects, each developer must set up their Administration Tool application to point to the multiuser development directory on the network. The Administration Tool stores this path in a hidden Windows registry setting on the workstation of the developer and uses it when the developer checks out and checks in objects in the shared directory.

NOTE:  Until the pointer is set up, the multiuser options will not be available in the Administration Tool.

Initially, the network directory contains the master repositories. The repositories in this location are shared with other developers.

When setting up the pointer, the developer can also complete the Full Name field. Although the field is optional, it is recommended that the developer complete this field to allow other developers to know who has locked the repository. The Full Name value is stored in HKEY_CURRENT_USER in the registry, and is unique for each login.

To set up a pointer to the multiuser default directory

1. From the Administration Tool menu, choose Tools > Options.
2. In the Options dialog box, click the Multiuser tab.
3. In the Multiuser tab, next to the Multiuser development directory field, click Browse.
4. In the Browse For Folder dialog box, locate and select the multiuser development network directory, and then click OK.
5. In the Options dialog box, verify that the correct directory appears in the Multiuser development directory field.
6. In the Full Name field, type your complete name, and then click OK.

Checking Out Repository Projects

After setting up a pointer to the multiuser development default directory, a developer can check out projects, change metadata, and test the metadata. In the File > Multiuser submenu, the Checkout option is only available when there is a multiuser development directory defined in the More tab of the Options dialog box. For more information, refer to Setting up and Using the Oracle BI Multiuser Development Environment.

If a developer checks out a local repository and attempts to exit the application before publishing it to the network or discarding local changes, a message appears to allow the developer to select an action. For more information, refer to About Closing a Repository Before Publishing It to the Network.

To check out projects

1. From the Administration Tool menu, choose File > Multiuser > Checkout.
2. In the Multiuser Development Checkout dialog box, select the repository, and then click Open.

   This dialog box will not appear if there is only one repository in the multiuser development directory.

3. If prompted for your user name and password, in the Extract from dialog box, type your user name and password, and then click OK.

   If no projects exist in the repository, a message appears and the repository does not open.

4. In the Browse dialog box, select the projects that you want to be part of your project extract, and then click OK.

   If only one project exists in the master repository, it is selected automatically and the Browse dialog box does not appear.

5. In the New Repository dialog box, type a name for the new repository and then click Save.

   A working project extract repository is saved on your local machine. The name is exactly as you specified and is opened in offline mode. A log file is also created. The extracted repository might not be consistent.

   CAUTION:  A second copy of the project extract repository is saved in the same location. The name of this version contains the word Original added at the beginning of the name that you assigned to the repository extract. Do not change the Original project extract repository. It will be used when you want to compare your changes to the original projects.

About Changing and Testing Metadata

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, logical tables, change table definitions, logical table sources, and so on. Developers may also work simultaneously on the same project locally. It is important to note, however, that Oracle BI assumes the individual developer understands the implications these changes might have on the master repository. For example, if a developer deletes an object in a local repository, this change will be propagated to the master repository without a warning prompt.

The following modifications should not be made in a local repository:

• Hierarchy definitions. When modified concurrently by two developers, the changes will not be merged correctly during checkin.
• Project definitions. These should only be changed by the Oracle BI Administrator in the master repository.
• Physical Connection settings. These are intentionally not propagated and developers should not test in local environments.

After making changes to a local repository, the developer can edit the local NQSConfig.INI file, enter the name of the repository as the default repository, and test the edited metadata.

NOTE:  DSNs specified in the metadata need to exist on the developer's workstation.

For more information about testing the metadata, refer to Test and Refine the Repository.

After the local developer makes changes, tests the changes, and saves the repository locally, the local developer can perform the following tasks from the File > Multiuser submenu:

• Compare with Original. Compares the working extracted local repository to the original extracted repository. When this option, the Compare repositories dialog box opens and lists all the changes made to the working extracted repository since you checked out the projects. For more information, see Comparing Repositories.
• Discard local changes. Anytime after check out and before check in, 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 Are You Sure? dialog box appears.

• Merge local changes. Locks the master repository on the network multiuser directory to allow you to check in your changes. For more information, see Checking In Multiuser Development Repository Projects.
• Publish to the network. After you successfully merge your changes, the master repository opens locally and the Publish to Network submenu item is available. When you select this option, the lock is removed, the repository is published, and the repository closes. For more information, see Checking In Multiuser Development Repository Projects.