Merging Repositories

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 .

See Merge Rules to learn how repository objects are merged.

This section contains the following topics:

Performing Full Repository Merges

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:

About Full Repository Merges

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.

Description of the illustration GUID-31797096-B7D2-4484-9140-50DB0D7A9DE2-default.gif
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.

Description of the illustration GUID-FCB144EA-EC34-4452-9EBF-601155FFC69F-default.gif

Performing Full Repository Merges With a Common Parent

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.

See Equalizing Objects.

In the Administration Tool, open the current repository in offline mode.
From the Administration Tool menu, select File, then select Merge.

The image shows the Merge Repository Wizard.

Description of the illustration GUID-B469C334-4F58-4EB5-87D5-CC2A00E6CB8C-default.gif
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.
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.
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. 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.
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. The table below describes the Define Merge Strategies.
Click Finish.

The table lists and describes the elements in the Define Merge Strategies screen.

Element	Description
Conflicts table	The Conflicts table includes the following columns: Type: The type of object for which there is a conflict (for example, Presentation Column). Name: The name of the object for which there is a conflict. Description: The reason for the conflict, such as Added to Current. See the previous step for a description of different conflict types. Decision: Select the decision according to what change you want to keep in the merged repository, such as Current, Modified (A), Modified (D), or By Property. See the previous step for a description of the results of different decisions. 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: Property: The name of the property that has been modified in each repository. Original: The value of the property in the original repository. Modified: The value of the property in the modified repository. Select this option to keep this value. Current: The value of the property in the current repository. Select this option to keep this value. Merge Choices: For some properties, like aliases, you can choose this option to merge the property values rather than choose one or the other.
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 `patchrpd`.
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 `patchrpd`. See Using patchrpd to Apply a Patch.
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.

Performing Full Repository Merges Without a Common Parent

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 to learn which objects are retained or discarded during the merge process.

In the Administration Tool, select File, then select New Repository to serve as the original repository in the merge.
In the Create New Repository Wizard, provide a name for the repository, for example,blank.rpd.
In 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, that is the repository that contains the objects you want to import, in offline mode.
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.
Navigate to your blank repository file and click Open and leave the password field blank.
Next to the Modified Repository field, click Select to choose the destination repository.
1. 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.
2. For binary repositories, browse to select the modified repository, and then click Open.
3. 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 a password for the modified repository in the appropriate Password field.
Click Next.

If there are any conflicts, the Merge Repository Wizard’s Define Merge Strategy displays a message.
In Define Merge Strategy, 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.
Click Finish.

Performing Patch Merges

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:

About Patch Merges

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.

Generating a Repository Patch

Use the Oracle BI Administration Tool to generate a patch that contains the differences between two repositories.

See Equalizing Objects.

In the Administration Tool, open the current Oracle BI EE repository in offline mode. In other words, open the updated repository that contains the changes you want to put in the patch.

Note:

In the case that changes are made using projects, metadata changes must be added to an existing project. Changes made to a new project will be lost during the patch merge process.
Select File, then select Compare.
Select the original Oracle BI EE 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.
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.

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.

Applying a Repository Patch

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.

In the Administration Tool, open the Oracle BI repository in offline mode to apply the patch.
Select File, then select Merge. The Merge Repository Wizard appears.
For Merge Type, select Patch Repository Merge. When you select this option, the Partial Subset Merge field displays. By default, this field is selected and the patch is applied as a partial subset merge. Clear this option if you want the patch applied to the whole repository.
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:

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.

Using patchrpd to Apply a Patch

You can apply a patch using the patchrpd utility.

Use patchrpd 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. You can only run patchrpd 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.

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.

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. 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 path names to all files, including the repository files and the XML patch file, if they are located in a different directory.