OBIEE 11G Parent-Child Hierarchies

OBIEE 11G Parent-Child Hierarchies – Differing Aggregations


Mark has already explained the new Parent-Child hierarchy new feature in 11g here.Parent Child hierarchies
are different from normal level based hierarchies not only in the nature of their structure but also in the way aggregations are done. For example, in a level based hierarchy, the most common type of aggregation that is done involves rolling up the numbers from the lower most level. But in the case of parent-child hierarchy,

an aggregation by default enforces the roll-up across all descendant members. To understand this lets try to take this through an example.

Lets consider a sales department with the employee hierarchy shown below






Its a simple parent child employee hierarchy found in the oracle HR schema. Now the

requirement for us is to model the Salary attribute of an employee in 3 ways

1. As an attribute – Show the salary of each employee as an attribute in the parent child hierarchy.

2. As a measure (All intermediary Roll-ups) – Roll-up the salary figures of all the employees \who roll into the employee. For example, Scott King will have a Salary equal to sum of salaries of all the employees who report to him, including the ones who are his direct & in-direct reporting employees.

3. As a measure (Level-0 Roll-up) – Roll-up the salary figures from the lower most level till the top node For example, in the above figure, Scott King will have a Salary Roll-up figure of all the employees who are the lowermost level (not including the intermediary nodes – very similar to normal level based hierarchy roll-ups)

The above requirement is quite straightforward, but to achieve similar such aggregations in a normal level-based hierarchy, we will have introduce fragmentation & other techniques.But with parent-child hierarchy modeling now available in BI EE, all the above 3 requirements can quite easily be achieved.Following is the employees parent child table that stores all the attributes of an employee

We start off with modeling this as a normal dimension table. As shown in Mark’s blog entry,

we then create the Parent-Child table that stores all the relationships within the employee hierarchy (if you look at the script used in creating this, it will be containing a Connect By statement that will connect a root hierarchical node to every member that is part of its hierarchy).

Once this is created, we start with including the Salary as an attribute within the Employee dimension itself

This will serve our first requirement i.e show salary as an attribute of every employee.

Now, to model the 2nd requirement i.e. to model salary as a measure and then make it to rollup from all the intermediary hierarchical members, we start with defining an alias on the main Employee table. Then join this table to the custom parent child employee table. The join structure of all the 3 tables is given below

We would then be using the salary column from the new employee alias table in our logical fact table as shown below

Lets now look at the report now and see what BI EE generates.

As you see, BI EE has generated the correct results with the roll-up of intermediary members aswell. This is something that is quite difficult to model in BI EE 10g. If we look at the query generated(just the key one that generates the measure as BI EE now generates lots of intermediary sub-queries to support contextual drilling) you would notice that the default Parent-Child behavior is to achieve a roll-up across a hierarchy

To achieve the 3rd requirement i.e. to model a level based hierarchy kind of rollups from level-0,

we create another alias in the physical layer and then model it the same way as the 2nd requirement. In the fact logical table, we then create a new measure that will map to the new physical alias as shown below

To ensure that we roll-up only from level-0 members, we then apply a filter in the fact logical table source as shown below

Lets now take a look at what BI EE generates

As you see, BI EE now generates the roll-ups only from level-0 members as against every

descendant.We can have even more granular roll-ups based on custom defined attributes.

Repositories and Migration from Development to Production

OBIEE 11G Patching Repositories and Migration from Development to Production


ne of the biggest problems that we have had with BI EE 10g was there was no automated way of making repository deployments in Linux environments. Some of us internally in Rittman Mead have adopted UDML to script the migration from development to production. But the problem with UDML is that it cannot not generate the encrypted passwords (primarily for connection pools) automatically. So, the encrypted passwords for production environment had to be stored externally, and every-time there was a need to do a repository migration, these encrypted passwords had to be retrofitted back to the development repository UDML. In some cases, UDML cannot be used, as the development and production repositories might be completely different in terms of security etc. In such cases, the recommended way of merging changes in 10g was to use the repository merge. But again to do a merge, one had to have an external windows machine and then do the merging which was a major issue in many automated environments.


In 11g, BI EE supports a concept called as repository patching. Mark has covered this already here. What this allows us is to do apply incremental changes to the repository in development directly to production through an automated process. This is based on the concept of Merge that was there in 10g. 11g basically extends this concept. This blog entry basically expands on what Mark has already explained before. There are 2 parts to patching. They are


1. Creating the Patch – This is done by creating an incremental XML patch file that will contain just the changes done in development. The incremental XML patch file is created using the Compare option.

2. Applying the Patch – This is done by applying the incremental XML file on the production repository.


Initially after any new BI EE install, the repository that is created in development will be tested and then will be moved over to production with changes to the connection pool settings (primarily passwords) done through BI EE Administrator. Unfortunately, this step mandates the use of a Windows machine for Linux deployments. This is still the same in 11g as well. This is highlighted in the sample flow diagram given below

Once a production RPD is deployed for the first time, end users might want more changes to be done in the repository. For example, some of the common changes that might be needed are


1. Renaming of columns

2. Adding new columns

3. Adding new subject areas

4. Changing Security

5. Bug Fixes


These changes will typically be done on the development RPD. The concept of patching basically extracts the incremental changes that were done to the development RPD and then apply them to the production RPD. This is depicted as shown below


Generating Patch File:

