Migrating Custom Kibana Visualizations/Dashboards

In the following DIY blog series, I described how we can use the framework provided in PeopleTools 8.58 to configure our own custom visualizations and dashboards in Kibana and use them in PeopleSoft applications via the 'Kibana Visualizer'.

Refer: DIY - Kibana Dashboards with Application Data

Someone ask a very valid question:
How do we migrate these configurations from one environment (source) to another (target)?

My previous blog post detailed the steps for migrating the Search Definition and associated configuration. This post will describe the steps for migrating the Kibana Visualizations and Dashboards.

Refer: Migrating Custom Search Definition and Configuration

Migration

We used an App Designer project to migrate the Search Definition. We will be using Data Migration Workbench to migrate all the Kibana Visualization/Dashboard related configurations. The following Doc Id from My Oracle Support details the application data sets delivered by Oracle.

E-KB: How to Migrate Kibana Dashboards From One Environment to Another? (Doc ID 2684543.1)

Application Data Set	Description	Notes
PTSF_KIBANA_DBOARD_DTL	Defines the dashboards that are deployed to Kibana.	This is the configuration located in PeopleTools > Search Framework > Administration > Deploy Kibana Dashboards
PTSF_KIBANA_DBOARD_ATT	Defines the JSON files of a dashboard.
PTSF_KIBANA_DBOARD_ROLE_MAP	Defines the roles mapped to a dashboard.	This is the configuration located in PeopleTools > Search Framework > Administration > Kibana Privileges
PTSF_KIBANA_DBOARD_CREATE_ROLE	Defines the privileges assigned to a role with respect to a Kibana dashboard.
PTSF_KIBANA_SYSDB	Defines the system monitoring dashboards that are imported and deployed.	This is the configuration located in PeopleTools > Search Framework > Administration > Kibana Privileges We did not set this up in the examples demonstrated in the DIY series.

In addition to the above configurations, we also need to migrate any Tiles or Related Information configured using PeopleTools > Search Framework > Administration > Kibana Visualizations.

Application Data Set	Description	Notes
PSPRSM_CREF	Content Reference	Dashboards configured as Tiles.
RCF_SERVICES	RC Services	Dashboards configured as Related Information of a Fluid page.

Finally, if we used the following workaround to setup any Kibana dashboards as related content of classic pages, then we need to migrate the configuration using the data sets listed below.

Refer: Kibana Dashboards - Related Content for Classic

Application Data Set	Description	Notes
RCF_SERVICES	RC Services	Dashboards configured as Related Content of a Classic page.
RCF_SERVICE_DEFINITION	RC Service Definition	Custom Related Content Service Definition - Classic Kibana Related Content

Here is a project used for demonstration purposes. This project will be used to demonstrate the migration of all the configurations created in the DIY series.

Imported Kibana Dashboards

The following steps will migrate the dashboards imported into PeopleSoft from Kibana.

Demo

Kibana Privileges

Demo

Kibana Visualization as a Tile

Demo

Kibana Visualization as Related Information (Fluid)

Demo

Kibana Visualization as Related Content (Classic)

Demo

Post Migration Steps

Once we migrate all the data sets using Data Migration Workbench, we should deploy the imported dashboards to Kibana in the target environment. As you can see in the screenshot below, the imported dashboards will appear to be in deployed status. This status is brought forward from the source. Therefore, we must deploy once again in the target environment.

The deploy step takes care of all the configurations in Kibana - index patterns, visualizations and dashboards!

Page and Field Configurator - Migration Tips

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 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.