Showing posts with label Configuration. Show all posts
Showing posts with label Configuration. Show all posts

Thursday, September 5, 2019

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.


Tuesday, August 23, 2016

Branding 8.54+ - Role Based Theme Assignment/Override

In the past, I have written about Branding PeopleSoft applications using themes (and even theme macro sets in PeopleTools 8.55). In this post, I want to quickly show how we can assign different themes to different users based on roles/permission lists.

Using the steps detailed in my previous post - PeopleTools 8.55 - Branding, I created two different themes (Red and Blue).

Note:
Although, I am using PeopleTools 8.55, the same - User Attribute Based Theme Assignments - can be done using PeopleTools 8.54 themes as well.

The two themes have the following look and feel. I only updated the background color of the header to keep the themes simple. The idea is to demonstrate role based theme assignment/override. You could follow my other branding posts and make further theme changes as per your requirements.

Blue Theme:


Red Theme:


Environment Details: CS 9.2 PUM Image 2, PeopleTools 8.55.06

Assigning Branding Themes based on User Roles:

Branding System Options:

PeopleTools > Portal > Branding > Branding System Options

I left this as default for the sake of this proof of concept.


Assign Branding Themes:

PeopleTools > Portal > Branding > Assign Branding Themes



Again, for the purposes of demonstration and simplicity, I am using the delivered DEFAULT_THEME_FLUID theme as my default. Notice the 'Effective Date'? This means that we could potentially have certain themes only active for a specific period of time. For example, creating a football based theme specifically for students that is only effective during game week?


Further, you can see that I set the priority of the Red Theme higher (100) than the Blue Theme (200). This means that if a user has both CSK_RED_THM_ROLE and CSK_BLUE_THM_ROLE, the system would prioritize CSK_RED_THEME_FLUID as the user's theme.

Results:

User without CSK_RED_THM_ROLE or CSK_BLUE_THM_ROLE (Default):

This is a scenario where the user does not have any of the roles defined in the 'User Attribute Based Theme Assignments' section. The user simply gets the 'Default Theme'.


User with access to CSK_BLUE_THM_ROLE:

This is a scenario where the user has the role CSK_BLUE_THM_ROLE but not CSK_RED_THM_ROLE. So, the system assigns the CSK_BLUE_THEME_FLUID theme for this user.


User with access to both CSK_RED_THM_ROLE and CSK_BLUE_THM_ROLE:

This is a scenario where the user has both CSK_RED_THM_ROLE and CSK_BLUE_THM_ROLE. The system uses the priority configuration and assigns the CSK_RED_THEME_FLUID.


PeopleBooks Reference:
PeopleTools 8.54
PeopleTools 8.55

Sunday, April 3, 2016

Working with Rich Text Editor - Custom Configuration, Toolbars and Plugins - Part 2

Modifying the Enter key (line breaking) behavior:

There was a question in the OTN forum asking if we could alter the default behavior of the ENTER key in the context of the CKEditor (RTE field) content area. Say, we want to change it to insert a line break <br/> element instead of the default paragraph <p> element?

We can refer to the following resource for the configuration change that is required:
Enter Key | CKEditor.com

In my previous post on CKEditor and RTE fields in PeopleSoft, I detailed how we can reference a custom configuration for RTE fields.

Assuming that we already have a custom configuration associated with our RTE field, we just need to add this line to our configuration (HTML) to change the ENTER key behavior to <br/> instead of <p>.

CKEDITOR.config.enterMode = CKEDITOR.ENTER_BR;

Setting a Default Style (Font) for the CKEditor:

There was also a follow up question asked which was removed by the author later. I am assuming that the author found a solution/workaround. But I have a copy of the question which describes the requirement.

If we enter any text in the Rich Text Editor as follows:


It gets stored in the database without any default styling:


This behavior might be desired in most cases but the requirement is to set a default font for the paragraph element so that it gets stored as follows (without users having to manually select the default font every time):


I tried to search for a custom configuration that allows us to set a default font to the editor and found the following useful resources:

http://ckeditor.com/forums/CKEditor-3.x/Setting-Default-Font-and-FontSize-Setting-Default-Labels
http://ckeditor.com/forums/CKEditor-3.x/CSS-style-sheet-for-content-area
http://ckeditor.com/forums/CKEditor-3.x/How-do-you-set-default-font-and-default-font-size
https://www.cotonti.com/forums?m=posts&q=6421