Applying Patch:

Lets try to understand this through an example. Given below is a screenshot of a sample repository that will be moved to production.

Lets name the above repository as DevRPD. Now during the first time migration to production lets assume the following changes are made.

1. All connection pool user names changed to point to the Prod database usernames

2. All connection pool passwords changed to point to the Prod database passwords

Lets name this repository as ProdRPD. After this repository has been migrated to production, let’s assume that we are getting more enhancement requests. Following are the changes requested

1. A new subject area called SH – Aggregate.

2. Rename some columns. For example, rename CHANNEL_CLASS column to something more user friendly like “Channel Class” in the SH subject area.


After the above changes have been done using the DevRPD, this new repository will be saved as DevRPDv2. Lets assume that the developer while making the changes inadvertently deleted the column AMOUNT_SOLD. The admin notices this and he recreates the column AMOUNT_SOLD in the repository. A screenshot of the DevRPDv2 is given below.

Now, we basically have 3 repositories. DevRPD – The development baseline repository for the first release. ProdRPD – The baseline repository that is in production. DevRPDv2 – The repository containing all the changes requested by end users.


To migrate the changes done in DevRPDv2 repository, we first start with opening up the DevRPDv2 using the Admin Tool. Then we click on File->Compare option and then choose the Dev Baseline Repository as shown below

As you see we now have the changes done to the baseline repository (within the DevRPDv2) listed. If you notice carefully, we will have the AMOUNT_SOLD column listed twice as Deleted & Created.

This happens because when we delete an object, the upgrade id associated with the object is lost. The entire process of merge happens through the upgrade ids and not the names. Now you can imagine what will happen when we try to merge a lot of changes. We cannot have control on what developers do and hence we might see even more of these in the actual scenario. To reduce this and to treat the columns with matching names as the same, we have to equalize the repositories. So before every merge, it is always recommended to do an equalization that will ensure that the matching names have the same ids.

We can equalize non-matching objects (different names) as well one by one. In this case, I will use the automatic equalization that will apply the matching name-matching id principle. This would show all the objects that have been equalized as shown below, in our case just the AMOUNT_SOLD

If you now look at the compare screen, you will notice that the AMOUNT_SOLD column will no more be there

So lets create a patch now without making any more changes by clicking on “Create Patch”.


This will create an XML file containing all the changes.

Now, to apply patch there are 2 ways. One is through the Admin tool Merge process and the other is by using a command line utility called patchrpd. Lets go through the process of patching the repository through the Admin tool.


To do this we start with opening up the ProdRPD in offline mode. Then click on Merge & choose the Patch Merging option. Choose the DevRPD as the Original Repository and the XML file generated above as the patch file. Enter the appropriate usernames and passwords.

By clicking next, we trigger the patching process. The patching process basically recreates the intermediary DevRPDv2 internally and then performs a 3-way merge. If we look at the repository now, you should see all the changes in the target repository ProdRPD – Patched.

The same patching can be done through command line utility patchrpd. To do the same process that we did through the Admin tool above, the command would be/u01/app/Middleware/Oracle_BI1/bifoundation/server/bin/patchrpd -P Administrator -C /home/oracle/ProdRPD.rpd -W Administrator -G /home/oracle/DevRPD.rpd -I /home/oracle/DevtoProdPatch1.xml -O ProdNew.rpd -S /u01/app/Middleware/Oracle_BI1/bifoundation/server/bin/xudml1.xsd



One main difference between the command line utility and the Admin tool based patching is, if there is any conflict resolution, the patch utility will just display some warnings and come out without creating the RPD. But in the admin tool we have the opportunity to resolve the conflicts and then proceed with the patching.


Next up is a methodology to do Web Catalog Patching. BI EE 11g offers similar patching capability for applying incremental changes to web catalogs.










OBIEE 11G Incremental Web Catalog Migration – Patching Web Catalogs


esterday, we saw how to go about patching repositories so that the entire process of migration from development to production can be automated. That patching process was basically an extension of the 3 way merge process. In 10g, 3 way merging was supported in Web Catalogs as well.  But the biggest downside was, it had to be done very carefully as there were chances of losing a lot of objects. In 11g, web catalog incremental migration is supported with more granular control on how the 3 way merge happens.


The high level architecture of the patching process for web catalogs is given below


Creating the Patch:

Applying the Patch:

So the process more or less is the same as the Repository Patching process. To start with lets assume we have a webcatalog called SampleAppBaseline which will be our baseline web catalog that is already in production (SampleAppProd). Due to a change request, lets assume following are the changes that were made to the SampleAppBaseline webcatalog.


1. One report was deleted – A report called ChartZoom has been deleted

2. One report was modified – A report called Filters has been modified

3. One new report was created – A report called SampleSales has been created


The name of this new web catalog is SampleAppChanged. Web Catalog patching is done through the Catalog Manager command line options. In 11g, we have much more comprehensive set of options that makes scripting catalog manager related tasks a lot easier. So we start with first creating the diff file using the following command./runcat.sh -cmd diff -baseline /home/oracle/SampleAppBaseline -latest /home/oracle/SampleAppChanged -outputFile /home/oracle/SampleAppDiff.txt -folder /shared -verbosity detail





Lets look at the diff file to see what the contents are.

