Merging Configurations, Customizations, and Personalizations Using ADS
The merge provided by Application Data Sets (ADS) framework applies to the merge able attributes and records defined in a data set. The merge property value determines whether the customer value for that attribute or record is retained or not. The merge using ADS takes place when there are modifications on attributes like labels, titles of a pivot grid model provided by Oracle PeopleSoft.
In the secondary merge process the framework provides options which determine the merge behavior for modifications made by the customer. Pivot Grid ADS uses the secondary merge for cases like addition of new dimensions or facts, changing the view options and so on.
See, Application Data Set Overview.
Note: These examples assume that the user follows the default merge process. After the compare, user has the option to override the merge and accept values for merge-able attributes.
The following scenarios compare the impact on pivot grid objects when you have to merge data between existing application and the application update available using the default merge process or the secondary merge process.
The scenarios describe a customer who is on an application version and how he proceeds for an application update using the ADS framework:
The customer decides to take the new update from PeopleSoft Update Manager (PUM) which includes an ADS project containing the pivot grid update.
He selects the updates he wants and creates a change package in the Change Assistant. If the customer selects an update containing a pivot grid, then the update is included as one of the ADS values.
The customer applies the change package in the target database. The change package with the ADS project has several steps like:
Copy to file.
Compare.
Review.
In this step the customer reviews the compare reports and overrides actions if required.
Copy from file.
The following sections describe the process and result of an application update in different scenarios where secondary merge is required or not required and changes are applied by application development, customer, or user.
|
Changes from Application Update |
Changes from Customer |
Result of the Merge on the Pivot Grid Object |
|---|---|---|
|
Configurations from application development which do not require secondary merge. For example, change in dimension aliases. |
Configurations from customer which do not require secondary merge. For example, updates the chart options. |
The customer’s configurations are maintained in the target database. Application changes are not applied because the changes were not on merge-able objects. Only the application fix is copied; the customer’s chart option configurations are maintained. |
|
Configurations from application development which require secondary merge. For example, adding a new dimension. |
Configurations from customer which do not require secondary merge. For example, updates the chart options. |
The customer’s configurations are maintained and the application changes are applied. Only the application fix is copied; the customer’s chart option configurations are maintained. |
|
Configurations from application development which do not require secondary merge. |
Configurations from customer which require a secondary merge. |
The customer’s changes are preserved, but the application fixes are not applied because the customer configurations always have a higher priority. |
|
Configurations from application development which do not require a secondary merge. |
Customer does not make any change to the pivot grid model but the user personalizes the pivot grid views. |
The customer personalizations are preserved but the application changes are not applied because they are part of a merge-able group where the target values have preference over the source. |
After the instance level compare of the merge-able objects:
The compare process determines that there are changes in Pivot Grid chart options and aliases. These being a part of the merge-able groups for the Pivot Grid, target values are preserved by default.
In the final compare, the target values for the merge-able attributes are preserved and displayed to the users.
Customer accepts the fix and then initiates a copy process.
The same merge framework is run to preserve the customer configuration.
|
Changes from Application Update |
Changes from Customer |
Result of the Merge on the Pivot Grid Object |
|---|---|---|
|
Update from application development on the pivot grid model and related objects. For example, changes to the query that is associated with the Pivot Grid model. |
Configurations from customer which do not require secondary merge. For example, updates the chart options. |
No merge is performed. If the customer selects to copy over the new version, all personalizations for the model need to be removed. |
|
Updates from application development on the pivot grid model and related objects. |
Configurations from customer which require a secondary merge. |
No merge is performed because customizations are detected. If customer decides to upgrade, the behavior is the same as in the previous PeopleTools releases (that is earlier than PeopleTools 8.54) where the source definition replaces the existing target definition. |
|
Configurations from application development which do not require a secondary merge. |
Customization from customer on the Pivot Grid model. |
No merge is performed because customizations are detected. If customer decides to upgrade, the behavior is the same as in the previous PeopleTools releases (that is earlier than PeopleTools 8.54) where the source definition replaces the existing target definition. |
|
Configurations from application development which require secondary merge. |
Customization from customer on the Pivot Grid model. |
No merge is performed because customizations are detected. If customer decides to upgrade, the behavior is the same as in the previous PeopleTools releases (that is earlier than PeopleTools 8.54) where the source definition replaces the existing target definition. |
|
Updates from application development on the pivot grid model and related objects. |
Customization from customer on the Pivot Grid model. |
No merge is performed because customizations are detected. If customer decides to upgrade, the behavior is the same as in the previous PeopleTools releases (that is earlier than PeopleTools 8.54) where the source definition replaces the existing target definition. |
|
Updates from application development on the pivot grid model and related objects. |
Customer does not make any change to the pivot grid model but the user personalizes the pivot grid views. |
All personalizations are removed. |
After the instance level compare of the merge-able objects:
The Pivot Grid custom merge code detects the customization and updates.
The updates including customizations are logged, and the merge process aborts.
A compare process is repeated, and the system displays the compare report visualization to the user. All changes, like the query name change, are listed in the compare report.
Customer can either select to retain the existing Pivot Grid model or copy over the new one.
An upgrade is run based on the customer’s selection.
|
Changes from Application Update |
Changes from Customer |
Result of the Merge on the Pivot Grid Object |
|---|---|---|
|
Configurations from application development which require secondary merge. For example, adds a new dimension. |
Configurations from customer which require secondary merge. For example, adds a new dimension which has a related action. |
Customer’s configurations are preserved and the application fixes are also copied. |
After the instance level compare of the merge-able objects:
The compare process highlights a newly added dimension.
If there are any merge-able attributes, the values are preserved in the target database.
Additional dimension in the target are reconciled with the source because the dimension is preserved. The additional dimension in the source is also preserved.
If there are any view related changes because of the additional dimensions, then those changes are also preserved.
The same merge and compare process is run for the related action object.
The related actions object in the merge reconciles the menu folders and layouts.
In the compare report visualization, user can identify the merge-able attribute values which are preserved in the target. The newly added dimension in the target are also preserved whereas the dimension in the source is displayed as a change to be added.
This behavior also applies to the related actions object.
Customer selects to uptake the fixes and initiates a copy.
The merge framework is run to preserve the customer’s configuration.
|
Changes from Application Update |
Changes from Customer |
Result of the Merge on the Pivot Grid Object |
|---|---|---|
|
Configurations from application development which require secondary merge. For example, adds a new dimension. |
Customer does not make any change to the pivot grid model but the user personalizes the pivot grid views. |
Customized personalizations are preserved, and the application changes are applied to the view that is associated with the Pivot Grid model. |
After the instance level compare of the merge-able objects:
No changes related to merge-able groups or secondary merge is found.
The compare process is repeated, and the system displays the compare report visualization to the user. The personalizations do not appear in the compare report but it shows a new dimension added to the pivot grid model.
Customer selects to uptake the fixes and initiates a copy.
The same merge framework is run to preserve the customer configuration.
|
Changes from Application Update |
Changes from Customer |
Result of the Merge on the Pivot Grid Object |
|---|---|---|
|
Updates from application development on the pivot grid model and related objects. For example, removing a dimension. |
Customer makes no change to the Pivot Grid model, but customer is using the dimension (that was removed by Application developer) in one of the Pivot Grid related actions. |
No merge is performed because of the customization. However, during validation, the conflict is detected and flagged as an error in the validation report, and customer has to modify the related action. |