Phase III - Independent Semantic Model Development
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:
Security Considerations for Multiple Independent Semantic Models
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 aren't 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 repository for Sales, and the other for HR. This approach requires the two teams to ensure that there aren't any shared objects. No conflicts can exists between the two repositories. The easiest way to ensure this is to make sure that the names for all top-level objects don't conflict. You must also use different variables and application roles.
Some governance committees ensure that top-level objects don't 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. Two-way merges can also 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's 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. The production operations staff can change the repository password to one that only they know, you must perform the change on a Windows computer because repository passwords are changed using the Model Administration Tool.
HR Semantic Model Developer Builds Content
Because Helen is working alone on her secure, independent semantic model, she doesn't need to check out a project. She needs to start building her content from a new, blank repository on her local computer.
Helen 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 the repository to Adam. He 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 by:
-
Adam equalizes the two repositories to reassign IDs honoring the different names given to the top-level objects. This practice ensures that there are no conflicts during the merge.
-
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
-
Adam equalizes the two repositories to reassign IDs honoring the different names given to the top-level objects. This practice ensures that there are no conflicts during the merge.
-
Adam copies the master repository out of the MUD directory and into a local directory, performs a two-way merge by using the Merge Repository Wizard, and then copies the master repository back into the master directory.
-
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. Helen 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's 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.
