Administrator Roles:

Setting Up a Multiuser Development Environment

(Administrator)
To prepare for multiuser development, the administrator performs the following tasks:
■ Creating Projects for a Multiuser Development Environment. In the repository, create
the projects that your developers need.
■ Set Up the Shared Network Directory. Identify or create a shared network directory
that will be dedicated to multiuser development.
■ Copy the Master Repository to the Shared Network Directory. After creating all
projects, you copy the repository file in which you created the projects to the shared network
directory where it will be used as your master repository for multiuser development.
NOTE: In this section, we use the phrase master repository to refer to this copy of a repository
in the shared network directory.

Creating Projects for a Multiuser Development Environment

A project consists of a discretely-defined subset of the metadata. Projects can consist of Presentation
layer catalogs (subject areas) and their associated business model logical facts, dimensions, groups,
users, variables, and initialization blocks.
The Oracle BI Administrator creates projects in a repository and copies this repository to a shared
network directory. A best practice is to create projects of manageable size based on individual logical
star schemas in the business model. For Oracle BI projects that are just beginning, the best practice
is to begin with a repository containing all the necessary physical table and join definitions. In this
repository, you create a logical fact table as a placeholder in the Business Model and Mapping layer
and a presentation catalog as a placeholder in the Presentation layer. As you add business model and
presentation catalog metadata, new projects based on individual presentation catalogs and logical
facts can be created.
NOTE: Only one person at a time can create projects in a master repository.
When creating a project, the Oracle BI Administrator selects a presentation catalog or a subset of
logical fact tables related to the selected presentation catalog, and the Administration Tool
automatically adds any business model and physical layer objects that are related. An object can be
part of multiple projects.

After you create projects, they become part of the metadata and are available to multiple developers
who need to perform development tasks on the same master repository. When defined this way,
projects typically become a consistent repository after a developer checks out the projects and saves
them as a new repository file.

To create a project for a multiuser development environment

1 In the Administration Tool menu, choose File > Open > Offline.
2 In the Open dialog box, select the repository that you want to make available for multiuser
development, and then click OK.
3 In the Administration Tool menu, choose Manage > Projects.
4 In the Project Manager dialog box, in the right panel, right-click and then select New Project.
The left pane contains the objects that are available to be placed in a project. The right pane
contains the objects that you select to be part of the project.
5 In the Project dialog box, type a name for the project.
6 Perform one of the following steps to finish creating the project:
■ In the Project dialog box, expand the catalogs and select one or more logical fact tables
within the business model that are related to the presentation catalog, and then click Add.
The project is defined as explicitly containing the logical fact tables and implicitly containing
all logical dimension tables that are joined to the selected logical fact tables (even though
they do not appear in the right pane).
■ In the Project dialog box, select a presentation catalog and then click Add.
The Administration Tool automatically adds all the logical fact tables.
7 To remove any fact table from the project, in the right pane, select the fact table and click
Remove.
8 Add any Catalogs, Groups, Users, Variables, or Initialization Blocks needed for the project.
NOTE: You must add all developers who need to work on the project or they will not be allowed
to check out objects.
9 Click OK.

Set Up the Shared Network Directory

After defining all projects and set up the shared network directory, the Oracle BI Administrator needs
to identify or create a shared network directory that all developers can access, and then upload the
new master repository to that location. This shared network directory needs to be used only for
multiuser development. This directory typically contains copies of repositories that need to be
maintained by multiple developers.

Developers create a pointer to this shared network directory when they set up the Administration
Tool on their machines.
CAUTION: The Oracle BI Administrator must set up a separate, shared network directory that is
dedicated to multiuser development. If not set up and used as specified, critical repository files can
be unintentionally overwritten and repository data can be lost.

Copy the Master Repository to the Shared Network Directory

Make a copy of the master repository file and paste it in the directory that you have dedicated to
multiuser development. Projects from this master repository will be extracted and downloaded by
the developers who will make changes and then merge these changes back into the master
repository.
After you copy the repository to the shared network directory, notify developers that the multiuser
development environment is ready.

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.

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.

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.
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.

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.
■ 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.
■ 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.

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.

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.
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.

Deleting Multiuser Development History

Only the Administrator can delete history. Administrators are defined in a special hidden option file
in multiuser development directory. This option file has the following properties and characteristics:
■ Must have the HIDDEN flag turned on.
■ Can have network access privileges assigned only to multiuser development administrators.
■ Has the same base name as the master repository, but the extension is OPT. For example, for
\\network\MUD\sales.rpd, the administrator might create the hidden file
\\network\MUD\sales.opt.
■ The OPT file is a TXT file in the format:
[Options]
Admin=admin1;admin2
Administrators are defined by their network login names. When multiple administrators exist,
administrator names are separated by semicolons. For example:
[Options]
Admin=jsmith;mramirez;plafleur
An administrator can delete the entire MUD history or the oldest 1 to n versions. It is not possible to
delete versions in the middle of the range. For example, an administrator cannot delete version 3 if
there are still versions 2 and 1. If an administrator deletes the entire MUD history, newly assigned
version numbers restart at version 1. If one or more versions are not deleted, the newly assigned
version numbers continue from.