| Oracle® Fusion Middleware Metadata Repository Builder's Guide for Oracle Business Intelligence Enterprise Edition (Oracle Fusion Applications Edition) 11g Release 1 (11.1.1) Part Number E20836-05 |
|
|
PDF · Mobi · ePub |
| Oracle® Fusion Middleware Metadata Repository Builder's Guide for Oracle Business Intelligence Enterprise Edition (Oracle Fusion Applications Edition) 11g Release 1 (11.1.1) Part Number E20836-05 |
|
|
PDF · Mobi · ePub |
This chapter describes tasks related to managing your Oracle BI repository files, including comparing and merging repositories, equalizing objects, querying and managing metadata, and changing the repository password.
This chapter contains the following topics:
This section explains how to compare all repository objects in two different repositories.
If you are using an Oracle BI Applications repository and have customized its content, you can use this feature to compare your customized repository to a new version of the repository received with Oracle BI Applications.
See "Merging Repositories" for more information about merging your customized Oracle BI Applications repository with a new version of the repository.
This section contains the following topics:
This section explains how to use the Compare dialog in the Administration Tool.
To compare two repositories:
In the Administration Tool, open a repository in offline mode.
The repository that you open in this step is referred to as the current repository. See "Using Online and Offline Repository Modes" for instructions on opening a repository.
From the File menu, select Compare.
In the Select Original Repository dialog, select the repository you want to compare to the open repository. Select Repository from the submenu to select a binary repository file in RPD format, or select XML to select a set of MDS XML documents.
In the Open Offline dialog, enter the repository password and click OK.
Use the Compare repositories dialog to review the differences between the two repositories. Figure 17-1 shows the Compare repositories dialog.
Table 17-1 lists and describes the values in the Change column.
Table 17-1 Compare Repositories Dialog: Change Column
| Change | Description |
|---|---|
|
Created |
Object was created in the current repository and does not exist in the original repository. |
|
Deleted |
Object exists in the original repository but has been deleted from the current repository. |
|
Modified |
Object exists in the original repository but has been modified in the current repository. |
Table 17-2 lists and describes some of the buttons in the Compare repositories dialog.
Table 17-2 Compare Repositories Dialog: Buttons
| Button | Description |
|---|---|
|
Filter |
Opens the Comparison Filter dialog to enable you to filter the objects that appear in the Compare repositories dialog by type of change and type of object. You can specify what you want to appear and what you want to be hidden. If you select Group created and deleted objects, the tool filters out the child objects of created and deleted objects, so that only the parent objects are shown. By default, all items are shown. |
|
Find |
Search by an object Name and Type (such as Initialization Block). |
|
Select |
Enables you to select a repository to compare with the current repository. Select Repository from the submenu to select a binary repository file in RPD format, or select XML to select a set of MDS XML documents. |
|
Find Again |
Search again for the most recent Find value. |
|
Diff |
Differences between the current repository and the original repository. |
|
Save |
Saves a list of the differences between the two repositories. |
|
Stats |
Provides the number of changes by Change type. |
|
View 1 |
Opens an object in the original repository in read-only mode. |
|
Edit 2 |
Opens an object in the current repository in read/write mode. |
|
View 2 |
Opens an object in the current repository in read-only mode. This button is only displayed when viewing MUD history, or when the current repository is open in read-only mode. |
|
Equalize |
Opens the Equalize Objects dialog so that you can model changes to the upgrade ID of the objects. See "Equalizing Objects" for more information. |
|
Create Patch |
Creates a patch file that contains the differences between the repositories. See "Performing Patch Merges" for more information. |
|
Mark |
Marks the object you select. Boxes appear around created and modified objects. To remove marks, from the File menu, choose Turn off Compare Mode. |
You can also compare repositories and create patch files using the comparerpd utility. This feature is especially useful when you want to compare repositories or generate patches on Linux and UNIX systems where the Administration Tool is not available. The compare utility is available on both Windows and UNIX systems.
Before running comparerpd, you must first run bi-init to launch a command prompt or shell window that is properly initialized. See "Running bi-init to Launch a Shell Window Initialized to Your Oracle Instance" for more information.
Syntax
The comparerpd utility takes the following parameters:
comparerpd [-P modified_rpd_password] -C modified_rpd_pathname [-W original_rpd_password] -G original_rpd_pathname {-O output_csv_file_name | -D output_patch_file_name | -M output_mds_xml_directory_name} -E -8
Where:
-P modified_rpd_password is the repository password for the modified repository, also called the customer or customized repository.
-C modified_rpd_pathname is the name and location of the modified repository.
-W original_rpd_password is the repository password for the original repository.
-G original_rpd_pathname is the name and location of the original repository.
-O output_csv_file_name is the name and location of a csv file where you want to store the repository object comparison output.
-D output_patch_file_name is the name and location of an XML patch file where you want to store the differences between the two repositories.
-M output_mds_xml_directory_name is the top-level directory where you want to store diff information in MDS XML format. Note that a list of removed XML files is stored in the directory tree under the top-level directory at:
oracle\bi\server\base\DeletedFiles.txt
You can specify an output CSV file using -O, an XML patch file using -D, or an MDS XML directory tree using -M. You cannot specify more than one output type at the same time.
Note that if the patch contains passwords, such as connection pool passwords, the patch file is encrypted using the repository password from the current repository. The current repository password effectively becomes the patch file password. You might need to supply this patch file password when applying the patch, if it is different from the repository password for the original repository.
-E is an optional argument that causes UIDs to be used to compare expression text. If -E is not specified, strings are used.
-8 specifies UTF-8 encoding.
Note:
The arguments for the modified_rpd_password and original_rpd_password are optional. If you do not provide password arguments, you are prompted to enter any required passwords when you run the command. To minimize the risk of security breaches, Oracle recommends that you do not provide password arguments either on the command line or in scripts. Note that the password arguments are supported for backward compatibility only, and will be removed in a future release.
For example:
comparerpd -C customer.rpd -G original.rpd -O diff.csv Give password for customer repository: my_cust_password Give password for original repository: my_orig_password
This example generates a comparison diff file in CSV format called diff.csv from the customer.rpd and original.rpd repositories.
comparerpd -C customer.rpd -G original.rpd -D my_patch.xml Give password for customer repository: my_cust_password Give password for original repository: my_orig_password
This example generates an XML patch file called my_patch.xml from the customer.rpd and original.rpd repositories.
This option enables you to remove marks applied to objects while using the Compare Repositories and Merge Repositories options. The Turn off Compare Mode option is only available after you have clicked Mark during the File > Compare action. If no repository object is marked, this option is not available.
To enable the Turn off Compare Mode option:
In the Administration Tool, select File, then select Turn off Compare Mode.
If you have objects in two repositories that have the same name but different upgrade IDs, you may want to treat them as the same object. To accomplish this, you can use the equalizerpds utility to equalize the objects by giving them both the same upgrade ID. Alternatively, you can equalize objects as part of the merge process.
You can also use the Equalize Objects dialog (available from the Compare repositories dialog) to preview what the repository will look like after you run the equalizerpds utility.
This section contains the following topics:
Objects may need to be equalized because the Administration Tool tracks the history of each repository object using the upgrade ID of the object. The upgrade ID is a unique identifier for each object. Sometimes, the upgrade ID can change because of user actions or during merge. When this occurs, and a subsequent comparison is done, the Administration Tool treats the new upgrade ID as a new object, and the missing original upgrade ID as a deleted object.
For example, assume you have two identical repositories. In one repository, delete a presentation column, then re-create it again. When you compare the two repositories using the Compare repositories dialog, there are two entries for the presentation column: one that shows the old object as deleted, and one that shows the new object as created. Without using the Compare repositories dialog, it is hard to tell that this action occurred, because the Administration Tool typically shows only the object name and properties, not the underlying upgrade ID.
It is very useful run the equalizerpds utility on your repositories before merging them to equalize your changes. Equalizing any opposing changes (such as a column that has been duplicated, and then renamed) cleans up the underlying upgrade IDs and prevents unintended renaming during the merge.
When you equalize objects, you can lose track of object renames because legitimate object renames become different objects. In other words, intentional renames you did in the repository might be changed to different upgrade IDs, so subsequent merges erroneously treat the renamed object as a new object. To avoid this situation, enter the before and after names of intentionally renamed objects in a rename map file that you then pass to the utility. The equalizerpds utility uses the information in the file to ensure that the original IDs are used in the renamed current objects.
Tip:
You can view the upgrade ID for repository objects using the Query Repository dialog. To do this, follow these steps:
Select Tools, then select Query Repository.
Run a query. See "Querying and Managing Repository Metadata" for details.
Click Columns.
Select Upgrade ID from the list. You can use the Find button to help locate the Upgrade ID.
Click OK. A new column showing the upgrade IDs appears in the Results list.
Note that Upgrade ID is not available as a column option unless you have selected Show Upgrade ID in Query Repository in the General tab of the Options dialog. See "Setting Administration Tool Options" for more information.
The Equalize Objects dialog gives you a preview of what your repository will look like if you run the equalizerpds utility on it. The Equalize Objects dialog provides a convenient way to compare changes related to objects that have the same name, but it does not persist any of the changes. Note that using the Equalize Objects dialog can be a very slow process for larger repositories.
To view and use the Equalize Objects dialog:
In the Administration Tool, open your repository in offline mode.
From the File menu, select Compare.
In the Select Original Repository dialog, select the repository you want to compare to the open repository (typically the original repository). Select Repository from the submenu to select a binary repository file in RPD format, or select XML to select a set of MDS XML documents.
In the Open Offline dialog, enter the repository password and click OK. The Compare repositories dialog is displayed.
Click Equalize to display the Equalize Objects dialog.
The Equalize Objects dialog shows a list of changes where you may want to consider objects with different upgrade IDs to be the same object. You can use the following options to model how the changes might get equalized:
Click Automatic to automatically equalize changes related to objects that have the same name. The changes appear in the Equated table.
If no changes can be automatically equalized, nothing appears in the table, and the OK button remains disabled.
Select an object in the Deleted list, then select the equivalent object in the Created list and click Add or Add Plus to equate the objects. Add Plus adds the object along with its child objects to the Equated table, while Add simply adds the selected object. For example, if you select a Subject Area and click Add Plus, the underlying Presentation Tables and Presentation Columns are added as well.
After you make a manual selection, the Automatic button is disabled.
Select a row in the Equated table and select Remove or Remove All to remove objects from the Equated table. Remove All removes the object along with its child objects, while Remove simply removes the selected object
The Automatic button is enabled after all manual selections are removed.
When you are finished modeling the changes, click OK. The changes appear in the Compare Repositories dialog, but the changes do not persist after you close the dialog.
You can use the equalizerpds utility to equalize the upgrade ID of objects in two separate repositories. If objects have the same upgrade ID, they are considered to be the same object. The utility compares upgrade IDs from the first repository (typically the original repository) with upgrade IDs from the second repository (typically the modified repository). Then, the utility equalizes the upgrade IDs of objects with the same name, using the upgrade ID from the original repository.
The equalizerpds utility is available on both Windows and UNIX systems. However, you can only use equalizerpds with binary repositories in RPD format.
Before running equalizerpds, you must first run bi-init to launch a command prompt that is properly initialized. See "Running bi-init to Launch a Shell Window Initialized to Your Oracle Instance" for more information.
Syntax
The equalizerpds utility takes the following parameters:
equalizerpds [-B original_repository_password] -C original_repository_name [-E modified_repository_password] -F modified_repository_name [-J rename_map_file] [-O output_repository_name] [-Y equalStringSet]
Where:
rename_map_file is a text file containing a list of objects that were renamed and that you want to equalize. The format is a tab-separated file with the following columns:
TypeName Name1 Name2
For example, to include a logical column in the map file that was renamed from Name1 to Name2, provide the following:
ATTRIBUTE "BusinessModel"."Table"."Name1" "BusinessModel"."Table"."Name2"
Do not cut and paste this example as the foundation for your own file, because the tab separators might not get copied properly. Create a new file with proper tabs.
See "About Values for TypeName" for more information about valid TypeName values.
equalStringSet is a set of characters that you want to treat as equal.
Note that the original_repository_password and modified_repository_password arguments are optional. If you do not provide these password arguments, you are prompted to enter the passwords when you run the command (password1 and password2). To minimize the risk of security breaches, Oracle recommends that you do not provide password arguments either on the command line or in scripts. Note that the password arguments are supported for backward compatibility only, and will be removed in a future release.
For example:
equalizedrpds -C original.rpd -F modified.rpd -O modified_equalized.rpd password1: my_original_rpd_password password2: my_modified_rpd_password
In this example, original.rpd is compared with modified.rpd, the upgrade IDs are equalized using the upgrade IDs from original.rpd, and the final result is written to modified_equalized.rpd.
Note:
Be sure to provide the full pathnames to your repository files, both the input files and the output file, if they are located in a different directory.
Table 17-3 shows the available object types and their corresponding values for TypeName.
Table 17-3 TypeName Values
| Object Type | Value for TypeName |
|---|---|
|
Database |
DATABASE |
|
Connection Pool |
CONNECTION POOL |
|
Physical Catalog |
CATALOG |
|
Physical Schema |
SCHEMA |
|
Physical Display Folder |
PHYSICAL DISPLAY FOLDER |
|
Physical Table |
TABLE |
|
Physical Key |
TABLE KEY |
|
Physical Foreign Key |
FOREIGN KEY |
|
Physical Column |
COLUMN |
|
Physical Complex Join |
JOIN |
|
Physical Hierarchy |
HIERARCHY |
|
Physical Level |
PHYSICAL LEVEL |
|
Cube Column |
COLUMN |
|
Cube Table |
CUBE TABLE |
|
LDAP Server |
LDAP SERVER |
|
Custom Authenticator |
CUSTOM AUTHENTICATOR |
|
Variable |
VARIABLE |
|
Application Role |
SECURITY ROLE |
|
User |
USER |
|
User Database Signon |
USER DATABASE SIGNON |
|
Project |
PROJECT |
|
Business Model |
SUBJECT AREA |
|
Logical Dimension |
DIMENSION |
|
Logical Level |
LEVEL |
|
Logical Display Folder |
LOGICAL DISPLAY FOLDER |
|
Logical Table |
LOGICAL TABLE |
|
Logical Source Folder |
LOGICAL SOURCE FOLDER |
|
Logical Table Source |
LOGICAL TABLE SOURCE |
|
Logical Column |
ATTRIBUTE |
|
Logical Join |
ROLE RELATIONSHIP |
|
Logical Key |
LOGICAL KEY |
|
Logical Foreign Key |
LOGICAL FOREIGN KEY |
|
Presentation Catalog |
CATALOG FOLDER |
|
Presentation Table |
ENTITY FOLDER |
|
Presentation Column |
FOLDER ATTRIBUTE |
|
Presentation Hierarchy |
PRESENTATION HIERARCHY |
|
Presentation Level |
PRESENTATION LEVEL |
|
Catalog Link |
CATALOG LINK |
|
Target Level |
CUSTOMER TYPE |
|
List Catalog |
LIST CATALOG |
|
Qualified Item |
QUALIFIED ITEM |
|
Qualifying Key |
QUALIFYING KEY |
|
Sampling Table |
SAMPLING TABLE |
|
Segmentation Catalog |
SEGMENTATION CATALOG |
You can use the Merge Repository Wizard in the Administration Tool to merge Oracle BI repositories. You can merge repositories in binary (RPD) format, or MDS XML format. There are three types of merges:
Full merges are typically used during development processes, when there are two different repositories that need to be merged. The Administration Tool provides a three-way merge feature that lets you merge two repositories that have both been derived from a third, original repository. Full merges can also be used to import objects from one repository into another.
Patch merges are used when you are applying the differential between two versions of the same repository. For example, you might want to use a patch merge to apply changes from the development version of a repository to your production repository, or to upgrade your Oracle BI Applications repository.
Multiuser development merges are used when you are publishing changes to projects using a multiuser development environment. See "About the Multiuser Development Merge Process" for more information.
See also Appendix D, "Merge Rules" for additional information about how repository objects are merged.
This section contains the following topics:
You can use the Administration Tool to merge different repositories. This section describes how to use the full (standard) repository merge feature in the Administration Tool.
This section contains the following topics:
The merge process typically involves three versions of an Oracle BI repository: the original repository, modified repository, and current repository. The original repository is the original unedited repository (the parent repository), while the modified and current repository are the two changed repositories you want to merge. The current repository is the one currently open in the Administration Tool.
During the merge process, the Administration Tool compares the original repository with the modified repository and the original repository with the current repository. Conflicts occur when there are conflicting changes resulting from the two comparisons. For example, a conflict occurs if you rename object A to B in the modified repository, but you rename object A to C in the current repository.
The Merge Repository feature lets you decide on an object-by-object basis which changes you want to keep in the final merged repository. If there are no conflicts, merging is automatic.
There are two types of full merge:
Common Parent. This merge, also called a three-way merge, is useful when you have a common parent repository and two derived repositories. There is a parent (original) repository, and two derived repositories. After the merge, a fourth merged repository is created.
The example shown in Figure 17-3 assumes you are merging binary (RPD) repositories, but you can also perform this type of merge with MDS XML repositories.
Figure 17-3 Example of Full Merge With a Common Parent with Binary Repositories
No Common Parent. This merge, also called a two-way merge, is useful when you want to import objects from one repository to another. In this case, objects are merged from two different repositories with no common parent. To accomplish this, you perform a three-way merge in the Administration Tool with a completely blank repository as the original repository (see Figure 17-4). This functionality replaces the Import from Repository feature that was deprecated in an earlier release.
The example shown in Figure 17-4 assumes you are merging binary (RPD) repositories, but you can also perform this type of merge with MDS XML repositories.
Figure 17-4 Example of Full Merge Without a Common Parent with Binary Repositories
This section explains how to use the Administration Tool to perform a full repository merge with a common parent. Typically, this approach is used when you have an original parent repository and would like to merge the changes made to objects in two modified repository versions (current and modified). Objects that do not exist in the current repository are created as new objects.
To merge two versions of an Oracle BI repository with a common parent:
In the Administration Tool, open the current repository in offline mode.
From the Administration Tool menu, select File, then select Merge. The Merge Repository Wizard appears.
Figure 17-5 shows the Merge Repository Wizard.
Figure 17-5 Merge Repository Wizard: Select Input Files Screen (Full Merge)
In the Select Input Files screen, for Merge Type, select Full Repository Merge.
Select the original parent repository by clicking Select next to Original Master Repository. Select Repository from the submenu to select a binary repository file in RPD format, or select XML to select a set of MDS XML documents.
For binary repositories, browse to select the original repository, and then click Open. For MDS XML format repositories, use the Browse For Folder dialog to select the root folder location of the MDS XML documents, and then click OK.
Provide the password for the original repository in the appropriate Repository Password field.
Select the modified repository by clicking Select next to the Modified Repository field. Select Repository from the submenu to select a binary repository file in RPD format, or select XML to select a set of MDS XML documents.
For binary repositories, browse to select the modified repository, and then click Open. For MDS XML format repositories, use the Browse For Folder dialog to select the root folder location of the MDS XML documents, and then click OK.
Provide the password for the modified repository in the appropriate Repository Password field.
Optionally, you can change the default name and location of the saved (merged) repository by clicking Select next to the Save Merged Repository as field. Select Repository from the submenu to save the merged repository as a binary repository file in RPD format, or select XML to save the merged repository as a set of MDS XML documents.
For binary repositories, provide a new name and location, and then click Save. For MDS XML format repositories, use the Browse For Folder dialog to select the root folder location of the MDS XML documents, and then click OK.
It is a good practice to equalize your changes to clean up underlying object IDs before merging. If you have not yet equalized your changes, select Equalize during merge to equalize objects as part of the merge process. Selecting this option may affect merge performance.
See "Equalizing Objects" for more information about equalizing.
Click Next. If there are any conflicts, the Define Merge Strategy screen of the Merge Repository Wizard appears. If there are no conflicts, the Merge Repository Wizard closes.
Figure 17-6 shows the Define Merge Strategy screen.
Figure 17-6 Merge Repository Wizard: Define Merge Strategy Screen
The Define Merge Strategy screen displays a decision table that shows conflicts for this merge. See Table 17-4 for details about the elements in this screen.
To make decisions about whether to include or exclude objects from the merged repository, choose Current or Modified from the Decision list. Choose Current to keep the change for the selected object in the current repository, or choose Modified to keep the change for the selected object in the modified repository.
When you select an object in the decision table, the read-only text box below the decision table describes what changes were made to that object in the current repository. In addition, the tree panels at the bottom of the dialog show the affected objects for the selected row. Alternatively, you can select an object in one of the tree views to automatically highlight the corresponding row in the decision table.
The Modified option in the Decision list displays a suffix that indicates whether the object in question will be added to or deleted from the merged repository. Modified (A) indicates that the object will be added, and Modified (D) indicates that the object will be deleted.
The type of conflict is displayed in the Description column of the Conflicts table. The decision choices you can make depend on the type of conflict shown in this column. The following list shows example results for different types of conflicts:
Added to Current: Choosing Current keeps the new object in the merged repository. Choosing Modified (D) deletes the new object from the merged repository.
Deleted from Current: Choosing Current keeps the repository as it is without adding the object to the merged repository. Choosing Modified (A) adds the object back into the merged repository.
Changed in both (different): The object was not added or deleted, but at least one of its properties was modified. Click the plus sign (+) to the left of the row to view the property that was changed, as well as its value in the original, current, and modified versions of the repository. Property values are only shown for small-length strings. Longer-length strings like descriptions, features, and init strings are not shown.
Click the option for the value you want to retain in the merged version of the repository. For some properties, such as aliases, you can choose the Merge Choices option to merge the properties rather than choose one over the other. This option is only available if the properties can be merged.
Note:
You typically do not need to make merge decisions regarding objects that have been added to or deleted from the Modified repository. However, you can view change statistics for this merge to see a summary of changes, including objects that have been added to or deleted from Modified. See Table 17-4 for more information about this feature.
After you make a merge decision, the row for that decision in the table changes from red to black. When all rows have a value in the Decision field, the Finish button is enabled.
In addition to making merge decisions, you can perform other operations in the Define Merge Strategies screen. See Table 17-4 for details.
Click Finish.
Table 17-4 lists and describes the elements in the Define Merge Strategies screen.
Table 17-4 Elements in the Define Merge Strategies Screen
| Element | Description |
|---|---|
|
Conflicts table |
The Conflicts table includes the following columns:
For objects with properties that are modified in each repository, a sub-table (grid) is displayed with details of the changed properties. The grid includes the following columns:
|
|
Show qualified names |
When selected, shows fully qualified names for objects in the decision table (for example, "Paint"..."Month Year Ago fact"). Note: When the Show qualified names option is selected, some of the object names can be too long to fit into the cells of the decision table. Use the mouse to hover over the truncated name to see the full name of the object or property. Alternatively, you can manually resize columns, or double click the column separator to expand the column to the width of the object name. |
|
Check consistency of the merged RPD |
When selected, runs a consistency check before saving the merged file. |
 |
