|
Siebel Business Analytics Server Administration Guide > Completing Setup and Managing Repository Files > Creating an Analytics Multiuser Development Environment >
Making Changes in an Analytics Multiuser Development Environment
Before checking out projects, developers need to set the multiuser directory in the Administration Tool to point to the shared network directory containing the master repository. This must be the multiuser development directory created by the administrator. During check out and check in, a copy of the master repository is temporarily copied to the developer's local repository directory (\SiebelAnalytics\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. To make changes in a multiuser development environment, perform the following tasks:
Setting Up a Pointer to the Multiuser Development Default Directory
Before checking out projects, each developer needs to set up their Administration Tool application to point to the multiuser development directory. The Administration Tool stores this path in a hidden Windows registry setting on the workstation of the developer and uses it during checkout and checkin. To set up a pointer to the multiuser default directory on a developer's machine
- From the Administration Tool menu, choose Tools > Options.
- In the Options dialog box, click the More tab.
- In the More tab, next to the Multi-user development directory field, click Browse.
- In the Browse for folder dialog box, locate and select the multiuser development network directory, and then click OK.
- Verify that the correct directory appears in the Multi-user development directory field.
- In the Options dialog box, click OK.
Checking Out Analytics 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. 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, see Creating an Analytics 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, see About Closing a Repository Before Publishing It to the Network. During checkout, the Administration Tool performs the following tasks: - In the developer's local \SiebelAnalytics\Repository directory, the Administration Tool makes a temporary copy of the master repository and writes an entry in the log file for the master repository file ([master repository].rpd.log). The entries in this log file record the time and date that the temporary repository file was created.
CAUTION: If a repository with that name already exists in this location, the developer is asked to confirm overwriting the existing repository. If the developer clicks Yes, the existing repository will be immediately overwritten in the background and after the new repository is saved, the master repository file will be automatically deleted.
- In the multiuser directory on the network, the Administration Tool writes an entry in a log file ([master repository].log). The entry in the log file records the time and date when a local repository is created, the names of the projects, the Windows login name of the developer, and the machine name where the local repositories are saved. The following is an example of an entry in the log file:
####################### 12/14/2003 6:41:55 PM: Created subset repositories originalDevelopment1.rpd and Development1.rpd based on project(s) Supplier Sales KW2 Login Name: kwolff Computer Name: KWOLFFP4
- In the developer's local \SiebelAnalytics\Repository directory, the Administration Tool saves a local copy of the selected projects in a new repository such as Development1.rpd. The developer makes metadata changes in this file.
Additionally, the Administration Tool writes an entry in a log file for the new local repository ([local repository].rpd.log). The entries in this log file record the time and date when a local repository is created and saved.
- In the developer's local \SiebelAnalytics\Repository directory, the Administration Tool saves a second local copy of the new repository, adding Original as the prefix. An example of this local copy might be OriginalDevelopment1.rpd.
- The Administration Tool writes an entry in a log file for the copy of the local repository (Original[local repository].rpd.log). The entries in this log file record the time and date when the copy of the local repository is created and saved.
- After the developer saves the new repository file, check out is complete. In the developer's local \SiebelAnalytics\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.
To check out projects
- From the Administration Tool menu, choose File > Multi-User Development > Checkout.
- In the Select repository to extract subset from dialog box, select the master repository and then click Open.
This master repository is copied to your local machine.
- In the Extract from dialog box, type your user name and password, and then click OK.
- In the Browse dialog box, select the check boxes for the projects you want to import (check out), and then click OK.
- In the New Repository dialog box, type a name for the new repository and then click Save.
The Administration Tool saves the new repository to your local machine and opens this repository in offline mode. This extracted repository might not be consistent.
CAUTION: In your local directory, you now have a copy of the extract of the master repository and the new repository you just saved. Do not modify the original extract copy of the master repository. Only make changes to the new repository that contains the projects that you checked out.
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 Siebel Business Analytics 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 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, see Process of Completing the Setup for a Repository File. After the local developer makes changes, tests the changes, and saves the repository locally, the local developer checks in the changes. About Closing a Repository Before Publishing It to the Network
If a developer checks out a local repository and attempts to exit the application before publishing it to the network or discarding local changes, the following message appears: Closing MUD repository without publishing or discarding your local changes will prevent other developers from being able to check in their work to the master repository. What would you like to do?
Publish repository, Discard local changes, Close repository and keep lock
The following is a description of these 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 > Multi-User Development 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 > Multi-User Development submenu.
- Close repository and keep lock. This closes the repository leaving the master repository locked.
Checking In Analytics Repository Projects
After changing and testing the metadata on a local machine, the developer needs to check in the projects and merge the metadata changes 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. About Checking-In Projects
When the check-in process begins, the following actions occur:
About Merging Metadata
The Administration begins the merge process involving 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 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 developer will see the changes made by the first developer.
CAUTION: The administrator needs to add newly created metadata to the project definition in 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 presentation catalog, and then checks it in, the new presentation catalog will not be visible in extracted versions of the project until it is explicitly added to the project definition. For instructions, see 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, checked out, and when these actions occurred
- 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, see Merging Analytics 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.
To check in projects to the master repository
- From the Administration Tool menu, choose File > Multi-User Development > Merge Local Changes.
- In the Lock Information dialog box, complete the following fields:
- In the Full Name field, type your complete name.
- In the Comment field, type a description of the changes that you made.
- Click OK and the following occurs:
- The master repository file from the shared network directory is copied to the local developers machine.
- The master repository file on the shared network directory is locked. You can see a [master repository].lck file on the shared network directory (hidden file). For example, Master_SiebelAnalytics.lck.
- 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, there appear to be no differences among the three repositories. However, what this means is that there are no decisions that have to be explicitly made by the developer to check-in changes.
- To see an overview of the merge decisions that will take place, click Stats.
- In the Results dialog box, click close.
- Click Merge.
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_SiebelAnalytics.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 Siebel Analytics Administration Tool dialog box, click Yes to release the lock on the repository.
The master repository on the shared network directory is overwritten with the master repository containing the developer's changes.
|
