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 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; it will stay checked out. Then, he checks out the project that will contain the new measure, ProjQuote, from the main branch master repository (sales.rpd). He creates the new measure and corresponding presentation column, tests it locally, and publishes the changes back to the main branch.
Scott then reopens the checked-out Phase II repository from his local drive and continues development.
Meanwhile, Adam sends the new sales.rpd to the test environment, where the test team validates the fix.
Next, Adam prepares to send the fixed repository to Production. Rather than send the entire repository, however, he sends a patch of the change.
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 just before the new changes were merged in, so it 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 he 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.
Next, Adam opens the repository containing the update, sales.rpd. He selects File > Compare, and chooses the sales.006.rpd as the old version to compare. The Compare repositories dialog shows the differences between versions that will be included in the patch.
The image shows the Compare repositories dialog.
Next, 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:
More complex patches might also 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:
Unlike migrating an entire repository, there is no 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 will not affect this logic, so the connection pools will stay correct without an intervention.
Finally, 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. Note that 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.
Tip:
If you have privileges to log on to a production Oracle BI Server using the Administration Tool in online mode, you can use File > 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 now 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, the branch must be merged back into the main branch using MUD merge. Doing this merges the production patch with the newly developed content, so that can be moved to production later.
Now, 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.