As you see all the changes that were made to the web catalog have now come into this diff file. Remember we can now control whether we want to migrate the permissions as well from one web catalog to the other. Now the next step is to create a patch file out of this diff file by comparing the changes in the diff file with the production web catalog../runcat.sh -cmd createPatch -inputFile /home/oracle/SampleAppDiff.txt -outputFile /home/oracle/SampleAppPatch.txt -production /home/oracle/SampleAppProd



If we look at the patch file, it will look similar to the diff file. Basically this provides us with an opportunity to pick & choose the changes that we want to apply in to the production web catalog (through command line options)

By modifying the PRODUCTION webcatalog name in the patch file we can apply multiple patches simultaneously to different web catalogs (like UAT, PROD etc). To apply the patch we just need to fire the following command./runcat.sh -cmd applyPatch -inputFile /home/oracle/SampleAppPatch.txt -outputFile /home/oracle/SampleAppPatched.txt





If we now open the production web catalog we should now be seeing all the changes applied automatically. Remember to test this out completely in development before finalizing the scripts in production. I have seen instances(on my test sand box) where the patch files seem to somehow not pick up the changes automatically (had to enforce it through timestamp differences).

OBIEE 11G Action Framework – Integration with External Applications


Action Framework in BI EE 11g opens up BI EE to external applications for extensive integration. Mark has covered this as part of his posting here. BI EE, even in 10g had a lot of integration options. But one biggest drawback had always been the lack of an ability to call external applications/scripts/processes right within the BI EE dashboard. Only way in 10g was to either make the call through a URL (like action links to Ebusiness Suite & Siebel) and browser based Java Scripts. In 11g, we now have a lot more options. There are basically 2 kinds of Actions. The first one is the Navigate action which basically enables the drill from BI EE to external applications like EPM, Ebusiness Suite, another report/dashboard in BI EE etc. The parameters can be passed from one application to the other easily.

The second one is the Invoke action that provides an ability to call external Java processes, Browser scripts, web services etc. The invoke action does not provide external navigation. They are primarily used for triggering processes that happen outside of BI EE like calling ETL processes, java processes etc

Both the Navigate and Invoke actions are part of the Action Framework. Listed below are some of the new features in Action Framework that enable integration with external applications.


1. Integration to external Applications through a URL – This feature existed even in 10g and was one of the most commonly used ways of integrating other applications with BI EE. The biggest problem with this in 10g was, we manually had to hand craft the URLs and the parameters. In 11g, this integration has been enhanced to alleviate 2 important issues that we have had with 10g


a. We can specify location aliases instead of hardcoded ip addresses (or hostnames). For example, if you are using Go URL to call another BI EE report, then we will have to enter the full URL including the hostname. When we migrate from environments (say dev to prod), then we will have to manually change the hostnames in every report that use Go URL. This is not needed anymore.


b. Its now much easier to specify the url parameters through the UI. We can pass parameters which can be either made visible or hidden. For example, if you want to pass username and passwords to the url but you would like them to be invisible for the person invoking it, then that is possible now.

2. Integration with Web Services – This is a complete new feature of BI EE 11g. In 10g, web services can be called only using Java Scripts or by calling an external JSP page. In 11g, we have this feature natively. So, effectively if you have say ODI ETL Web Services and you would like to kick start an ETL process from BI EE, it is easily possible now. In addition to making calls to external web services, BI EE also has a new type of Web Service called BI EE Web Services for SOA. This new web service basically is for integration with Oracle FMW products like BPEL etc. One of the big drawbacks in BI EE 10g web services was, every-time we had to call a report or an iBot, we had to establish a session with BI Server and then pass the session id to the individual web service methods. But in the BI EE Web Services for SOA, there is no need to establish a session to get access to the individual methods. I will cover this in detail in another blog post.

3. Integration using Java Methods – Another interesting integration that is part of 11g is the ability to call Java methods natively. In 10g, the only way to call java methods directly was to use delivers and then call the java methods through the Java Host. In 11g, this method of calling java methods (through Javahost) is not recommended. Instead the java classes will have be wrapped inside a EJB and then this EJB can be called from BI EE. This opens up a lot of integration opportunities like writeback to Essbase etc. I will cover this in a separate blog post.

4. Integration with EPM – BI EE 10.1.3.4 introduced the first steps of integration between BI EE and EPM. In BI EE 10g, we could embed BI Answers, Dashboards etc within an EPM workspace. Also, SSO capability was added between the EPM and BI Suites. But there was no native integration between the reporting tools like Hyperion Financial Reporting and BI EE. One had to use methods like the one i have used here and here. In 11g, this is not needed anymore. It is possible navigate to any EPM report (HFR & Web Analysis) and we can also pass parameters from BI EE to the target EPM report. I will blog about this in detail in another blog post.

BI EE 11g provides us with a lot of potential opportunities for integration that weren’t easily available in 10g. Next up is a blog post on how to call Java-EJB methods to add watermarks to BI EE PDF exports.

OBIEE Multi User Development 11g

Creating Projects

• File > Open > Offline

• Manage > Projects>New Project

• Provide a Name to the project

• Select rpd objects to be part of the project and save








“extractprojects” Utility

• Command line utility for extracting OBIEE projects from MUD RPD

• Located at the Dir : ORACLE_INSTANCE/bifoundation/OracleBIApplication/coreapplication/setup

• extractprojects –B base_repository_name -O output_repository_name {-I input_project_name} [-Prepository_password] [-L]

