In the next phase of the fictional company example, Sally and Scott begin development of Phase III of the Sales initiative.
Meanwhile, Helen Rowe builds the first phase of the HR initiative and brings this new independent semantic model into production.
The following sections describe Phase III development:
In the fictional company example, Helen's application has highly sensitive personal information, such as salaries and medical information.
Meanwhile, the Sales application has legally sensitive financial information. Due to corporate security compliance, these two teams are not allowed to see each other's data or metadata. They also have little content they could share, other than generic dimensions like time dimensions. Finally, they have different business drivers, budgets, and schedules.
For these reasons, the Eden Corporation governance committee decided to use independent semantic models in the repository: one for Sales, and the other for HR. This approach requires the two teams to ensure that there are not any shared objects, and there can be no conflicts between their content. The easiest way to ensure this is to make sure that the names for all top-level objects do not conflict. Even variables and application roles must be different.
Some governance committees ensure that top-level objects do not conflict by requiring developers to put a prefix specific to each semantic model before the name of each top-level object, such as S_ for Sales and H_ for HR. This practice makes it easy to see which objects belong to which organizations. Other committees prefer to keep a master list of top-level objects, and require new applications to submit top-level object names for review to ensure there are no conflicts. In addition, two-way merges can catch any mistakes before overwrites can damage content or cause unexpected object name changes.
Another security requirement is the need to apply security to the separate MUD directories so that only the correct developers have access to each repository. Sally and Scott can only see and check out from the Sales MUD directory, and Helen can only see and check out from the HR MUD directory. The Main directory continues to exist, since it must hold the merged master that is actually in production, but now only Adam has privileges to see or modify that directory.
At Eden Corporation, a final security requirement is to disable the ability for independent semantic model developers to access the running repository in online mode after the merge. There is only a single repository password, so a developer who has the password and access to the repository can see and modify all its contents in offline mode. However, in online mode, the developer also needs a data access user name and password to log on to the Oracle BI Server. To enforce this security requirement, Adam must ensure that the developers have no privileges to log on to the production or test system in this way. Alternatively, the production operations staff can change the repository password to one that only they know, but this task must be performed on a Windows computer because repository passwords are changed using the Administration Tool.
Because Helen is working alone on her secure, independent semantic model, she does not yet need to check out a project. She needs to start building her content from a new, blank repository on her local computer.
She follows the usual steps of building and unit testing content incrementally.
When she is done with unit testing, Helen has a complete, free-standing repository. She sends it to Adam, who manually updates the master repository or performs a two-way merge in a separate location. Adam uses one of the following merge methods:
Manually updates the repository
First, Adam equalizes the two repositories to reassign IDs honoring the different names given to the top-level objects. This practice ensures that there will be no conflicts during the merge.
Next, Adam copies the master repository out of the MUD directory and into a local directory, performs the required manual updates to add the contents of Helen's repository into the master repository, and then copies the master repository back into the master directory.
Performs a two-way merge in a separate location
To create a blank repository, select File > New Repository. Then, provide a name such as blank.rpd, and a repository password. Choose No for Import Metadata and then click Finish.
After the merge, Adam creates a new project for managing the content going forward, hr_payroll. He adds Helen's content to the project. Adam then checks it out of main and posts it to the HR Branch MUD directory. Using a project checkout makes managing IDs and merges easier later.
Adam adjusts connection pool parameters, and migrates the repository to the test computer. When a bug is found, Helen checks out the hr_payroll project, fixes it, unit tests it, and publishes it. (Note that she checks her functional project out of the checked-out branch project.) Adam migrates it to the test system for further testing. When testing is complete, he merges the completed HR branch repository back into the main branch, and sends the integrated repository to integration testing on the test system.
When the integrated repository completes testing, it is ready for migration to production. Again, the options are complete repository migration, or applying a patch to the production environment using
patchrpd. Both methods require a rolling restart.
After this step, the production repository contains content for both Initiative S and Initiative H.
The image shows the parallel activities for Phase III for the fictional company example.