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 Model 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's running in the Oracle BI Server. Every time he clicks Check In Changes in the Model Administration Tool, his changes are applied to the running server. He can then immediately move to 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 stack, and uploads his checked-out subset repository. He restarts the Oracle BI Server, opens the Model 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.

Scott can also 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 doesn't change anything in the F10 logical table because it's owned by Sally. After she merges and publishes her changes to the master Oracle BI repository, 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 is detected and resolved through the merge process during the publishing step in a few moments.

Scott doesn't 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.