Based on a popular suggestion, I tried adding the following line to the custom RTE configuration:
CKEDITOR.config.font_defaultLabel = 'Arial';

But font_defaultLabel property only sets the default label for the Font in the RTE Toolbar but it does not affect the contents of the editor in any way unless we explicitly select the Font (manually).

The only workaround that I found was to write a 'script' to initialize a placeholder text and wrap it around a <span> attribute with the desired styling. This would make sure that the content area gets initialized with a default font.

Refer: http://stackoverflow.com/questions/16339258/ckeditor-4-how-to-set-default-font

I adjusted the 'script' to only trigger the default font initialization when there is no existing content in the editor (on add mode). This would ensure that we are not overwriting any of the existing contents with the placeholder text.

Script for reference:

CKEDITOR.on( 'instanceReady', function( ev ) {

     if (ev.editor.getData() == '') {
             ev.editor.setData('<span style="font-family:georgia,serif">PlaceHolder&nbsp;Text</span>');     
     };
});

Custom RTE Configuration:


Results - On Add Mode:


Results - After replacing the place holder text:


Results - Contents in the database:


Results - On Update Mode:


Thursday, September 24, 2015

Working with Rich Text Editor - Custom Configuration, Toolbars and Plugins

Rich Text Editors (RTE) are being used more commonly with the latest PeopleTools versions. There are several pages that contain Rich Text Editor fields (generally for configuration) which are then used for display on other transactional pages using HTMLAREAs, used as the content for Rich Text enabled emails or used as the content for Rich Text enabled BI Publisher reports (to name a few use cases).

Note: The Rich Text Editor provided by PeopleTools is powered by CKEditor.

Page With Rich Text Editor Enabled Field:

Here is an example of a simple page that contains a Rich Text Editor field. 



The page contains a Long EditBox (CSK_RTE_DATA.DESCRLONG) with the following properties.


We are currently using the default Rich Text Options (Note: Configuration Settings Id is blank). The page appears as follows with the Rich Text Editor for the DESCRLONG Long EditBox. The Rich Text Toolbar is generated based on the default configuration.



Page Displaying Rich Text Data:

Here is an example of a simple page that displays data stored in a Rich Text enabled field using a HTMLAREA.


Page Activate PeopleCode to display the Rich Text data field in the HTMLAREA:


The page display the Rich Text data in the HTMLAREA as follows:



Adding Custom Rich Text Options - Templates, Plugins:

I recently came across an interesting question on the OTN forums. The question was "how to use Rich Text to display an iframe with a link to a youtube video?". If you look at the above Rich Text Editor field that uses the default Toolbar, it does not have the ability to add any HTML tags or specifically IFRAME content.

To enable additional/custom Toolbar items on the Rich Text Editor, we must first create our own custom Rich Text Editor Configuration.

Creating a Custom RTE Configuration:

We need to create a new HTML definition with a name that starts with 'PT_RTE_CFG'. Let us create a custom HTML definition called PT_RTE_CFG_CSK cloned from PT_RTE_CFG_PTPPB (delivered RTE Configuration).


Now to enable a custom Toolbar item for embedding an IFRAME, we must make use of additional plugins. To find the list of all available plugins as delivered, we can look in the following directory on the web server:

<PIA_HOME>/webserv/<domainname>/applications/peoplesoft/PORTAL.war/<sitename>/ckeditor/plugins

Fortunately, in this case the IFRAME plugin for CKEditor is already available as delivered (if not we must download and place the required plugins in the above folder path).


Let us now add the custom IFRAME Toolbar to our Custom RTE Configuration (PT_RTE_CFG_CSK). Let us include the following additional line in the configuration (note the comma in the screenshot).

  { name: 'insert', items : [ 'Image','Flash','Table','HorizontalRule','Smiley','SpecialChar','PageBreak','Iframe' ] }



Moving ahead, let us reference this Custom RTE Configuration in the Page Field Properties of the Rich Text enabled field.



Now let us take a look at the page with the Rich Text enabled field.


We can see the additional/custom Toolbar that we added to our Custom RTE Configuration. This would help us with embedding an IFRAME element that links to a youtube video.




This results in an embedded IFRAME as follows:


Testing IFRAME on the Display Page:


Similarly, we can add additional custom Toolbars to our Custom RTE Configuration. Hope you find this useful!

Environment details at the time of writing this post:
HCM 9.2 PUM Image 12 (PeopleTools 8.54.08)

Reference:
PeopleBooks - Modifying the Rich Text User Interface