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!

Migrating Custom Search Definition and Configuration

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)?

This post will detail the steps for migrating the Search Definition and associated configuration.

Migration

We can migrate everything related to the Search Definition using an App Designer project. Simply insert the Search Definition and make sure the the 'Related Definitions' are selected as shown below.

Save the 'Project' and migrate to target environment.

Note: If we used any Application Package PeopleCode to configure the Search Definition (Security Configuration) - Document Filter App Class, then we must also include the App Package in the project.

Post Migration Steps

Once we migrate the configuration, we must complete the following administrative steps in the target environment.

1. Deploy Search Definition
2. Schedule Search Index
3. Configure Search Context (optional)
4. Configure Search Group Security

Related Posts

Migrating Custom Kibana Visualizations/Dashboards

Portal General Settings Migration

From time to time, we may need to make adjustments to the 'General Settings' page under PeopleTools > Portal.

What if we want to migrate/script these changes instead of manually performing the updates in each environment?

Portal Description, Default Template, Owner ID and Folder Navigation

Any changes to the Portal Description, Default Template, Owner ID and Folder Navigation can be simply migrated using the Portal definition as shown below.

Migration

Portal Search, Navigation and Header Frame Options

The Portal Search, Navigation and Header Frame Options are all stored as CREF attributes of a hidden content reference (PT_PORTAL_PROFILE_APPS91). Again, we can simply migrate this CREF object for any associated changes.

Content Reference

Content Reference Attributes

Migration

Node Templates

Finally, the Node Templates appears to be stored directly in PSPRDMCNTPRV SQL table. So, if we want to automate a change to these values, we can simply write a SQL script to update the necessary rows in this table.

Migration

Event Mapping Framework - Migration

A reader asked a question in one my posts on Event Mapping Framework.

Question: Do you know how I can include the "Configure Event Mapping" settings in an App Designer project so I can migrate it from dev to test to prod environments?

The answer is very simple. Since the Event Mapping Framework is simply an extension of the 'Related Content Service' functionality, the procedure to migrate the configuration is also the same as migrating 'Related Content'.

For those who are new to Related Content and/or Event Mapping Framework, here are the steps that will help with the migration.

Step 1: Insert 'Related Content Definition' into the Project

This will take care of migrating the 'Related Content Definition' and associated Application Class. Note: We must highlight 'Application Packages' under the 'Related Definitions' before inserting the Related Content Service ID into the project.

Step 2: Insert 'Related Content Service' into the Project

Insert the 'Related Content Service' by entering the 'Portal Object Name' of the associated 'Content Reference'. This will take care of migrating the 'Event Mapping' Configuration.

Step 3: Save and Migrate the Project

Simply save and migrate the project from the source to the target environment.