Phase II - Branch, Fix, and Patch
In Phase II of the fictional company example, development continues on a new Phase II branch, while a Main branch tracks 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:
Set 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 Model 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's 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 can't 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. Adam knows that 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>
Adam doesn't 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 doesn't affect this logic, so the connection pool 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 Model 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 don't 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 cancels the update and exits 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 isn't recommended for production systems.
If you've privileges to log on to a production Oracle BI Server using the Model Administration Tool in online mode, you can use Copy As to copy it to your local drive.
Finish and Merge 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 doesn't 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.
