Page and Field Configurator is another great framework delivered by Oracle to enable customers to isolate/eliminate customizations. Alternatively, it provides a method to make such changes as non-invasive configurations.
Let us take an example of a simple requirement where we need to update the label of a field (URL) on a page/component (URL_TABLE).
Instead of making this change on the Page object via App Designer as a customisation, we can simply configure this using the 'Page and Field Configurator'.
Navigation: Enterprise Components > Page and Field Configuration > Page and Field Configurator
Even after we make the changes as shown in the image above, we will notice that the URL label will continue to refer to the delivered value. This is because we are missing a step in the 'Page and Field Configurator' process! That is, we need to 'Map Configuration to the Portal Registry'. This basically means that we need to apply these configurations to the Component peoplecode events via the Event Mapping Framework. In case you did not know already, 'Page and Field Configurator' actually leverages Event Mapping framework behind the scenes!
Result
Once we push the 'Apply Configuration' button, we will now notice a new column 'Review/Edit Mapping' as shown in the image below. If we click on the 'Review/Edit Mapping' hyperlink, we will be taken to the corresponding Event Mapping configuration associated with the content reference of this component.
After the 'Map to Portal Registry' step is completed, we can now see the configuration take effect on the page.
Migration
Next, let us move on from the implementation phase to the release management phase. It is great that we can eliminate customization of managed objects and use configurations instead. But we need to find a way to automate the configuration process when we get ready to move the change to other environments (TEST, UAT, PROD, etc.). Simply making these changes online as a manual step will likely make it inconsistent and prone to errors.
To facilitate this configuration migration, a delivered ADS (Application Data Set) definition called
Here is how we create the Data Migration Workbench project using the
PeopleTools > Lifecycle Tools > Migrate Data > Data Migration Workbench
Tip
The Data Migration Workbench project is now ready to be 'Saved' and 'Copied to File'/exported. But if we just use this data set, we will only be moving the 'Page and Field Configurator' data and will need to manually use the 'Apply Configuration' functionality on the 'Map to Portal Registry' page to generate the Event Mapping configuration on the target environment. This additional manual step basically defeats the original purpose of automating the configuration!
To eliminate this additional manual step ('Map to Portal Registry'), we can simply include the 'Event Mapping' configuration using the
Now, we are ready to 'Save' the project and 'Copy to File' to export the configuration data ('Page and Field Configurator' and 'Event Mapping') from the source environment.
Importing Data Migration Workbench Project
Here are the instructions to import the Data Migration Workbench project in the desired target environment.
Note: The following assumes that appropriate 'File Locations' are setup in both the source and target environments to be able to create and access the project (copied to file).
Navigation: PeopleTools > Lifecycle Tools > Migrate Data > Data Migration Workbench
By default the
Once we approve the migration, the project will change status to 'Scheduled for copy from file' and eventually to 'Copy from file succeeded' if there are no errors/issues with the migration.
Let us take an example of a simple requirement where we need to update the label of a field (URL) on a page/component (URL_TABLE).
Instead of making this change on the Page object via App Designer as a customisation, we can simply configure this using the 'Page and Field Configurator'.
Navigation: Enterprise Components > Page and Field Configuration > Page and Field Configurator
Even after we make the changes as shown in the image above, we will notice that the URL label will continue to refer to the delivered value. This is because we are missing a step in the 'Page and Field Configurator' process! That is, we need to 'Map Configuration to the Portal Registry'. This basically means that we need to apply these configurations to the Component peoplecode events via the Event Mapping Framework. In case you did not know already, 'Page and Field Configurator' actually leverages Event Mapping framework behind the scenes!
Result
Once we push the 'Apply Configuration' button, we will now notice a new column 'Review/Edit Mapping' as shown in the image below. If we click on the 'Review/Edit Mapping' hyperlink, we will be taken to the corresponding Event Mapping configuration associated with the content reference of this component.
After the 'Map to Portal Registry' step is completed, we can now see the configuration take effect on the page.
Migration
Next, let us move on from the implementation phase to the release management phase. It is great that we can eliminate customization of managed objects and use configurations instead. But we need to find a way to automate the configuration process when we get ready to move the change to other environments (TEST, UAT, PROD, etc.). Simply making these changes online as a manual step will likely make it inconsistent and prone to errors.
To facilitate this configuration migration, a delivered ADS (Application Data Set) definition called
EOCC_CONFIGURATION is available. This data set enables us to export the configuration data associated with the 'Page and Field Configurator' and import it to the desired target environment using Data Migration Workbench.Here is how we create the Data Migration Workbench project using the
EOCC_CONFIGURTATION data set.PeopleTools > Lifecycle Tools > Migrate Data > Data Migration Workbench
Tip
The Data Migration Workbench project is now ready to be 'Saved' and 'Copied to File'/exported. But if we just use this data set, we will only be moving the 'Page and Field Configurator' data and will need to manually use the 'Apply Configuration' functionality on the 'Map to Portal Registry' page to generate the Event Mapping configuration on the target environment. This additional manual step basically defeats the original purpose of automating the configuration!
To eliminate this additional manual step ('Map to Portal Registry'), we can simply include the 'Event Mapping' configuration using the
RCF_SERVICES data set in the same Data Migration Workbench project as follows.
Now, we are ready to 'Save' the project and 'Copy to File' to export the configuration data ('Page and Field Configurator' and 'Event Mapping') from the source environment.
Importing Data Migration Workbench Project
Here are the instructions to import the Data Migration Workbench project in the desired target environment.
Note: The following assumes that appropriate 'File Locations' are setup in both the source and target environments to be able to create and access the project (copied to file).
Navigation: PeopleTools > Lifecycle Tools > Migrate Data > Data Migration Workbench
By default the
MigrateData Approval ProcessID will change the project status to 'Evaluating Approval'. We can use the 'Work Approvals' link which is shown in the image above to review and approve this migration.
Once we approve the migration, the project will change status to 'Scheduled for copy from file' and eventually to 'Copy from file succeeded' if there are no errors/issues with the migration.
Thanks! Your write-ups help more people than you know.
ReplyDeleteThanks Ricky! Appreciate it.
DeleteThanks you for sharing wonderful article
ReplyDeleteHi Sasank,
ReplyDeleteGr8 article as always.
Can you suggest how we can roll back the above migration? Scenario is like we already have a few existing datasets in Prod and then we added a few more using DM workbench as suggested above, now we want to roll back only the recently migrated datasets without impacting earlier datasets ? Let me know if you can throw some light on this.
Thanks,
Kartik Shah
Hi Kartik - I don't think there is an easy way to do the rollback particularly for application data.
DeleteWhat we could do is 1) Run a compare using DMW before we migrate the data. 2) Then use the compare to manually rollback or re-configure.
Note that ADS provides options to delete rows. So, you could create a new rollback project and migrate it to production to perform the rollback.
Just a few ideas. I have not done any of this myself. :)
Hi Sasank,
ReplyDeleteIf we make the page configuration status as Inactive, it will rollback everything. But, on the event level mapping there is an option to Enable the events we want. Would that help in this scenario?
Thanks,
Sameer
I think that should solve the problem of disabling the migration. But it will not technically rollback the configuration that was migrated.
DeleteHi Sasank,
DeleteWhat I tried was configuring something for hiding some fields with the page configuration status as Active and the results were visible as the page fields were hidden.
Next I tried to keep the page configuration as Inactive and the earlier fields started appearing again.
So, according to this the changes seem to be disabled.
Thanks!