• extractprojects -B my_repos.rpd -O extract_repos.rpd -I project1 -I project2

Give password: my_rpd_password

• Logging file ProjExtr.YYYYMMDD.HHMMSS.xml

MUD Menu Options

• Compare with Original. Compares the working extracted local repository to the original extracted repository. When this option is selected, the Compare repositories dialog opens and lists all the changes made to the working extracted repository since you checked out the projects.

• Merge Local Changes. Locks the master repository on the network multiuser directory to allow you to check in your changes.

• Publish to Network. After you successfully merge your changes, the master repository opens locally and the Publish to Network submenu item is available. When you select this option, the lock is removed, the repository is published, and the repository closes.

• Undo Merge Local Changes. Rolls back any previously merged local changes, and leaves the repository checked out so that you can make additional changes and then merge your local changes again. This option is only available after you have already merged local changes.

• Discard Local Changes. Any time after check out and before check in, you can discard your changes. When you select this option, the working repository closes without giving you an opportunity to save your work.

MUD Env Development Options

• \\network\MUD\devoptfile.opt created to specify development options

• In standard windows INI format

• Hidden flag should be turned on for the file

• To be managed “ONLY by MUD administrators”

• OPT file contents and explanations :

[Options]

BuildNumber = Yes (Displays Version of rpd)

Admin = weblogic;admin2 (Logins of MUD Admins)

Mandatory Consistency Check = Yes (Forces CC when before Publish)

Equalize During Merge = Yes (Forces Equalization during merge process)























OBIEE 11G Multiuser Development Environment

Preparing the Environment - Initial Administrative Tasks

The Oracle BI Repository development process is conceptually identical to the classic Software Configuration Management (SCM) three-way merge, in that changes are managed by merge and reconciliation. The Oracle BI Repository is stored as an .rpd file. Changes are managed by using the Administration Tool. Developers check out the file and make changes locally. Then, these changes are reconciled and merged into the master repository. To read a more detailed description and view an image of the merge process, click this link.

In this topic, you review user roles and privileges in Oracle WebLogic Server, set up the MUDE directory, and create a project.
Verifying User Roles and Privileges by Using WebLogic

In previous releases of Oracle BI, users were stored in the repository. These users are now stored in the WebLogic LDAP or whatever identity store with which your system is configured.

To review user roles and privileges in Oracle WebLogic Server, perform the following steps:

1 . Open the WebLogic Administration Console. Open a browser window and in the address bar, enterhttp:\\:port\console (for example, http:\\localhost:7001\console). Note that 7001 is the default port assignment for the Oracle WebLogic Server Administration Console.

2 . The Oracle WebLogic Server Login window appears. Enter your username and password (for example,weblogic/welcome1).



Note: During installation, you are prompted for a username and password to use as an Oracle BI Administrator. This user (weblogic, for example) has administrative privileges across the Oracle Business Intelligence (BI) stack. This includes the Oracle BI Repository, the Oracle BI Presentation Catalog, Oracle BI Publisher, the identity store in WebLogic, and so on.


3 . Click Login. The Oracle WebLogic Server Administration Console appears.




4 . Select Security Realms from the Domain Structure pane on the left.




5 . The "Summary of Security Realms" pane appears on the right. Select myrealm from the Realms table.




6 . The "Settings for myrealm" pane appears on the right. Click the Users and Groups tab.




7 . All users who are configured in this security realm appear in the Users table. In the Name column, clickabell.




8 . The "Settings for abell" pane appears. From this pane, you can change Adam's name, password, attributes, and the groups to which he belongs. Click the Groups tab.




9 . Review the detail for Adam Bell on the Groups tab and note the two selection areas: Available and Chosen. You select a group and then use the arrow buttons () to toggle a parent group membership on or off for the specific user.

There are three default groups specific to Oracle BI: BIAdministrators (in the Available grouping in the image), BIAuthors, and BIConsumers (both in the Chosen grouping in the image). These default groups are provided as a convenience during installation, so that you can use the Oracle BI software immediately. Groups are nested in a hierarchy.
Members of the BIAdministrators group have permissions equivalent to those of theAdministrator user of earlier releases. Members of the BIAdministrators group are by default members of both other groups.
Members of the BIAuthors group have permissions necessary to create content for others to consume. Members of BIAuthors are members of BIConsumers.
Members of the BIConsumers group have permissions necessary to consume content created by others.

Now that you've reviewed Adam's privileges, click the breadcrumb trail for "Users and Groups" (highlighted in the image below, just above the "Settings for abell" pane) to review the privileges for Helen Mayes. The breadcrumb trail provides a means for you to quickly navigate back to pages that you have previously viewed.




10 . The "Settings for myrealm" pane reappears. Click hmayes.




11 . Once again click the Groups tab. Note that Helen is also a member of the BIAuthors and BIConsumers groups.




12 . Click Log Out and then close your browser.



Reviewing User's Roles in Identity Manager Within the Administration Tool

You can also review default security settings by using the Administration Tool.

To review security settings within the Administration Tool, perform the following steps:



1 . Open the Administration Tool. Click Start > All Programs > Oracle Business Intelligence > BI Administration.



Note: When you first start the Administration Tool, a DOS window appears. Keep this window open while you work. You can minimize the window to avoid accidentally closing it.


2 . Click File > Open > Offline.