Saves a file containing interim changes in the Repository subdirectory so that you can stop work on the merge and continue it later. After saving the changes (decisions), close the Merge repositories dialog by clicking Cancel. Note: If there are a large number of decisions, you can save time by saving the merge decisions to a CSV file, opening the file in Excel or a text editor, and then modifying the merge decisions manually. Then, you can load the updated merge decisions file in the Define Merge Strategies screen, or include the decision file as an argument in patchrpd. |
 |
Loads a saved decisions file from the Repository subdirectory so that you can continue processing a repository merge. This option is especially useful for resolving conflicts after running an automated patch merge using patchrpd. See "Using patchrpd to Apply a Patch" for more information. |
|
Find by Name or Type  |
Searches by an object Name and Type (such as Initialization Block). |
|
Find Again  |
Searches again for the most recent Find value. |
|
View Change Statistics  |
Shows statistics for this merge, such as the number of objects deleted from the Modified repository, the number of objects that were changed in both repositories, and so on. |
|
Details  |
Shows the text in the read-only text box below the decision table in a separate window. |
|
View Original/Modified/ Current repository  |
Shows properties for the affected object in the selected repository. |
This section explains how to use the Administration Tool to perform a full repository merge without a common parent. Use this method when you want to import objects from one repository (the modified repository) into another (the current repository).
Note:
In the repository you choose to define as current, make sure that the Presentation layer references any Physical layer or Business Model and Mapping layer objects that you want to keep. Objects like business models, databases, and connection pools in the current repository that are not referenced by any Presentation layer objects are discarded during the merge. If necessary, you might want to add a placeholder subject area that references the objects before you perform the merge to ensure the desired objects are kept.
See Appendix D, "Merge Rules" for more information about which objects are retained or discarded during the merge process.
To merge two versions of an Oracle BI repository file without a common parent:
If you do not already have a blank repository file to serve as the original repository in the merge, create one, as follows:
Close the blank repository.
Open the current repository in offline mode. This is the repository that contains the objects you want to import.
From the Administration Tool menu, choose File, then select Merge. The Merge Repository Wizard appears.
In the Select Input Files screen, for Merge Type, select Full Repository Merge.
Click Select next to Original Master Repository, then click Repository. Then, browse to select your blank repository file as the original repository and click Open. Leave the password field blank.
Select the destination repository by clicking Select next to the Modified Repository field. Select Repository from the submenu to select a binary repository file in RPD format, or select XML to select a set of MDS XML documents.
For binary repositories, browse to select the modified repository, and then click Open. For MDS XML format repositories, use the Browse For Folder dialog to select the root folder location of the MDS XML documents, and then click OK.
This is the repository into which you want to import objects.
Provide a password for the modified repository in the appropriate Password field.
Optionally, you can change the default name and location of the saved (merged) repository by clicking Select next to the Save Merged Repository as field. Select Repository from the submenu to save the merged repository as a binary repository file in RPD format, or select XML to save the merged repository as a set of MDS XML documents.
For binary repositories, provide a new name and location, and then click Save. For MDS XML format repositories, use the Browse For Folder dialog to select the root folder location of the MDS XML documents, and then click OK.
Click Next. If there are any conflicts, the Define Merge Strategy screen of the Merge Repository Wizard appears. If there are no conflicts, the Merge Wizard continues with the merge process and then closes automatically when finished.
The Define Merge Strategy screen displays a decision table that shows conflicts for this merge. To make decisions about whether to include or exclude objects from the merged repository, choose Current or Modified from the Decision list. When you select an object in the decision table, the read-only text box below the decision table describes what changes were made to that object in the current repository.
Refer to Figure 17-6 to see the Define Merge Strategy screen. Refer to Table 17-4 for information about additional options in the Define Merge Strategy screen, such as saving merge decisions to a comma-separated values (.csv) file.
After you make a merge decision, the row for that decision in the table changes from red to black. When all rows have a value in the Decision field, the Finish button is enabled.
Click Finish.
Oracle Business Intelligence provides the capability of generating an XML patch file that contains only the changes made to a repository. This patch can be then applied to the old (original) version of the repository to create the new version. This is very useful for development-to-production scenarios, and can also be used for Oracle BI Applications customers to upgrade their repository.
This section explains how to generate a patch that contains the differences between two repositories, and then apply the patch to a repository file.
This section contains the following topics:
In a patch merge, you create a patch that contains the differences between the current repository and the original repository. Then, you apply the patch file to the modified repository.
In a development-to-production scenario, you have an original parent repository, a current repository that contains the latest development changes, and a modified repository that is the deployed copy of the original repository.
To generate a patch, you open the current repository and select the original repository, then create the patch.
Figure 17-7 shows how to create a patch in a development-to-production scenario. The example shown in Figure 17-7 assumes you are creating a patch for binary (RPD) repositories, but you can also create a patch for MDS XML repositories.
Figure 17-7 Development-to-Production: Creating the Patch
To apply the patch, you open the modified repository and select the original repository, then apply the patch.
Figure 17-8 shows how to apply a patch in a development-to-production scenario. The example shown in Figure 17-8 assumes you are applying a patch to a binary (RPD) repository, but you can also apply a patch to an MDS XML repository.
Figure 17-8 Development-to-Production: Applying the Patch
In an Oracle BI Applications repository upgrade scenario, the current repository is the latest version of the repository shipped by Oracle, and the original repository is the original repository shipped by Oracle. The modified repository is the one that contains the customizations you made to the original repository.
To generate a patch, you open the current repository and select the original repository, then create the patch.
Figure 17-9 shows how to create a patch in an Oracle BI Applications repository upgrade scenario. The example shown in Figure 17-9 assumes you are creating a patch for binary (RPD) repositories, but you can also create a patch for MDS XML repositories.
Figure 17-9 Oracle BI Applications Repository Upgrade: Creating the Patch
To apply the patch, you open the modified repository and select the original repository, then apply the patch.
Figure 17-10 shows how to apply a patch in an Oracle BI Applications repository upgrade scenario. The example shown in Figure 17-10 assumes you are applying a patch to a binary (RPD) repository, but you can also apply a patch to an MDS XML repository.
Figure 17-10 Oracle BI Applications Repository Upgrade: Applying the Patch
Use the Administration Tool to generate a patch that contains the differences between two repositories.
To generate a patch using the Administration Tool:
In the Administration Tool, open the current Oracle BI repository in offline mode. In other words, open the updated repository that contains the changes you want to put in the patch.
Select File, then select Compare.
Select the original Oracle BI repository. Select Repository from the submenu to select a binary repository file in RPD format, or select XML to select a set of MDS XML documents.
In the Open Offline dialog, enter the repository password and click OK.
It is a good practice to equalize your changes to clean up underlying object IDs before generating a patch. See "Equalizing Objects" for more information.
In the Compare repositories dialog, review the changes between the repositories. Then, click Create Patch.
In the Create Patch dialog, enter a name for the patch file (for example, my_patch.xml) and click Save.
Note that if the patch contains passwords, such as connection pool passwords, the patch file is encrypted using the repository password from the current repository. The current repository password effectively becomes the patch file password. You might need to supply this patch file password when applying the patch, if it is different from the repository password for the original repository.
You can also generate a patch at the command line using the comparerpd utility. See "Comparing Repositories Using comparerpd" for more information.
Use the Administration Tool to apply a patch that contains the differences between two repositories.
Note that you can apply patches from a larger multiuser repository to a smaller subset extract repository. In this case, only the changes in the subset are applied from the patch.
To apply a patch:
In the Administration Tool, open the modified Oracle BI repository in offline mode. In other words, open the repository on which you want to apply the patch.
Select File, then select Merge. The Merge Repository Wizard appears.
For Merge Type, select Patch Repository Merge.
Select the original parent repository by clicking Select next to Original Master Repository. Select Repository from the submenu to select a binary repository file in RPD format, or select XML to select a set of MDS XML documents.
For binary repositories, browse to select the original repository, and then click Open. For MDS XML format repositories, use the Browse For Folder dialog to select the root folder location of the MDS XML documents, and then click OK.
Note that the original repository cannot be the same as the modified (currently open) repository.
Enter the repository password for the original repository.
Click Select next to Patch File. Browse to select the patch file you want to apply, then click Open. The patch file must be in XML format.
In most cases, you can leave the Patch Password field blank. You only need to supply the patch file password when the patch file contains passwords for objects, such as connection pool passwords, and when the patch file password is different from the original repository password. The patch file password is the same as the password for the current repository.
Optionally, you can change the default name and location of the saved (patched) repository by clicking Select next to the Save Merged Repository as field. Select Repository from the submenu to save the merged repository as a binary repository file in RPD format, or select XML to save the merged repository as a set of MDS XML documents.
For binary repositories, provide a new name and location, and then click Save. For MDS XML format repositories, use the Browse For Folder dialog to select the root folder location of the MDS XML documents, and then click OK.
Click Finish.
You can also apply a patch using the patchrpd utility. This feature is especially useful when you want to patch repositories on Linux and UNIX systems where the Administration Tool is not available. The patchrpd utility is available on both Windows and UNIX systems. However, patchrpd can only be used with binary repositories in RPD format.
Note that unlike the Administration Tool patch feature, patchrpd provides an option to apply default decisions for conflicts automatically. It also provides the capability to save all conflicts to a decision file so that you can examine the results and determine whether additional manual changes are needed. See "Using Patchrpd to Automate the Patch Process" for more information.
Patchrpd also provides the ability to select the set of merge rules to apply. By default, the merge rules for patches are used, but you can optionally select to use the full (upgrade) merge rules or the multiuser development merge rules.
Before running patchrpd, you must first run bi-init to launch a command prompt or shell window that is initialized to your Oracle instance. See "Running bi-init to Launch a Shell Window Initialized to Your Oracle Instance" for more information.
Syntax
The patchrpd utility takes the following parameters:
patchrpd [-P modified_rpd_password] -C modified_rpd_pathname [-Q original_rpd_password] -G original_rpd_pathname [-S patch_file_password] -I patch_file_pathname [-S patch_file_2_password -I patch_file_2_pathname ...] [-D input_decision_file_pathname] -O output_rpd_pathname [-V output_decision_file_pathname] [-E] [-M mode] [-R] [-A] [-U] [-8]
Where:
-P modified_rpd_password is the repository password for the modified repository, also called the customer or customized repository.
-C modified_rpd_pathname is the name and location of the modified repository.
-Q original_rpd_password is the repository password for the original repository.
-G original_rpd_pathname is the name and location of the original repository.
-S patch_file_password is the password for the patch file. The patch file password is the same as the password for the current repository. You only need to supply the patch file password when the patch file contains passwords for objects, such as connection pool passwords, and when the patch file password is different from the original repository password.
-I patch_file_pathname is the name and location of the XML patch file you want to apply. You can apply multiple patches by including multiple -I arguments (with paired -S arguments as needed).
-D input_decision_file_pathname is the name and location of a decision file in CSV format that you want to use to affect the behavior of this patch merge. This argument is optional.
-O output_rpd_pathname is the name and location of the RPD output file you want to generate.
-V output_decision_file_pathname is an optional argument that lets you generate a CSV format decision file. The decision file shows all the conflicts from the merge. In other words, the decision file lists the decisions that would have been displayed in the Define Merge Strategy screen of the Merge Wizard in the Administration Tool. The decision file provides a record of all items that could be influenced by user input. This argument must be used in conjunction with the -U argument.
-E is an optional argument that enables you to skip the equalize step.
-M mode is an optional argument that enables you to change the mode of the merge. By default, patchrpd runs in patch mode, in which as many changes as possible are applied silently. For mode, specify "mud" to use merge rules for multiuser development merges, or "upgrade" to use merge rules for full merges. See Appendix D, "Merge Rules" for information about the rules for different types of merges.
-R is an optional argument that skips consistency checking for logical columns. This option can speed up the patch process when the patch file does not contain logical to physical column mappings.
-A is an optional argument that can be used in multiuser development environments to skip subset patching and instead apply the patch using input repository files.
-U is an optional argument that applies default decisions for conflicts automatically so that patchrpd can finish successfully. If you do not include this parameter, patchrpd displays a warning and exits if a conflict is detected.
-8 specifies UTF-8 encoding.
Note:
The arguments for all passwords, including the modified_rpd_password, original_rpd_password, and patch_file_password, are optional. If you do not provide password arguments, you are prompted to enter any required passwords when you run the command. To minimize the risk of security breaches, Oracle recommends that you do not provide password arguments either on the command line or in scripts. Note that the password arguments are supported for backward compatibility only, and will be removed in a future release.
For example:
patchrpd -C customer.rpd -G original.rpd -I patch.xml -O patched.rpd -V decision.csv -U Give password for customer repository: my_modified_rpd_password Give password for original repository: my_original_rpd_password
This example applies a patch called patch.xml to the customer.rpd repository, and then generates an output repository called patched.rpd and an output decision file called decision.csv.
Note:
Be sure to provide the full pathnames to all files, including the repository files and the XML patch file, if they are located in a different directory.
You can use repository queries to help manage repository metadata in the following ways:
Examine and update the internal structure of the repository. For example, you can query for objects in the repository based on name, type (such as Logical Column or Presentation Hierarchy), or on a combination of name and type. You can then edit or delete objects that appear in the Results list. You can also create new objects and view parent hierarchies.
Query a repository and view reports that show such items as all tables mapped to a logical source, all references to a particular physical column, content filters for logical sources, initialization blocks, and security and user permissions.
For example, you might want to run a report before making any physical changes in a database that might affect the repository. You can save the report to a file in comma-separated value (CSV) or tab-delimited format.
You can save a query to run again later, or save the query results to an external file. When you save to an external file, the encoding options are ANSI, Unicode, and UTF-8.
This section contains the following topics:
You can query for objects in the repository using the Query Repository tool. You can also construct a filter to filter the results, save a query, run a previously saved query, or create new repository objects.
To query a repository:
In the Administration Tool, open your repository.
Select Tools, then select Query Repository.
In the Query Repository dialog, complete the query information using Table 17-5 as a guide.
Click Query.
Table 17-5 lists the options available in the Query Repository dialog.
Table 17-5 Query Repository Options
| Option | Description |
|---|---|
|
Name |
Use this option to search by object name. You can use an asterisk ( * ) wildcard character to specify any characters. The wildcard character can represent the first or last characters in the search string. Searches are not case sensitive. |
|
Type |
Select a type from the list to narrow your search to a particular type of object, or select All Types to query all objects. The list does not contain objects such as aggregate rules, logical source folders, privilege packages, and other objects that are considered internal objects. |
|
Filter |
Click Filter to create or edit a filter for your query. After you create a filter, the filter criteria appear in the box to the left of the button. See "Constructing a Filter for Query Results" for more information. |
|
Query |
Click Query when you are ready to submit your query. |
|
Save Query As |
Click Save Query As to save your query to run again later. Enter the name of the saved query in the Save query as field, then click Save. |
|
Saved Queries |
Click Saved Queries to view or run previously saved queries. You can also delete saved queries. To run a previously saved query, select the row that contains the query you want to run and click Select, or double-click the row. The Saved Queries option is only available if you have previously saved queries. |
|
Edit |
After executing a query, select an object from the Results list and click Edit to edit an object in the list of query results. Not all repository objects can be edited from the results list (for example, privilege objects and user database sign-on objects). If an object cannot be edited from the results list, Edit is not available. |
|
Delete |
After executing a query, select one or more objects in the Results list and click Delete to delete the objects. After you confirm the deletion, the objects are deleted from your metadata repository. |
|
New |
Use this option to create new repository objects. First, select the type of object you want to create from the Type list, then click New. This option is not available when All Types is selected. The dialogs that appear depend on the object type that you select. For more information, refer to the sections that describe how to create that object. Note that if you choose to create a new logical dimension, you must choose whether to create a dimension with a level-based hierarchy, or a parent-child-hierarchy. Similarly, if you choose to create a new Oracle OLAP hierarchy, you must select whether you want to create a level-based or value-based hierarchy. |
|
Show Parent |
After executing a query, select an object in the Results list and click Show Parent to view the parent hierarchy of an object. If the object does not have a parent, a message appears. You cannot use Show Parent with users or application roles. In the Parent Hierarchy dialog, you can edit or delete objects. Note that if you delete an object from this dialog, any child objects of the selected object are also deleted. |
|
Mark |
After executing a query, select one or more objects in the Results list and click Mark to mark the selected objects. To unmark the objects, select them and click Mark again. Marking objects makes them easier to visually identify as you develop metadata. |
|
Set Icon |
After executing a query, select one or more objects in the Results list and click Set Icon to select a different icon for the objects. You can set special icons for objects to help visually identify them as having common characteristics. For example, you might want to pick a special icon to identify columns that will be used only by a certain user group. To change the icons back to the original icons, select the objects and click Set Icon again. Then, select Remove associated icon and click OK. |
|
GoTo |
After executing a query, select one or more objects in the Results list and click GoTo to go to the objects in the Administration Tool view of the repository. The selected objects appear highlighted in the Physical, Business Model and Mapping, or Presentation layer. Note that the Query Repository dialog closes when you choose this option. |
|
Save |
After executing a query, click Save to save query results to an external file. Then, in the Save As dialog, provide a name, file type, and encoding value for the file, then click Save. |
|
Columns |
Click Columns to add additional columns of information to the results. Then, select the columns you want from the list and click OK. Note that in the Select Columns dialog, you can re-order the columns by selecting a checked column and clicking Up or Down. Select Show Upgrade ID in Query Repository in the General tab of the Options dialog to enable Upgrade ID as a results column. See "Setting Administration Tool Options" for more information. |
|
Show Qualified Name |
Use this option to display the fully qualified name of the objects found by the query. For example, if you query for logical columns, the default value in the Name column of the Results list is the column name. However, if you select Show Qualified Names, the value in the Name list changes to |
Use the Query Repository Filter dialog to filter the results in the Results list of the Query Repository dialog.
The Query Repository Filter dialog contains five columns: an Item column and its operator or selection column, a Value column and its operator or selection column, and a Delete column that lets you delete the selected filter.
To construct a filter:
In the Administration Tool, select Tools, then select Query Repository.
In the Query Repository dialog, select an item in the Results list or select an item from the Type list, and then click Filter.
In the Query Repository Filter dialog, click the Item field. The Item list contains the items by which you can filter.
Select Show Upgrade ID in Query Repository in the General tab of the Options dialog to enable filtering by Upgrade ID. See "Setting Administration Tool Options" for more information.
In the Item list, select the filter that you want to apply to the Results or Type object you selected in Step 2. Then, adjust or enter information in the Value column, as appropriate.
You can construct multiple filters. When you do, the Operator field becomes active. When the Operator field is active, you can set AND and OR conditions.
Click OK to return to the Query Repository dialog. The filter appears in the box to the left of the Filter button.
Note:
If you are constructing a complex filter, you might want to click OK after adding each constraint to verify that the filter construction is valid for each constraint.
Example 17-1 and Example 17-2 show how to create different kinds of filters.
Example 17-1 Viewing All Databases Referenced In a Business Model
The following example shows how to create a filter that lets you view all databases referenced in a particular business model.
In the Query Repository dialog, select Database from the Type list, and then click Filter.
In the Query Repository Filter dialog, click the Item field, and then select Related to.
Click the ellipsis button to the right of the Value field, and in the list, choose Select object.
In the Select dialog, select the business model by which you want to filter, and then click Select. Your selection appears in the Value field.
Click OK to return to the Query Repository dialog. The filter appears in the box to the left of the Filter button.
Click Query. The Results list shows the databases referenced by the business model you selected.
Example 17-2 Viewing All Presentation Columns Mapped to a Logical Column
The following example shows how to create a filter that lets you view all presentation columns mapped to a particular logical column.
In the Query Repository dialog, select Presentation Column from the Type list, and then click Filter.
In the Query Repository Filter dialog, click the Item field, and then select Column.
Click the ellipsis button to the right of the Value field, and in the list, choose Select object.
In the Select dialog, select the column by which you want to filter, and then click Select. Your selection appears in the Value field.
Click OK to return to the Query Repository dialog. The filter appears in the box to the left of the Filter button.
Click Query. The Results list shows the presentation columns mapped to the logical column you selected.
Example 17-3 Nested Queries
The following example shows nested queries, where the filter itself is another query.
In the Query Repository dialog, select Logical Column from the Type list, and then click Filter.
In the Query Repository Filter dialog, click the Item field, and then select Related to.
Click the ellipsis button to the right of the Value field, and in the list, choose Set Condition for Physical Column.
In the new Query Repository Filter dialog, click the Item field, and then select Source column.
Click the ellipsis button to the right of the Value field, and in the list, choose Select Object.
In the Browse dialog, select a source physical column (for example, Column A) and click Select.
Click OK in the Query Repository Filter dialog for the subquery condition. This subquery queries all aliases for the source column you selected.
In the Query Repository Filter dialog for the main query, click the Item field in the next row and then select Related to.
Click the ellipsis button to the right of the Value field, and in the list, choose Select Object.
In the Browse dialog, select the same source physical column (for example, Column A) and click Select.
Select OR from the Operator list.
Click OK to return to the Query Repository dialog. The filter appears in the box to the left of the Filter button.
Click Query. The Results list shows a list of logical columns related to either Column A, or aliases of Column A.
The Query Related Objects feature enables you to query objects related to one or more objects that you select from the Physical, Business Model and Mapping, or Presentation layer.
You can only use this feature with objects selected from the same layer. For example, you cannot query objects related to both a Physical layer object and a Business Model and Mapping layer object.
To query objects related to a selected object:
In the Administration Tool, open your repository.
Select one or more objects from a single layer (for example, a set of logical columns from the Business Model and Mapping layer). The objects you select must all be of the same type.
Right-click the objects and select Query Related Objects.
From the right-click submenu, select an object type to narrow your search to a particular type of object, or select All Types to query all objects related to your source objects. If you have previously made queries for this source object type, the three most recent queries are available at the top of the submenu.
After you select an object type, the Query Related Objects dialog is displayed, showing the objects related to your source objects in the Name list.
Table 17-6 lists the options available in the Query Repository dialog.
Table 17-6 Query Related Objects Options
| Option | Description |
|---|---|
|
Mark |
Select one or more objects in the Name list and click Mark to mark the selected objects. To unmark the objects, select them and click Mark again. Marking objects makes them easier to visually identify as you develop metadata. |
|
Set Icon |
Select one or more objects in the Name list and click Set Icon to select a different icon for the objects. You can set special icons for objects to help visually identify them as having common characteristics. For example, you might want to pick a special icon to identify columns that will be used only by a certain user group. To change the icons back to the original icons, select the objects and click Set Icon again. Then, select Remove associated icon and click OK. |
|
Show Qualified Name |
Use this option to display the fully qualified name of the objects found by the query. For example, if you query for logical columns, the default value in the Name list is the column name. However, if you select Show Qualified Names, the value in the Name list changes to |
|
Show Parent |
Select an object in the Name list and click Show Parent to view the parent hierarchy of an object. If the object does not have a parent, a message appears. You cannot use Show Parent with users or application roles. In the Parent Hierarchy dialog, you can edit or delete objects. Note that if you delete an object from this dialog, any child objects of the selected object are also deleted. |
|
GoTo |
Select one or more objects in the Name list and click GoTo to go to the objects in the Administration Tool view of the repository. The selected objects appear highlighted in the Physical, Business Model and Mapping, or Presentation layer. Note that the Query Related Objects dialog closes when you choose this option. |
Each repository has a password that is used to encrypt its contents. You create the repository password when you create a new repository file, or when you upgrade a repository from a previous release of Oracle Business Intelligence.
You can change the repository password using the Administration Tool in offline mode. You cannot change the repository password when the repository is open in online mode.
After you change the repository password in the Administration Tool, you must also publish the updated repository and specify the new password in Fusion Middleware Control. Specifying the repository password in Fusion Middleware Control enables the password to be stored in an external credential store, so that the Oracle BI Server can retrieve it to load the repository.
Note:
If you are using the SampleAppLite.rpd sample repository, you must change the default password the first time you open it in the Administration Tool, for security reasons. See "About the SampleApp.rpd Demonstration Repository" for more information about the sample repository.
To change the repository password in the Administration Tool and Fusion Middleware Control:
Open the repository in the Administration Tool in offline mode.
Select File, then select Change Password.
Enter the current (old) password.
Enter the new password and confirm it. The repository password must be longer than five characters and cannot be empty.
Click OK.
Save and close the repository.
Open a Web browser and log in to Fusion Middleware Control from the computer where the updated repository is located.
In the navigation tree, expand Business Intelligence and then click coreapplication to display the Business Intelligence Overview page.
Display the Repository tab of the Deployment page.
Click Lock and Edit Configuration.
Click Browse next to Repository File. Then, select the updated repository file and click Open.
Enter the new (updated) repository password in the Repository Password and the Confirm Password fields.
Make sure to specify the password that has been set in the repository. If the passwords do not match, the Oracle BI Server fails to start, and an error is logged in nqserver.log.
Click Apply, then click Activate Changes.
Return to the Business Intelligence Overview page and click Restart.
See "Configuring Repositories" in Oracle Fusion Middleware System Administrator's Guide for Oracle Business Intelligence Enterprise Edition for more information about the repository options in Fusion Middleware Control.
|
 Copyright © 2010, 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
