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.
By default, the patchrpd
utility's merge functionality uses patch mode. If you want to set up the Merge Repository Wizard to match the patchrpd
utility's default merge functionality, then you must set up the Merge Repository Wizard to run in "patch" mode.
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 Merge Rules for additional information about how repository objects are merged.
This section contains the following topics:
You can use the Oracle BI 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 the figure below assumes you are merging binary (RPD) repositories, but you can also perform this type of merge with MDS XML 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. This functionality replaces the Import from Repository feature that was deprecated in an earlier release.
The example shown in the image below assumes you are merging binary (RPD) repositories, but you can also perform this type of merge with MDS XML repositories.
Learn how to use the Oracle BI 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 Business Intelligence repository with a common parent:
The table lists and describes the 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. |
Set Default Decisions |
When clicked, allows you to choose how the Administration Tool resolves conflicts. Use this option when you do not want to set each conflict's decision manually. Select All if you want the Administration Tool to resolve all unresolved and resolved conflicts, that is conflicts for which you have already specified decisions. If you choose this option, then the Administration Tool checks the conflict decisions that you have already specified and changes them if necessary. Select Only undecided if you want the Administration Tool to resolve only the unresolved conflicts. That is, to assign decisions to all conflicts for which you have not specified decisions. When you select this option, the Administration Tool preserves the conflict decisions that you have already specified. |
Check consistency of the merged RPD |
When selected, runs a consistency check before saving the merged file. |
Hide object views |
Select this option to hide the tree panels in the dialog. The tree panels show the affected objects for the row selected in the conflicts decision table. Hiding the tree panels can improve the performance of the Define Merge Strategies screen. |
Save Decisions to 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 |
Load Decision File |
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 |
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. |
Learn how to use the Oracle BI 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 Merge Rules for more information about which objects are retained or discarded during the merge process.
To merge two versions of an Oracle BI EE 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:
In the Administration Tool, select File, then select New Repository. The Create New Repository Wizard appears.
Provide a name for the repository, for example,blank.rpd
.
For Import Metadata, choose No.
Enter and confirm the repository password you want to use for this repository.
Click Finish.
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.
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 the table 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.
You can use the patch merge to generate 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 merge method 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.
You apply the patch file to the modified repository. Differences between the current and original repository must exist in matching existing projects in both repositories.
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.
To apply the patch, you open the modified repository and select the original repository, then apply 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 changes you made to the original repository.
To generate a patch, you open the current repository and select the original repository, then create the patch.
To apply the patch, you open the modified repository and select the original repository, then apply the patch.
Use the Oracle BI Administration Tool to generate a patch that contains the differences between two repositories.
To generate a patch using the Administration Tool:
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 Oracle BI Administration Tool to apply a patch that contains the differences between two repositories.
Note:
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:
You can 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.
The location of the patchrpd
utility is:
BI_DOMAIN/bitools/bin
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] [-N] [-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. To change this default, then for mode specify "mud" to use merge rules for multiuser development merges, or "upgrade" to use merge rules for full merges. See Merge Rules for information about the rules for different types of merges.
By default, the Administration Tool's merge functionality uses full merge. If you want to run the patchrpd
utility to match the Administration Tool's default merge functionality, then you must specify "upgrade" in the -M
mode
argument.
-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.
-N
is an optional argument that is used to ignore all non-fatal errors. Examples of non-fatal errors are unresolved objects, duplicated objects, and broken or incorrect expressions.
-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 scripting purposes, you can pass the password through standard input.
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.