| 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 appendix provides information about the merge rules and behavior of the Oracle BI repository merge process.
When you use the Merge Repository Wizard in the Oracle BI Administration Tool, the patchrpd utility, or publish changes to the network in a multiuser development environment, sophisticated rules determine how objects are merged. Some decisions about merging objects are made automatically by the system, while other decisions appear as prompts in the Define Merge Strategy screen.
This appendix contains the following topics:
There are three types of Oracle BI repository merges:
Full merges (sometimes called upgrade 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. See "Performing Full Repository Merges" for more information.
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. See "Performing Patch Merges" for more information.
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.
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 file (the parent repository), while the modified and current repository are the two changed files you want to merge. The current repository is the one currently open in the Administration Tool.
The original, modified, and current repository may mean different things, depending on your situation. For example:
In a development-to-production scenario, you have an original parent file, a current file that contains the latest development changes, and a modified file that is the deployed copy of the original file.
In an Oracle BI Applications repository upgrade scenario, the current file is the latest version of the repository shipped by Oracle, and the original file is the original repository shipped by Oracle. The modified file is the file that contains the customizations you made to the original file.
Note that patch merge can be used with both of these situations. In a patch merge, you open the current file and select the original file, then generate the patch. To apply the patch, you open the modified file and select the original file, then apply the patch. See "Performing Patch Merges" for more information.
For full merges, the following general rules are applied:
It is assumed that you generally want to keep the changes in the modified repository. For example, if an object is added to or deleted from the modified repository, the object is added or deleted without prompting.
If an object is added to or deleted from the current repository, the Merge Repository Wizard asks whether you want to keep the changes.
In general, the Merge Repository Wizard tries to ensure that you have the minimum set of objects necessary to service your queries. During a merge, there might be objects introduced by the current repository that are not needed in the merged repository. To address this issue, the Merge Repository Wizard asks whether new Presentation layer objects in the current repository are needed in the final merged result. If you choose to keep the new presentation objects, all the dependent logical and physical objects are added as well. However, if you choose not to keep the new presentation objects, then the dependent logical and physical objects are not kept, because no queries will require the use of these objects. The Merge Repository Wizard discards these objects to ensure that the merged repository does not get populated with unused objects.
If an object is added to or deleted from both repositories, the object is added or deleted without prompting. If the same object was added with slight differences in its properties, the Merge Repository Wizard asks which version of the properties you want to keep.
If an object has been modified only in the current repository, or only in the modified repository, the change is kept. If the same object is modified in both the current and modified repository, and the changes are different, then there is a merge conflict. When conflicts occur, the Merge Repository Wizard asks you to choose which change you want to keep.
Making a decision about one object can determine a whole set of decisions, depending on the object relationships involved. For example, if you choose to keep a presentation column that has been added to the current repository, then the associated presentation table and subject area must also be kept, along with the logical column, physical column, and other associated objects upon which it is based. Alternatively, if you choose not to keep a subject area that has been added to the current repository, then you are not prompted to choose whether to keep its associated objects. Adding a join may require the addition of its base tables, while changing an expression may cause physical columns to be added.
Object relationships can be interconnected through their properties. In addition to strings and numbers, the internal value of a property can be other repository objects. Because of this, a change to one object might cause a corresponding change to an interrelated object.
For example, assume you change the data source of Init Block B from a connection pool to Custom Authenticator A. In addition to the data source property change to the initialization block object, a corresponding property change occurs in the custom authenticator object (because the value of the initialization block property for Custom Authenticator A is now Init Block B).
Because the decisions made for these properties must be synchronized, if you select Current as the decision for the data source property of Init Block B, then the decision for the initialization block property of Custom Authenticator A will also be Current. See Figure D-1 shows what this example looks like in the Merge Repository Wizard.
In the Merge Repository Wizard, any decisions that require user input are displayed on the Define Merge Strategy screen. Figure D-1 shows the Define Merge Strategy screen.
In addition to the general rules governing how objects are merged and which situations require prompting, there are special rules for certain types of objects and situations.
This section contains the following topics:
Some objects, such as levels, application roles, and object permissions, use a vector merge algorithm that determines the parent/child relationships between objects.
Objects that use the vector merge algorithm include:
Levels in a dimension, levels associated with a logical column, and child levels
Dimensions and tables in a logical display folder
Aggregation content in a logical table source
Security objects like user and application role membership and permissions
Initialization block LDAP server settings and execution precedence
The Oracle BI Server determines the initial state of object relationships in each repository during the merge process. For example, the following list shows the different possibilities for object permissions and how they relate to users and application roles:
M - Missing. The application role, user, or object is not present in the repository.
D - Default. Permissions are inherited from the parent application role.
Y - Yes. The permission is explicitly granted to the user or application role.
N - No. The permission is explicitly denied to the user or application role.
The Merge Repository Wizard determines the appropriate relationship for the merged repository depending on the state of the object permission relationships in each repository. For example:
For an original repository with a result of Y, a modified repository with a result of N, and a current repository with a result of M, the Merge Repository Wizard determines a result of N for the merged repository.
For an original repository with a result of N, a modified repository with a result of Y, and a current repository with a result of M, the Merge Repository Wizard determines a result of Y for the merged repository.
Example D-1 provides a detailed explanation of how object relationships are merged for application role objects.
Example D-1 Vector Merge Example: Merging Application Roles
The following list shows the different possibilities for user and application role relationships:
M - Missing. The application role or user is not present in the repository.
Y - Yes. The application role or user is a member of the application role.
N - No. The application role or user is not a member of the application role.
Table D-1 shows the merged result for different combinations of object relationships in the merging repositories.
Table D-1 Results for Merging Application Roles Based on Object Relationships
| Original Repository | Modified Repository | Current Repository | Result |
|---|---|---|---|
|
M |
M |
M |
|
|
M |
M |
Y |
Y |
|
M |
M |
N |
N |
|
M |
Y |
M |
Y |
|
M |
Y |
Y |
ImpossibleFoot 2 |
|
M |
Y |
N |
Impossible |
|
M |
N |
M |
N |
|
M |
N |
Y |
Impossible |
|
M |
N |
N |
Impossible |
|
Y |
M |
M |
Y |
|
Y |
M |
Y |
Y |
|
Y |
M |
N |
N |
|
Y |
Y |
M |
Y |
|
Y |
Y |
Y |
Y |
|
Y |
Y |
N |
N |
|
Y |
N |
M |
N |
|
Y |
N |
Y |
N |
|
Y |
N |
N |
N |
|
N |
M |
M |
N |
|
N |
M |
Y |
Y |
|
N |
M |
N |
N |
|
N |
Y |
M |
Y |
|
N |
Y |
Y |
Y |
|
N |
Y |
N |
Y |
|
N |
N |
M |
N |
|
N |
N |
Y |
Y |
|
N |
N |
N |
N |
Footnote 1 This situation can happen if neither the application role nor the user are present in the original repository, but the user is present in the modified repository and the application role is present in the current repository. In this case, no membership can be assumed.
Footnote 2 M in original implies that either the user or application role is not present. The missing object added in both cannot be considered the same object.
Special rules govern how to merge column mappings in logical table source objects. Each column mapping is merged individually. For each column, if the mapping has changed in either the modified or current repository, the change is kept. If the mapping has changed in both repositories, the Oracle BI Server attempts to merge the mappings automatically.
Note that the deletion of a column is not considered to be a change in its mapping. If a column is not present in the modified repository, then the mapping in the current repository is used instead.
If there are differences in aggregation content, then the aggregation content specified by level has priority. In other words, if the aggregation content in one repository is by level and the aggregation content in another repository is by column, then the aggregation content by level is retained.
If a filter for an application role has changed in only one repository, then the change is kept. If the filter has changed in both repositories, the Oracle BI Server attempts to merge the filters automatically.
If an object is required for merging a particular filter (such as a presentation column) and is not present, then that filter is considered invalid and does not appear in the merged repository. Note, however, that this rule does not apply to variables. If a variable is required for merging a particular filter, the Oracle BI Server ensures that the variable is retained in the merged repository.
Presentation columns have both a Name property and a Use Logical Column Name property. In some cases, these properties can come into conflict. For example, Table D-2 shows a scenario where this situation could occur.
Table D-2 Conflicting Presentation Column Name and Use Logical Column Name Properties
| Repository | Presentation Column Name | Logical Column Name | Use Logical Column Name |
|---|---|---|---|
|
Original |
Sales |
GroupSales |
No |
|
Current |
Sales |
Sales |
Yes |
|
Modified |
GroupSales |
GroupSales |
Yes |
If the regular merge rules for the objects in Table D-2 are applied, the merged repository contains a presentation column called GroupSales and a logical column called Sales, with the Use Logical Column Name property set to Yes. However, this result is incorrect, because the name of the presentation column is different from the name of the logical column.
To avoid this situation, the Oracle BI Server infers the value of the Use Logical Column Name property. Using this logic, the merged repository for the example in Table D-2 has a presentation column called GroupSales, a logical column called Sales, and a Use Logical Column Name property set to No.
During the full merge process, users are not prompted to make decisions about aliases. Aliases from the current and modified repositories are merged automatically.
In multiuser development merges, however, users are prompted to choose whether to keep aliases from the current repository, keep aliases from the modified repository, or merge choices to keep aliases from both repositories.
Also note the following:
If object names change because of the merge process, then the previous names are added as aliases.
Any aliases that are not associated with presentation objects are deleted.
The rules for multiuser development merges are very similar to the full merge rules, with the following important differences:
Changes to security settings are not retained when you perform a MUD merge to prevent developers from overwriting passwords and other important objects in the master repository.
The database and connection pool properties in the master repository take precedence over the same properties on the developer's computer. This precedence are applied without a prompt during a multiuser development merge.
Inserts (created objects) are applied automatically. Because a subset of the master repository is being used as the original repository, most objects in the master repository appear to be new. This would result in many unnecessary prompts that the developer would have to manually approve. Therefore, new objects are created without a prompt during a multiuser development merge.
Conflicts that are not inserts but are resolved because of the automatic inserts are applied without a prompt during a multiuser development merge.
To change security settings or database features in a multiuser development environment, you must edit the master repository directly. To do this, remove the master repository from the multiuser development directory, edit it in offline mode, then move it back.
The rules for patch merges are also similar to the full merge rules, except that the behavior for deleting objects is different. For example, if an object is deleted in the current repository, the default behavior for patch merges is to always ask the user whether the object should be discarded or retained. This is different from full merges, which often accept deletions from the current repository without prompting.
You can use the -U and -V options in the patchrpd command-line utility to automate the patching process. The -U option enables the patching process to complete by accepting default decisions for conflicts, while the -V option enables you to specify an output file for recording all merge conflicts so that you can examine them and possibly take action later.
Follow these guidelines to use patchrpd to automate the patch process:
Apply patching automatically using default rules. Include the -U option in patchrpd to always apply the default decisions for conflicts. For example, if both repositories (current and modified) change the name of an object, the default decision is to keep the name in the modified repository, to avoid overwriting user customizations. If you do not include this parameter, patchrpd displays a warning and exits if a conflict is detected.
Record conflicts in an output decision file. Include the -V option to cause patchrpd to generate a decision file that shows all the conflicts from the merge. The decision file lists the decisions that would have been displayed in the Define Merge Strategy screen of the Merge Wizard if the merge had been performed in the Administration Tool. The decision file provides a record of all items that can be influenced by user input.
Modify the decision file to change the result. After you run patchrpd, there are two ways to make changes to the resulting repository:
You can use the Load Decision File button in the Define Merge Strategy screen of the Merge Wizard to load the merge decisions, and then change the decisions if needed. You can then complete the merge in the Administration Tool. Alternatively, you can save the modified decision file using the Save Decisions to File button, and then re-run patchrpd with the decision file as an input using the -D option to reapply the patch with the new decisions.
You can edit the decision file by hand, and then re-run patchrpd with the decision file as an input using the -D option to reapply the patch with the new decisions.
|
 Copyright © 2010, 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