3 . The repositories are located in \bifoundation\OracleBIServerComponent\coreappplication_obips1\repository(for example,c:\bi11g\instances\instance3\bifoundation\OracleBIServerComponent\coreappplication_obips1\repository).

In the Open dialog box, select the SampleApp repository (for example, SampleApp_BI0010.rpd) and clickOpen.



Note that Oracle BI Release 11g (11.1.1.5) automatically appends a numeric, incremental suffix to each version of the .rpd file.


4 . A message box appears, indicating that this repository must be opened in read-only mode. This is because the repository has been loaded into the Oracle BI Server. Click Yes when the message box appears.




5 . In the Open Offline dialog box, enter the Repository Password (for example, Admin123) and click OK. If you are unsure of this password, you can verify it with your local administrator.



The repository opens in read-only mode.




6 . Click Manage > Identity.



The Identity Manager dialog box appears. You can review each user authorized for this repository and also each application role.




7 . Double-click hmayes to view the roles that are assigned to Helen.




8 . These roles are precisely the same as those identified in Oracle WebLogic Server. Click Cancel.



You can similarly view Adam's application roles, if you so choose.

9 . Click Application Roles. Examine the roles available in the Administration Tool.




10 . Click Action > Close to close Identity Manager.

11 . Click File > Close to close the repository. Leave the Administration Tool open.

Creating a Project

The next step is to create one or more projects. As mentioned above in Scenario, the primary reason to create projects is to support multiuser development. Administrators can create projects so that developers and groups of developers can work on projects in their own area of responsibility.

To create a project, perform the following steps:

1 . For this tutorial, SampleApp_BI0009.rpd, will be modified in the MUDE. You can use the most current offline version of your repository.

In the Administration Tool, click File > Open > Offline (or you can select the repository from the recent repository list).




2 . Enter the repository password (for example, Admin123) and click OK.

3 . Click Manage > Projects to open the Project Manager.



The Project Manager dialog box appears. Two projects are evident in the right pane: Samp Essbase and Samp Relational. These projects were defined as metadata objects in the Sample App repository that is shipped with the Sample Application.




4 . Click Action > New Project.



The Project dialog box appears. The Project dialog box is composed of two panes—the available objects are contained in the left pane, whereas the selected items are contained in the right. You build the project by adding subject areas or logical fact tables to the project. Additionally, the Project dialog box consists of a name text box (required entry) and a description text box (optional) for documentation purposes.



You can group facts by subject area or by business model. You can also select one or more logical fact tables in the business model that are related to the subject area or you can select a subject area. The Addbutton is enabled once an object is selected in the left pane.

The Administration Tool adds all the logical fact tables automatically. Adding a subject area includes all fact tables and dependencies in the subject area. Adding a logical fact table includes the subject area containing the table. In both cases, logical dimension tables joined to the logical fact tables are implicitly included, even though they do not appear in the right pane.


5 . Enter Sample Apps Fact Table in the project name text box.




6 . Click the plus sign () to expand Business Models, and then expand 1 - Sample App.




7 . Select F0 Revenue Base Measures in the left pane and click Add. The logical fact table appears in the right pane.




8 . Click OK. Your new project appears.




9 . Add a second project. Click Action > New Project.

10 . Enter Sample Apps Presentation in the project name text box.

11 . Click the plus sign () to expand Business Models.

12 . Select 1 - Sample App and click Add.



Note: You must have at least one fact table in a project.

13 . Collapse Business Models. Click the minus sign () for Business Models to gain more space in the left pane.

14 . Click the plus sign for Presentation to expand the Presentation node in the left pane.



The Presentation node contains Presentation layer objects that are not automatically added to your project. You must explicitly include these objects in your project, if you want to work with them.


15 . Select A - Sample Sales in the left pane and then click Add. Presentation (A - Sample Sales) appears in the right pane.




16 . Expand Presentation, and then expand A - Sample Sales in the right pane and take some time to review the structure.




17 . Click OK to add the new project.




18 . Double-click the Sample Apps Presentation project in the right pane of Project Manager to edit the project.

19 . Expand Presentation > A - Sample Sales in the right pane.

20 . Remove all but the following tables from the right pane:

—Time

—Products

—Offices

—Sales Person

—Customers

—Cust Regions

—Orders

—Ship To Regions

—Orders Dates

—Base Facts

—Calculated Facts

Select the table that you want to delete (for example, Alternate Calendars) from the right pane, and then click Remove. Hint: You can press Ctrl-click to select multiple tables.

Your project selection should look like this:




21 . Click OK.

22 . Click File > Save to save your changes to the repository. When prompted to check global consistency, click No.




23 . Click File > Close to close the repository.

24 . Minimize the Administration Tool.

Setting Up the MUDE Directory

The final administrative-type step that you perform is to locally set up the MUDE. The administrator must identify or create a shared network directory that all developers can access. Then, the administrator copies the appropriate repository files to that location. Typically, this directory is a shared network directory and contains copies of master repositories that multiple developers access during checkin and checkout. Developers create a pointer to this directory when they set up the Administration Tool on their own machines. This directory must be accessible to all developers and repository servers.

Note: The administrator must set up a separate, shared network directory that is dedicated to multiuser development. If it is not set up and used as specified, critical repository files can be unintentionally overwritten and repository data can be lost. In this OBE, the shared directory is a local directory, :\RPD.

