B MUD Case Study: Eden Corporation
This appendix contains the following topics:
About the Eden Corporation Fictional Case Study
Depicts a fictional corporation to describe Oracle Business Intelligence initiative examples.
Eden Corporation, a fictional company, recently purchased Oracle Business Intelligence. They have two divisions that are licensed and plan to use the product.
Because of this, the company has two separate initiatives:
-
Initiative S
The Sales Division wants to use Oracle Business Intelligence for the dashboard and analysis of revenue versus plan. They want to deploy an initial phase to production quickly to meet an immediate need. Then, they want to roll out more functionality in Phases II and III. Initiative S is large enough for two developers.
-
Initiative H
The Human Resources Division (HR) needs to create a dashboard and analysis of HR data. Initiative H is a smaller initiative with only one developer. They plan to deliver their application to production between Initiative S Phases II and III.
The Sales developers and the HR developers are not allowed to see each others' data or metadata. The metadata administrator is the only person who has security privileges for all the metadata.
As in all organizations, there is a steady stream of urgent requests and occasional bugs from production. The developers need to deliver fixes for these within days, even though the longer-term initiatives S and H are in development at the same time.
About the Technical Team Roles and Responsibilities
Eden Corporation has staffed the team as follows:
-
Adam Straight - MUD Administrator
-
Sally Andre - Developer for Sales Division, Revenue project
-
Scott Baker - Developer for Sales Division, Quota project
-
Helen Rowe - Developer for HR Division
About the Eden Corporation Development Phases
Eden Corporation plans to deploy RPDs to production based on the following timeline:
-
January - Sales Phase I (projects Revenue and Quota)
-
February - Sales Phase II (add project Target, extend projects Revenue and Quota)
-
March - HR (one project used)
-
April - Sales Phase III (extend all three projects)
About the Eden Corporation Topology
Eden Corporation plans to use the following systems for their multiuser development environment:
-
MUD Administrator - NT computer with a share
-
Sally Andre - NT computer for Administration Tool client, and Linux computer to run the Oracle Business Intelligence stack
-
Scott Baker - high-powered NT computer
-
Helen Rowe - either of the above
-
Test - Linux computer
-
Production - Clustered Linux computers
About the Repository Architecture
Because of Eden Corporation's business structure and initiatives, they need to have two independent semantic models in their repository: one for Sales and one for HR. Each of these models can have multiple projects.
Planning the Repository Structure
Eden Corporation knows that it is important to plan the structure of their repository file to support the multiuser development needs of their organization. They assigned owners to major objects, so the developers know who to go to when conflicts arise, and which objects they should not modify on their own.
Tip:
When hosting multiple independent semantic models, itemize the names of top-level objects to prevent duplicate names.
The tables show the high-level repository objects in main.rpd for both Initiative S and Initiative H, mapped to projects and owners. Adam is the overall owner of both Initiative S and Initiative H.
| Object Type | Object | Owner | ProjRevenue | ProjQuota | ProjTarget |
|---|---|---|---|---|---|
|
physical database |
Sample App Data |
Sally |
Yes |
Yes |
Yes |
|
business model |
Sales |
Sally |
n/a |
n/a |
n/a |
|
logical fact table 1 |
F10 Billed Rev |
Sally |
Yes |
Yes |
No |
|
logical fact table 2 |
F30 Facts Targets |
Scott |
No |
No |
Yes |
|
logical fact table 3 |
F50 Facts Quotas |
Scott |
No |
Yes |
No |
|
logical dimension |
(various) |
Sally |
Yes |
Yes |
Yes |
|
subject area (1) |
Sales Quota |
Scott |
No |
Yes |
No |
|
subject area (2) |
Sales Revenue |
Sally |
Yes |
No |
No |
|
subject area (3) |
Sales Target |
Scott |
No |
No |
Yes |
|
variable |
S_Last_Load |
Sally |
Yes |
Yes |
Yes |
|
initialization block |
S_Last_Load |
Sally |
Yes |
Yes |
Yes |
|
application role (1) |
Sales Management |
Sally |
Yes |
Yes |
Yes |
|
application role (2) |
Sales Rep |
Sally |
Yes |
Yes |
Yes |
| Object Type | Object | Owner | ProjHR |
|---|---|---|---|
|
physical database |
Human Resources Data |
Helen |
Yes |
|
business model |
HR |
Helen |
n/a |
|
logical fact table (1) |
Payroll Facts |
Helen |
Yes |
|
logical fact table (2) |
Medical Ins Facts |
Helen |
Yes |
|
logical dimension |
(various) |
Helen |
Yes |
|
subject area (1) |
HR Payroll |
Helen |
Yes |
|
subject area (2) |
HR Medical |
Helen |
Yes |
|
variable |
H_Last_Load |
Helen |
Yes |
|
initialization block |
H_Last_Load |
Helen |
Yes |
|
application role (1) |
HR Management |
Helen |
Yes |
|
application role (2) |
HR Rep |
Helen |
Yes |
Phase I - Initiating Multiuser Development (MUD)
In the first phase of the fictional company example, both Sally Andre and Scott Baker develop in parallel.
Sally creates the starter content that Adam Straight divides into projects. He creates the MUD directory so that Sally and Scott can check out and perform their development. After unit testing, they merge and publish their changes, and then Adam migrates the repository to the test environment. After a bug fix cycle, Adam promotes the repository to production.
The following sections describe Phase I development:
Starting Initiative S
In the fictional MUD project, Sally Andre starts off Initiative S from an empty RPD.
Because it is easier to divide the repository into MUD projects if you define some logical stars and subject areas first, she begins by developing the physical model needed for Phase I. She includes connection pool details for her own local test data sources.
Tip:
The physical model should include the physical tables, the best practice of aliasing all the physical tables to give them meaningful names, and joins.
The image shows the physical model for Initiative S.
Sally drags the Physical layer to the Business Model and Mapping layer to create some starter content. She removes unneeded tables, and ensures that the star joins are correct. She also ensures that all the physical tables that will be needed during development have mappings from the starter logical tables, so that they will be included in the projects when they are checked out. For Sally, these steps create two logical fact tables, F10 Revenue and F50 Quotas, that can act as the basis for the projects.
Sally also needs to have some subject areas to map to the projects in the business model. She could drag the entire business model, but a convenient way to accomplish this is to instead right-click the business model and select Create Subject Areas for Logical Stars and Snowflakes. This feature creates a subject area from each logical fact table.
Sally does not need to be concerned about the contents of the subject areas yet. All that matters is that each subject area maps to the logical fact table for the same project. However, she does name the subject areas based on the plan agreed to in the governance meeting: Sales Quota and Sales Revenue.
Sally now has enough content for the MUD administrator to create the first two projects based on the Revenue and Quota fact tables. To review, Sally has made sure that she meets the following criteria at a minimum:
- At least one logical fact table according to the governance plan, to anchor the projects. The columns of the logical fact tables need not be complete or even properly named, but they do need to be complete enough to map all the physical content.
- Enough logical dimensions so that the repository will pass the consistency check.
- Physical content that maps to one or more logical fact tables, so they will be included in projects.
- The subject areas needed according to the governance plan.
Setting Up MUD Projects
In the fictional company example, the MUD administrator for Eden Corporation, Adam Straight, now handles the next few steps to create the projects and get them ready for checkout.
Adam Straight creates the MUD directory,RPD_main, where the master RPD is stored. This master RPD contains the superset of content for the developers. The users check their projects out of the master, and merge their project back into the master when they want to share their changes. Sally copies her started RPD to the master folder so that Adam can create the first two projects, ProjRevenue and ProjQuota.
Adam opens the master RPD in the System Administrator's Guide for Oracle Business Intelligence Enterprise Edition and selects Projects. Then, in the Project Manager, he selects New Project. Adam names the project ProjRevenue and proceeds to pick the logical fact tables at the center of the project. The top object in the list expands to show the logical fact tables, but he has a choice of seeing them grouped by the Business Model to which they belong, or by Subject Area.
The image shows the different ways Adam can view the logical fact tables.
Adam decides to group facts by Business Model for convenience, although he could have used the Subject Area grouping to select the same fact table. He adds the fact table, plus the default application roles and subject areas specified for this project. Because there are no custom-defined application roles, users, variables, or initialization blocks yet, he cannot yet add them to the project. Adam repeats this process for ProjQuota, the second project.
Tip:
Some of the explicit objects are the same in both projects, because both projects share application roles. Similarly, many of the implicit project objects are shared, particularly dimension tables in both the logical and physical models. Projects are a convenience for creating small subsets that are easy to work with. Project are not for security. It is critical in your governance process that the owner of each top-level object is assigned and documented for the whole team, because this enables developers to avoid conflicts.
Adam included the logical fact table F10 Bill Rev in the project, even though it is owned by Sally Andre, not by Scott Baker, the owner of this project. He did this because Scott needs to create a measure that derives from measures in both fact tables, Sales percent of quota. Again, the point is to provide the user with the subset of content they need to implement their requirements, not just the objects they own.
Adam saves the master RPD to the shared drive, RPD_Main, as sales.rpd. It is now ready for users to check out projects and begin working in parallel.
First Developer Checks Out
An administrator configures their Administration Tool clients for the master repository, check out their projects, and begin working.
The developer, Sally starts by setting up her Administration Tool client to use the master repository. She selects Tools, select Options, and then selects the Multiuser tab. She sets up the pointer to the master repository directory in the Multiuser tab. She also enters her full name, used in logs and locks. She checks out her project and begins work.
In the Master Repository directory, two new files have been created the sales.000 and sales.mhl files. The image shows the new files.
The sales.000 file is an automatic backup created for sales.rpd file that was created when Sally checked out the repository. The backup file is used if a roll back is needed resulting from a problem. The sales.mhl file tracks her checkout status and parameters, including project, computer, and user.
Three files have been created in Sally's local repository directory:
-
The originalProjRevenue.rpd file is the project subset repository at the time of checkout. The originalProjRevenue.rpd used later as the original in the three-way merge process, and also when Sally discards her changes.
-
The ProjRevenue.rpd file contains only the self-consistent subset project, ProjRevenue. The ProjRevenue.rpd file that is open for editing.
-
The ProjRevenue.rpd.Log file is the log file for the editing session in the Administration Tool. You can view ProjRevenue.rpd.Log files contents in the Administration Tool using File, select Multiuser , and then select History.
The image shows the three files in the local repository directory.
Sally begins to work on the model for her application in offline mode. She does not need to change her connection pool settings because she used her own test data source connection pool details when she created the starter content.
Sally starts by opening her fact table and deleting the unused keys based on the modeling best practice. Then, she adds SUM aggregation rules to three measures, Discnt_Value, Revenue, and Units. She also changes the name of Discnt_Value to Discount Amount, Units to Units Sold, and Revenue to Sales Revenue.
Sally also needs to add a new column to the D10 Product table, an upper-case version of the Prod_Dsc column called PRODUCT DESCRIPTION. The column uses the following expression: Upper("Sales"."D10 Product (Dynamic Table)"."Prod_Dsc"). Sally adds dimension hierarchies, creates a variable called Constant One, and initializes it to the value 1. She uses the variable to create a new measure, Constant One. Finally, she saves her work.
Sally starts her sandbox Oracle Business Intelligence stack so that she can add application roles, and then test her repository using Answers. She follows these steps to start her components in the right order and to configure her system environment:
-
Start the database containing the RCU schema, using its standard controls. This database is the local sandbox developer database.
-
Start the sandbox Oracle WebLogic Server Administration Server. For example, on Windows, from Start, select Programs, select Oracle WebLogic. In Oracle WebLogic, select User Projects, select bifoundation_domain, and then select Start Admin Server for WebLogic Server Domain and enter the user and password created during installation when prompted.
Note:
If you used an Enterprise or Software-Only install type, you must also start the Oracle WebLogic Server Managed Server using the Oracle WebLogic Server Administration Console. Typically, you use the Simple install type when installing development sandboxes.
-
Log in to the local sandbox Fusion Middleware Control and upload the repository file, making sure to enter the correct repository password. You upload the local subset repository, in Sally's case, the MUD checked-out repository, ProjRevenue.rpd, not the master repository.
-
Also in Fusion Middleware Control, turn off Oracle BI Server caching, so that interpreting the query log is simpler.
-
Still in Fusion Middleware Control, start the system components from the Business Intelligence Overview page.
See the System Administrator's Guide for Oracle Business Intelligence Enterprise Edition provides more information about steps 2 - 5.
Because Sally's Oracle BI Server is on a Linux system, she must set up ODBC connectivity on her Windows computer so that her Administration Tool client can access the Oracle BI Server there.
Sally manually adds an Oracle BI Server ODBC DSN pointing to the Oracle BI Server on the Linux computer. See “Integrating Other Clients with Oracle Business Intelligence” in Integrator's Guide for Oracle Business Intelligence Enterprise Edition for information about how to create an ODBC DSN for the Oracle BI Server.
Sally is using the Oracle WebLogic Server embedded policy store and needs to add two application roles, Sales Management and Sales Rep. To add the roles, she opens a Web browser on her Windows computer and logs in to Fusion Middleware Control, pointing to her Oracle Business Intelligence stack on Linux. She uses Fusion Middleware Control to create the new roles, maps it to the appropriate users, groups, or other roles, and grants the appropriate permissions to the role.
Tip:
See Creating Application Roles in Security Guide for Oracle Business Intelligence Enterprise Edition .
Sally needs to add the new application roles to her repository, and then use them for object permissions and data access filters. Sally uses the following steps:
- Sally opens the Administration Tool and selects File > Open > Online. She picks the local Windows ODBC DSN that connects to her local Oracle Business Intelligence stack, enters her repository password, and also enters the default user name and password for administering her stack that she created upon install.
- Next, Sally selects Manage, and then selects Identity to open the Identity Manager. She clicks BI Repository in the navigation tree and then clicks the Application Roles tab. She sees the five default application roles, as well as the new ones she just created.
- Sally double-clicks the Sales Rep application role, and then clicks Permissions. On the Data Filters tab, she adds a data filter with an expression that only allows users who belong to this role to see sales that they themselves have made. On the Object Permissions tab, she sets Read, Read/Write, or No Access permissions that allow Sales Rep users to see revenue, but not quota or cost information. On the Query Limits tab, she keeps the defaults for Max Rows and Max Time, and does not set any time restrictions. She clicks OK to return to the Identity Manager.
- Next, Sally double-clicks the Sales Management application role and sets up Data Filters, Object Permissions, and Query Limits appropriate for this role, based on the decisions of the governance committee.
- Finally, Sally exits the Identity Manager.
- Sally commits the changes she made in online mode by using the Check In Changes menu option. This action propagates the online mode changes to her local subset, ProjRevenue.rpd, but does not commit them to the master MUD repository. Sally publishes her changes to the master repository in a later step.
For the new variable and application roles to be in Sally's project the next time she checks it out, she must add them to the project before she checks in her changes. To do this, she performs the same steps that Adam did when he created the projects: She selects Manage, and then selects Projects. Sally selects her project, selects the new objects, and clicks Add.
Second Developer Checks Out
In the fictional company example, Sally Andre is working on the ProjRevenue project and Scott Baker is getting started on ProjQuota.
Scott sets up his Administration Tool options for MUD, checks out his project, and starts working.
Scott prefers to work in online mode. Doing this tightens the development/unit test loop, because he is modifying the repository while it is running in the Oracle BI Server. Every time he clicks Check In Changes in the Administration Tool, his changes are applied to the running server. He can then immediately move to Oracle BI Answers and test the changes there. When he adds, deletes, renames, or reorganizes Presentation layer objects, he must reload metadata in the Answers criteria tab to refresh the tree visible there.
Scott starts his local Oracle Business Intelligence stack, and uploads his checked-out subset repository. He restarts the Oracle BI Server, opens the Administration Tool, and opens his repository in online mode.
Scott must change the connection pool settings to point to his local test database, because the master repository contains Sally's settings. In the merge process, these connection pool changes are overridden by the connection pools already in the master repository. The next time Scott checks out, he needs to apply his local test connection pool changes again.
Tip:
Use the Oracle BI Server XML API to automate connection pool changes required during migrations to production and other environments. See “Moving from Test to Production Environments” in XML Schema Reference for Oracle Business Intelligence Enterprise Edition.
Scott's next task is to clean up his logical fact table by removing keys. He also gives a measure a SUM aggregation rule and a business-friendly name, Quota Amount.
Scott does not change anything in the F10 logical table because it is owned by Sally. After she merges and publishes her changes to the master RPD, he does the same. Scott checks out again, picking up Sally’s changes.
Scott adds a new measure called Sales percent of quota to the F50 table. The measure derives from both fact tables with the following expression:
"Sales"."F10 Billed Rev."."Revenue" / "Sales"."F50 Facts Quotas"."Quota Amount"
Even if Sally changes the name of Revenue in her project, the merge identifies it as the same object and uses the new name in Scott's expression. The merge logic can identify the name change because the upgrade ID of the object is the same as the original.
Scott forgets what he learned in the Governance Committee meeting, that all the dimensions are owned by Sally. He has a requirement for an all-capitals version of the D10 Product.Prod_Dsc column called PRODUCT DESCRIPTION. He creates a column identical to the one Sally created. This mistake will be detected and resolved through the merge process during the publishing step in a few moments.
Scott does not need to upload his repository and restart his system because he is working in online mode. Instead, he unit tests his work immediately after committing his changes using Check In Changes. Meanwhile, Sally has finished testing her changes.
First Developer Publishes Changes to the Master MUD Repository
Sally has finished creating and unit testing her first batch of changes, so she saves her work and prepares to merge it into the master repository.
She chooses File , selects Multiuser , and then select Publish to Network. If she forgot to add any new objects to a project, a detailed warning is displayed so that she can add the objects to her project and try the merge again. Otherwise, the objects are not extracted the next time she checks out the project.
Next, the Administration Tool locks the master repository so that Sally can merge her changes without any chance of corruption from other users' merges.
Tip:
For logging purposes, it is a best practice to use the comment field to provide a description of the changes you are publishing. Publishing frequently, or performing a subset refresh, also makes it easier to keep track of changes, and easier to audit the history later. A best practice in Administration Tool modeling is to work incrementally to simplify testing and reduce the complexity of each task.
Sally's changes cause no conflicts, so they do not appear in the Define Merge Strategy step that is displayed next. However, aliases for presentation objects are a special case where you can choose to keep either the modified (your local version) or current (the master), or merge the two. The aliases were automatically created when Sally changed the column names, so that reports written to the old names would not break when she put the new names into production. Because Eden Corporation has no reports yet, Sally keeps the aliases empty by selecting Current. She does this for "Sales Revenue," "Units Sold," and "Discount Amount."
Note:
Sometimes, there can be a series of aliases if names change more than once. Because there might be a set of reports using the older names, you can select Merge Choices in the Define Merge Strategy screen to keep any aliases already in Current as well as the new ones in Modified.
When the merge step is complete, the master sales.rpd is overwritten with the changes from Sally. A merge log is also stored.
Second Developer Publishes Changes to the Master MUD Repository
In the fictional company example, Scott has completed his development work for this phase, he selects Refresh Subset to perform a subset refresh to merge his changes with the latest version of the master repository.
The Define Merge Strategy screen asks whether to keep the alias created on the presentation column Quota Amount. Like Sally, Scott chooses to keep the current repository value, which does not use the alias.
After the subset refresh, Scott unit tests again briefly. Upon inspection, he also notices his mistake of creating the same PRODUCT DESCRIPTION column that Sally did. Because Scott's column was created separately, its internal upgrade ID is different than the one in Sally's. Therefore, even though the name is the same, the merge logic knows it is a different column, and renames it rather than overwriting it by appending #1 (PRODUCT DESCRIPTION#1).
Scott deletes the extra column, connects his logic to Sally's PRODUCT DESCRIPTION column, tests again briefly, and publishes his changes to the network master repository.
If Scott had deleted or modified a different user's object, the error might have been more difficult to resolve. It might have required re-creating and equalizing the object, or rolling back to a backup version of the repository and re-creating his own changes.
MUD Administrator Test Migration Activities
To prepare the repository for the test environment, the MUD administrator, Adam Straight, must now perform several tasks directly on the master repository.
The MUD administrator, Adam, opens the sales.rpd repository in offline mode. As soon as he does this, other users are locked out, and get Windows permissions errors if they try to check out projects. If Adam needs to open and close the file several times, he needs to remove the RPD from the shared directory while modifying it so that other users cannot check out repository objects between his changes.
Adam changes the connection pool settings to match the test environment. When Administration Tool users check out projects, connection pool parameters are not included in the checkout. The master repository in the MUD directory contains the test connection pools, but each individual developer might need different settings for connecting to their own test databases. At merge and publish, the connection pools in the master repository are not overwritten by developer changes, so that they can continue to point at the shared test databases.
Adam must ensure that the new application roles are migrated to the test system. Because there are only two application roles, he decides to reenter them in Fusion Middleware Control on the test system. Adam also provisions some test users or groups to the new application roles so the security filters, permissions, and query limits can be tested.
Adam uploads the repository to the test system and restarts the Oracle BI Server. Using his local Administration Tool, he connects to the test Oracle BI Server in online mode and runs the consistency checker. If any application roles referenced by this repository are missing or incorrect, the consistency checker lists the errors.
Phase I Testing
Learn about testing in a multiuser development environment by reviewing fictional company example.
The test team can now test the repository. During testing, the test team discovers a bug: "Sales"."F50 Facts Quotas"."Sales percent of quota" was erroneously created with the expression quota/sales instead of sales/quota. The test team writes a bug report, and Scott Baker is assigned to fix the bug.
Scott opens the Administration Tool, checks out ProjQuota, makes the change, changes the connection pool to point to his local test database, and tests on his own sandbox. Then he publishes the changes to the shared MUD directory. He informs Adam that the bug is fixed and that the repository is ready for him to send to test again.
Adam notes that the connection pools are still pointed at the correct test system, because the MUD feature isolates the master repository from connection pool changes in checked out projects. Adam uploads the repository, and restarts the Oracle BI Server.
The test team tests to completion, and the repository is cleared for production.
Phase I Migration to Production
After the repository has passed the testing phase, you must update the repository’s database connection parameters before uploading the repository to production.
You must also migrate and provision the application roles.
Based on the plan provided by the governance team, the production operations team knows the new application roles needed. They create them as Adam did for the test environment. They also provision users or groups to those application roles, based on the security specification from the governance team.
Before migrating to production, Adam has to change the connection pool parameters to the values needed for the production database. In Eden Corporation, Adam has the privilege to see the production connection pools, but the repository developers do not. Therefore, Adam cannot change from the test to production connection pools and leave the repository in the master directory, because the developers have Windows permissions to read and write to it. Instead, he creates an XML patch of the connection pools needed for Production. Then, he copies sales.rpd to a secure directory and applies the patch, and then tests to be sure it really does connect to the production data sources. He then uploads the repository to the production system, and starts the production cluster of servers.
Tip:
Use the Oracle BI Server XML API to automate connection pool changes required during migrations to production and other environments. See “Moving from Test to Production Environment” in XML Schema Reference for Oracle Business Intelligence Enterprise Edition .
Because the master repository still points to the test databases, the Administration Tool users can still be allowed to see it. Meanwhile, new versions of the production repository can be built at any time by applying the connection pool changes in the XML patch file.
Production validations are now performed. Similar to the migration to the test system, an important validation is to run the consistency checker in online mode to ensure that the application roles are all correct. When this validation is complete, Phase I is in production.
Phase II - Branching, Fixing, and Patching
In Phase II of the fictional company example, development continues on a new Phase II branch, while a Main branch will track the production application.
To manage this work, Adam adds a branch project, and set up a second master repository shared directly, one for Main, and one for the new Phase II branch.
Sally adds more content to ProjRevenue. While she works on that, Scott adds brand new content. After Scott merges and publishes, Adam creates the new project, ProjTarget, and move Scott's new content into it. Meanwhile, they must handle any bugs that occur in production, which is still on the main sales.rpd branch.
The following sections describe Phase II development:
Setting Up the Second Branch
In the fictional company case study, Adam begins by creating another MUD directory to hold the master for the new branch. He sets the Windows share security so that Sally and Scott can read or write to it.
Next, Adam places the main repository into the main MUD directory. He adds a new project for the branch, which encompasses all the existing functionality. Then, he closes the repository, and checks out the branch project in his local Administration Tool repository folder. He copies it to the branch MUD directory, where it now serves as the master for the branch.
Developers Check Out Projects
Sally and Scott check out their projects again, and begin developing Sales Initiative Phase II in parallel with each other, and in parallel with Phase I being in production.
Because Scott is adding new content for a new project, he needs to check out one or more other projects to provide the shared objects that he needs to map or join in the new content. He chooses to check out ProjQuota.
Patch Fix for the Main Branch
A fictional company, Eden, is used to show how to create a new measure.
While Sally and Scott are developing Phase II, an urgent CEO request is escalated to them. The CEO wants the key sales managers to see a new measure called Sales Quota Variance on their dashboards within two days.
Scott closes his work on the new project on the Phase II branch. The new project remains checked out. He checks out the project to contain the new measure, ProjQuote, from the main branch master repository, sales.rpd. Scott creates the new measure and corresponding presentation column, tests the measure locally, and publishes the changes back to the main branch.
Scott reopens the checked-out Phase II repository from his local drive and continues development.
Adam sends the updated sales.rpd to the test environment, where the test team validates the fix.
Adam prepares to send the fixed repository to Production. He sends a patch of the repository change to the testers.
To create the patch, Adam compares the modified repository to the one that is currently running in production. The repository running in production is the same as the main repository before the new changes were merged in and is one of the backup repositories in the MUD directory. The current repository running in production is the backup called sales.006, the same one Adam identified as the original for the upcoming branch merge. He copies this to sales.006.rpd so the Administration Tool can see and open the file. He cannot simply rename it, because it may be needed for another merge later.
The image shows the files in the MUD directory, including sales.rpd and sales.006.
Adam opens the repository containing the update, sales.rpd. He selects Compare, and chooses the sales.006.rpd as the old version to compare. Compare repositories shows the differences between versions that Adam can include in the patch.
The image shows the Compare repositories dialog.
Adam clicks Create Patch and saves the result as Patch_variance.xml. The patch contains just the objects needed to apply the two new columns, and their associated interconnections.
Tip:
Complex patches might delete objects or overwrite objects to merge in new property values.
Adam's patch appears as follows:
<?xml version="1.0" encoding="ISO-8859-1"?>
<Repository xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<DECLARE>
<LogicalTable name="F50 Facts Quotas" parentName=""Sales""
parentId="2000:68667" parentUid="2160843965" id="2035:69454" uid="2160843966"
x="718" y="288">
<Description/>
<Columns>
<RefLogicalColumn id="2006:69460" uid="2160844041"
qualifiedName=""Sales"."F50 Facts Quotas"."Quota
Amount""/>
<RefLogicalColumn id="2006:69786" uid="2160845070" qualifiedName=
""Sales"."F50 Facts Quotas"."
Sales percent of quota""/>
<RefLogicalColumn id="2006:70033" uid="2160845342" qualifiedName=
""Sales"."F50 Facts Quotas"."
Sales Quota Variance""/>
</Columns>
<TableSources>
<RefLogicalTableSource id="2037:69456" uid="2160844747"
qualifiedName=""Sales"."F50 Facts Quotas"."
F50 Facts Quotas""/>
</TableSources>
</LogicalTable>
<LogicalColumn name="Sales Quota Variance" parentName=
""Sales"."F50 Facts Quotas"" parentId="2035:69454"
parentUid="2160843966" id="2006:70033" uid="2160845342" isDerived="true"
isWriteable="false">
<Description><![CDATA[quota - sales]]></Description>
<Expr><![CDATA["Sales"."F50 Facts Quotas"."Quota Amount" - "Sales".
"F10 Billed Rev."."Sales Revenue" ]]></Expr>
</LogicalColumn>
<PresentationTable name="F50 Facts Quotas" parentName=
""Sales Quota"."""
parentId="4004:69706" parentUid="2160844968" id="4008:69707"
uid="2160844969" hasDispName="false" hasDispDescription="false">
<Description/>
<Columns>
<RefPresentationColumn id="4010:69711" uid="2160844973" qualifiedName=
""Sales Quota".."F50 Facts Quotas"."
Quota Amount""/>
<RefPresentationColumn id="4010:70032" uid="2160845338" qualifiedName=
""Sales Quota".."F50 Facts Quotas"."
Sales percent of quota""/>
<RefPresentationColumn id="4010:70036" uid="2160845345" qualifiedName=
""Sales Quota".."F50 Facts Quotas"."
Sales Quota Variance""/>
</Columns>
</PresentationTable>
<PresentationColumn name="Sales Quota Variance" parentName="
"Sales Quota".."F50 Facts Quotas"" parentId=
"4008:69707" parentUid="2160844969" id="4010:70036" uid="2160845345"
hasDispName="false" hasDispDescription="false" overrideLogicalName="false">
<Description><![CDATA[quota - sales]]></Description>
<RefLogicalColumn id="2006:70033" uid="2160845342" qualifiedName=
""Sales"."F50 Facts Quotas".
"Sales Quota Variance""/>
</PresentationColumn>
</DECLARE>
</Repository>
Tip:
You do not need to make any connection pool changes before applying this patch. The correct connection pool settings are already in the repository running in production. The patch does not affect this logic, so the connection pools remains correct without an intervention.
Adam must have this patch migrated and applied to the production system. There are several ways to accomplish this:
-
Patch main repository offline and upload
Adam can apply the patch to a copy of the production repository locally on his Windows computer by using the Administration Tool to perform a patch merge. Then, he can upload the repository to the production system, like Sally did earlier in her sandbox. Because the production system is clustered, he must restart all the Oracle BI Servers after uploading the repository. Adam can restart manually through Fusion Middleware Control, one server at a time. If he performs a rolling restart in this way, end users do not see any unavailability. Alternatively, Adam or one of the operations staff can write a script using the BI Systems Management API to automate a rolling restart.
-
Patch production repository in place using patchrpd utility
The operations staff can log onto a production system directly, and apply the XML patch using the
patchrpdutility. If any conflict occurs, the utility will cancel the update and exit without making changes. If the update is successful, the operations staff can then perform a rolling restart, as described in the previous paragraph. -
Patch running system using biserverxmlcli utility
This method is not recommended for production systems.
If you have privileges to log on to a production Oracle BI Server using the Administration Tool in online mode, you can use Copy As to copy it to your local drive.
Finishing and Merging Phase II Branch
Sally and Scott complete their changes in the new branch and publish them.
Adam adds Scott's new content to a new project, projTarget. He performs the same steps as before to send the branch repository to the testing team.
When testing is complete, merge the branch back into the main branch using MUD merge. The result is a merge of the production patch with the newly developed content to place into production later.
The sales.rpd contains all the changes, and the branch is no longer needed. Sales.rpd is sent to integrated test, to ensure the merged content does not cause any bugs in the existing content. When integrated testing is complete, Adam creates another patch containing the changes, and has the operations staff apply it to the running production system. Sales Initiative Phase II is now in production.
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 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 repository for Sales, and the other for HR. This approach requires the two teams to ensure that there are not 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 do not conflict. You must also use different variables and application roles.
Tip:
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. 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 Administration Tool.
HR Semantic Model Developer Builds Content
Because Helen is working alone on her secure, independent semantic model, she does not 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 will be 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 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.