To set up a multiuser development directory and copy the appropriate repository file, perform the following steps:

1 . Navigate to a local drive and create a new directory named RPD (for example, c:\RPD).




2 . Right-click RPD and select Properties from the shortcut menu.




3 . In the RPD Properties dialog box, click the Sharing tab. Select Share this folder and click Permissions.




4 . In the "Permission for RPD" dialog box, select the Full Control check box and click Apply.



Note: For this tutorial only, full control is being granted. Normally you would only grant full control permissions to those people who require access to the RPD.


5 . Click OK > OK.

You have shared your directory that will house the repository.


6 . Next, copy the most current offline version of the SampleApp repository that will be modified in the MUDE.

Navigate to \bifoundation\OracleBIServerComponent\coreappplication_obips1\repository (for example,c:\bi11g\instances\instance3\bifoundation\OracleBIServerComponent\coreappplication_obips1\repository) and select the highest version of the SampleApp repository.




7 . Copy and paste the repository file into the :\RPD directory (for example, c:\RPD).




8 . Right-click the repository file and rename the file SharedMaster.rpd. This is the dedicated multiuser development repository that will be modified and merged back into the master repository. This repository contains the user projects as well.



You have completed the administrative tasks.

WORKING IN A MUDE
Setting Up Users and Pointing to the Multiuser Directory

Before a developer can access the MUDE, the user must be set up in the Administration Tool. This includes identifying the user and pointing to the appropriate repository.

To set up a user to access the MUDE, perform the following steps:

1 . Click Tools > Options. The Options dialog box appears. Click the Multiuser tab.



The �Multiuser development directory� text box is mandatory. It must be completed by any user who wants to use the MUDE feature. The multiuser development directory must be set to the directory on the network shared with other MUDE developers. The Administration Tool stores this path in a hidden Windows registry setting on the developer�s workstation, and uses it during checkout and checkin.

The �Full name� text box is optional. If a user enters a name in this text box, the value is used by default in the �Full name� text box of the repository Lock Information dialog box—this dialog box locks the master repository in the shared directory. For convenience and tracking, each MUDE developer should enter a full name. The value is stored in the HKEY_CURRENT_USER part of the registry and is, therefore, unique for each login.

Note: For this tutorial, Administrator is used as the developer name because it is not possible to produce multiple users on multiple machines for this OBE. In a real-world scenario, this step would be performed on each developer user's computer.

2 . Click Browse.

3 . In the Browse For Folder dialog box, navigate to and select your shared RPD directory, and then click OK.




4 . Enter Administrator in the "Full name" text box and click OK.



You are now ready to perform multiuser development.

Checking Out a Project

To check out the project, which begins the development process, perform the following steps:

1 . Click File > Multiuser > Checkout.




2 . In the "Extract from SharedMaster.rpd" dialog box, enter the repository password (for example, Admin123) and click OK.




3 . The Browse dialog box appears. Select the check box for Sample Apps Presentation and click OK.




4 . The "Create new subset repository" dialog box appears.



In the "Create new subset repository" dialog box, change the default file name, Metadatan.rpd (where nrepresents a variable number), to abell.rpd.

There are several items to note at this point:
The file name (abell.rpd, representing Adam Bell) is arbitrary.
The repository file is being saved to the default repository directory (\bifoundation\OracleBIServerComponent\coreappplication_obips1\repository) not the RPD directory.
A copy of the shared repository (SharedMaster.rpd) has been copied to the default repository directory.




5 . Click Save.

6 . Adam Bell's repository appears with the subset of data from the Sample Apps Presentation project. The other subject areas and business models from SharedMaster do not appear. Note that Adam's repository name appears in the title bar at the top of the Administration Tool.



Leave the repository and the Administration Tool open. Minimize the Administration Tool.


7 . Navigate to :\RPD by using Windows Explorer. Two new files appear: SharedMaster.000 andSharedMaster.mhl. The SharedMaster.000 file is an automatic backup file for SharedMaster.rpd, whereas the SharedMaster.mhl file tracks the checkout status and parameters, including project, computer, and user.




8 . Navigate to the default repository directory (\bifoundation\OracleBIServerComponent\coreappplication_obips1\repository). Three new files appear: originalabell.rpd, abell.rpd.Log, and abell.rpd. The abell.rpd file is a subset of the SharedMaster repository that you modify. The originalabell.rpd file contains the original repository file, which the Administration Tool uses to track your changes or revert to the original. Finally, the abell.rpd.Log file is your local log file.




9 . Check out the repository as Helen Mayes. Open up a new instance of the Administration Tool, and then click File > Multiuser > Checkout.




10 . In the "Extract from SharedMaster.rpd" dialog box, enter the repository password (for example, Admin123) and click OK.




11 . The Browse dialog box appears. Select the check box for Sample Apps Presentation and click OK.



Note that you are not given any indication that another developer currently has the project out for update. This is an intentional feature of the the product. Multiple developers can work on a single project. All changes are merged during the checkin process.

12 . In the "Create new subset repository" dialog box, change the default file name, Metadatan.rpd (where nrepresents a variable number), to hmayes.rpd.




13 . Click Save.

14 . Helen Mayes' repository appears.



Leave the repository and the Administration Tool open. Minimize the Administration Tool.


15 . Navigate to the default repository directory (\bifoundation\OracleBIServerComponent\coreappplication_obips1\repository). Three new files appear for Helen Mayes, just as they appeared for Adam Bell: originalhmayes.rpd, hmayes.rpd.Log, andhmayes.rpd.



Making Changes to the Repository

The same repository and project were simultaneously opened, demonstrating the MUDE. Adam and Helen are ready to begin their modifications.

Most changes that can be made to standard repository files are also supported for local repository files (such as abell.rpd and hmayes.rpd). You can add new logical columns, logical tables, change table definitions, and so on.

Physical connection settings should not be modified in a local repository. To prevent you from overwriting passwords and other important objects in the master repository, the physical connection and security settings, and database feature tables changes are not retained during a multiuser development merge. Note: All repository connection information specified in the repository metadata, such as Open Database Connectivity (ODBC), must also exist on the developer's workstation.

To make changes to the repository, perform the following steps:



1 . Select Adam's Administration Tool. You can maximize the tool or simply select it from the taskbar along the bottom of your window.



Adam's Administration Tool reappears.




2 . Click View and deselect Physical. The Administration Tool should look like this:




3 . Click View and deselect Business Model and Mapping. Only the Presentation layer should be visible in the Administration Tool.


4 . Expand A - Sample Sales.




5 . Select Customers and Cust Regions by using the Ctrl-click method.




6 . Right-click and from the shortcut menu, select Delete and then confirm the delete. This is an easy modification to track during your review process.



Adam Bell's repository should look like this:




7 . Click File > Save and do not check for global consistency.


8 . Select Helen's Administration Tool now. You can limit the view to just the Presentation layer if you so choose, just as you previously limited Adam's view.


9 . Expand A - Sample Sales and select Products.


10 . Right-click and from the shortcut menu, select Delete and confirm the delete.

Helen's repository should look like this:




11 . Click File > Save and do not check for consistency.

Reviewing Multiuser Options During Development

After you and other developers have finished making your changes, you have several options available for analyzing the changes. These options include the following:
Compare with Original: Compares the working, extracted local repository to the original extracted repository
Merge Local Changes: Allows you to check in your changes. (Discussed below in "Merging Local Changes.")
Publish to Network: Locks the repository, verifies that no other developer-published changes to the master exist, and then publishes the repository. (Discussed below in "Publishing Local Changes.")
Undo Merge Local Changes: Rolls back any previously merged local changes, and leaves the repository checked out so that you can make additional changes, and then merge your local changes again. This option is only available after you have already merged local changes.
Discard Local Changes: Abandons your changes. When you select this option, the working repository closes without giving you an opportunity to save your work. You can discard your changes any time after checkout, but before checkin.

To review the multiuser options, perform the following steps:

1 . Using Adam's repository (abell.rpd), click File > Multiuser > Compare with Original.




2 . The "Compare repositories" dialog box appears. In this example, this dialog box compares abell.rpd (the subset repository) with originalabell.rpd. You can see the deletion of the Presentation layer tables by Adam. Scroll down and examine all objects that were deleted.



Within this dialog box, you can perform functions, such as Equalize (used to treat two objects in two repositories that have the same name but different upgrade IDs as the same object), Mark (annotates the object you select with a surrounding box for comparison against other objects), Create Patch (generates an XML patch file that contains only the changes made to a repository, which can then be applied to the original version of the repository to create the new version), and so on.


3 . Click Cancel.

4 . Minimize Adam's Administration Tool.

5 . Compare Helen's changes now. In Helen's Administration Tool, click File > Multiuser > Compare with Original.




6 . Review the changes and then click Cancel.


7 . Helen realizes that she should not have deleted the Products table. She needs to undo her changes before the local repositories are merged, and the new master is created.

Click File > Multiuser > Discard Local Changes.



Products is restored to the repository and the repository immediately closes (the Administration Tool remains open).


8 . Navigate to \bifoundation\OracleBIServerComponent\coreappplication_obips1\repository. You can clearly see that Helen's three files, originalhmayes.rpd, hmayes.rpd.Log, and hmayes.rpd, have been removed and will no longer become part of the repository update.




9 . Helen needs to continue her work in the MUDE. She therefore needs to check out the shared repository once again. In the Administration Tool, click File > Multiuser > Checkout.

Note: If you are running this tutorial on a local machine and are building both developer's (abell andhmayes) repositories on the local hard drive, you may receive a Window's sharing message that prompts you to overwrite the SharedMaster.rpd. If you receive this message, click No.


10 . In the "Extract from SharedMaster.rpd" dialog box, enter the repository password and click OK.


11 . The Browse dialog box appears. Select the check box for Sample Apps Presentation and click OK.


12 . In the "Create new subset repository" dialog box, change the default file name to hmayes.rpd, as previously named, and click Save.


13 . Expand A - Sample Sales and ensure that Products has been restored.

Helen's repository should look like this:




14 . Minimize Helen's Administration Tool.

CHECKING IN AND PUBLISHING A MUDE PROJECT
Merging Local Changes

After all changes are finished, the developers must check the project into the master repository in the multiuser development directory. Only one developer at a time can merge metadata from a local repository into the master.

The following actions occur when the checkin (merge) process begins:
The Administration Tool determines whether the shared master repository is currently locked. If not, it locks the shared master repository, preventing other developers from performing a merge until the current merge is complete.
If there are any conflicts, the Merge Repository Wizard opens and displays the Define Merge Strategy page. You then make merge decisions about whether to include or exclude objects by choosing Current or Modified from the Decision drop-down list.
A local version of the master repository opens.
The Administration Tool automatically creates a comma-separated value (.csv) file in the local repository directory on the developer�s machine. This file lists changes made to the shared master repository during the merge.
A new file is created in the shared master repository directory with a modified subset.

To merge your changes to the master repository, perform the following steps:



1 . Select Adam's Administration Tool. Click File > Multiuser > Merge Local Changes. This locks the shared repository until checkin is complete.



The Merge Repository Wizard briefly flashes.



If any conflicts exist, the Merge Repository Wizard - Define Merge Strategy dialog box would appear. You would then make merge decisions about whether to include or exclude objects by choosing Current or Modified from the Decision drop-down list.


2 . The SharedMaster repository opens. Expand A - Sample Sales to verify that the deleted objects (Customers and Cust Regions) do not appear.



At this point, you can undo the local merge, discard the local changes, or publish the repository. These options are available from the File > Multiuser submenu.

If other local repositories need to be merged (for example, hmayes.rpd), you must merge these before publishing. When working in a MUDE, the master repository is not locked when you merge local changes. Instead, the master repository is locked during the "Publish to Network" step. This reduces the total time that the master repository is locked to avoid lock contention issues.

An Oracle best practice is to publish immediately following the merge.


3 . As noted in the introduction to this topic, a merge log file (*.csv ) is created that contains the merge changes. Navigate to \bifoundation\OracleBIServerComponent\coreappplication_obips1\repositoryand open SharedMaster.merge_log.csv.




4 . Review the changes in the merge log file.




5 . Close the log.

Publishing Local Changes

After all local repositories are merged, you publish the local changes to create a new master repository. The publish step checks to ensure that no other developer published changes to the master between the time that you merged local changes and the time that you published to the network. If the program logic discovers that another repository developer has published to the network in this time period, the system will automatically redo the merge with the master, rolling back the repository version that you used for the Merge Local Changes step, and then it will merge your changes with the new master.

To publish the local changes, perform the following steps:



1 . Adam had previously sent out an email reminding his peers that he was ready to merge and publish the new repository. Helen did not see the email. Adam continues with his task.

In Adam's Administration Tool, click File > Multiuser > Publish to Network.



Do not check for consistency.


2 . The Lock Information dialog box appears. The master repository is locked to prevent concurrent update.

Enter Adam Bell in the Full Name text box and enter a comment for documentation into the Comment text box.




3 . Click OK. If you receive a message prompting to use this full name, click Yes.



The local copy of the master repository merges with the master repository in the shared folder. That is, Adam's changes are merged into SharedMaster, and then, originalabell.rpd, abell.rpd.Log, and abell.rpdfiles are deleted. The SharedMaster repository within Adam's Administration Tool closes.

Resolving Issues for a Repository Update



1 . Helen wants to assist with the devlopement effort. She decides that she will perform the publication of the repository to the network (not knowing that Adam has already merged and published the repository).

Before Helen can publish, she needs to perform a merge (although she has not made any changes to the repository ). In Helen's Administration Tool, click File > Multiuser > Merge Local Changes. The Merge Repository Wizard - Define Merge Strategy dialog box appears.




2 . Select the first row of the Conflicts table. The Differences pane refreshes with conflict details.




3 . Click the ellipsis button () to the right of the Differences pane to review the details of the objects that were modified.




4 . Click Cancel.


5 . Notice that the repository panes area displays the original (originalhmayes) repository, along with her modified repository, and the current (SharedMaster) that was updated by Adam.



At this point, Helen must make a decision about how to proceed with the merge. Realizing that there is a conflict between her version and the master, Helen contacts Adam and resolves the issue.


6 . In the Conflicts table at the top of the wizard, select the Decision drop-down list for the Customers table, and then select Current. This selection chooses the current repository (the repository that does not contain Customers and Cust Regions) over Helen's version.




7 . In the Conflicts table at the top of the wizard, select the Decision drop-down list for the Cust Regions table, and then select Current.




8 . Click Finish.


9 . Click File > Save and do not check for consistency.


10 . Click File > Close, leaving the Administration Tool open.

Reviewing the History and Verifying the New Repository

You can review all modification activity by reviewing the history associated with the MUDE.

To review the history, perform the following steps:



1 . Click File > Multiuser > History and when prompted, enter the password.



The "SharedMaster.rpd Multi User History" dialog box appears.




2 . Right-click the Version 1 row and select View > Details.



Note: You can also review the projects and changes before the merge.


3 . The "Version 1 details" dialog box appears. This shows all multiuser changes.



Click X to close both the "Version 1 details" and " SharedMaster.rpd Multi User History" dialog boxes.


4 . Next, open the new repository. Click the Open Offline icon (), navigate to :\RPD, and selectSharedMaster.rpd.


5 . Click Yes to acknowledge that you can only open it as a read-only file.


6 . Enter the password. The new repository appears.


7 . Expand A - Sample Sales in the Presentation layer and verify that the new repository changes have been merged successfully and that the Customers and Cust Regions objects are not part of the new repository.



Click File > Exit to close the Administration Tool.


8 .

Navigate to :\RPD and notice that a new subset file appears. If you need to roll back the changes, you can use this subset to accomplish that task.