HCM Fluid Attachment Framework Configuration

Building Something with the HCM Fluid Attachment Framework

What we are building

We want to build a fluid component in PeopleSoft that utilizes the HCM attachment framework.  We want this component to be accessible to certain users as an entry page, thus the need to display a logo instead of a back button.  This needs to setup with as little customization as possible.

Software Requirements

This exercise needs to be setup on HCM Image 25 or greater.

Challenge 1:

Configure the Fluid Branding Framework to show a logo instead of the back button:

Configuration Steps:

Via WINSCP:

Upload your svg logo file the following location to the portal.war directory on the Peoplesoft Server. The directories uc_content and images will need to be created.  If you use the peoplesoft login page, it may be likely that you have already placed an image in a similar location within the PORTAL.war directory.

Note: IE may position your SVG in the centre: you can open the SVG image with notepad, and make the following additions / changes:

<svg viewbox="0 0 64 64"
    preserveAspectRatio="xMinYMid">
    … </svg>

Where the viewbox would be the ratio of your SVG.  The preserveAspectRatio property will ensure your SVG is left aligned in IE.

Theme Macro Set:

Via Ptools > Portal > Branding Theme Macro Set

Select PT_DEFAULT_MACROSET_855

Click Copy Macro Set

New Name: UC_PT_DEFAULT_GUEST_855

Within UC_PT_DEFAULT_GUEST_855 Theme Macro Set:

Change Attributes:

36 PT_BANNER_BACKGROUND_COLOR: red; background-repeat: no-repeat;

37 PT_BANNER_BACKGROUND_IMAGE:  url(/uc_content/images/UCImage.svg)

57 PT_BANNER_BORDER_COLOR: rgb(97, 33, 11)

75 PT_BANNER_BUTTON_TRUE_BG_COLOR_HOVER: rgb(221, 87, 4)

Notes ~ it would have been easier to use the database stored %Image on Item 37, but that doesn’t work ~ this is a slight hack to get around the no back button issue.  If this is to be migrated to other environments, uploading the image to the PORTAL.war directory will need to be done the target environment as well.

Assemble Themes:

Via Ptools > Portal > Branding > Assemble Themes

Load theme DEFAULT_THEME_FLUID

Click Save As Button:

Use name: UC_THEME_FLUID_GUEST

Set the following Attributes:

Create Role Security:

Via Ptools > Security > PLs and Roles > Roles

Add a new role called UC_PUBLIC (use for the scope of this project)

Assign it to an account that will access this component.

Assign Themes:

Via Via Ptools > Portal > Branding > Assign Themes

Challenge 2:

Using the HCM Attachment Framework on a Fluid Page.

Configuration Steps:

First, create and build the following Fields and Records in App Designer:

And Insert the following Data:

Insert into PS_UCUT_ODC_DTYPE values ('WKPERM');

Create new Field: UC_GUID: Length 36 Char

Create new record: UCPT_PUBFILE

Insert UC_GUID, and sub record: HR_ATT_DD_SBR to the record

In the Record Definition, set the Owner ID, the Description to Cust Record Storing Pub Objects

Build Record

These will importantly be used in Context and Store Keys in the following steps.

Next we have to step through the HCM attachment framework:

Via the PIA,

Create a new Authorization:

Create a new Authorization Entry:

Define Attachments:

Configure Keys:

Set Context Key: related to the table created previously

Set Store Key: related to the table created previously

Maintain Definitions:

Configure as below:

App Designer Work:

New Record:

UCPT_PUB_WRK - Derived / Work

Fields added to Record:

SAVE_PB

Add PeopleCode to Field in Record:

SAVE_PB.FieldChange

import HR_ATTACHMENT_FLU:Attachment_Fluid;

Component HR_ATTACHMENT_FLU:Attachment_Fluid &call_attachment;

/* Calling Save*/

&call_attachment.Attachment_SaveProcessing();

New > Page – Fluid > PSL_APPS_CONTENT

UC_S_FL

Insert Sub Page: HR_ATTCH_FL_SBF

Insert Push Button: associate with record created previously

Component:

UC_S_FL

Insert Page UC_S_FL

Component Properties

  

Add PeopleCode:

UC_S_FL.GBL PostBuild:

import HR_ATTACHMENT_FLU:Attachment_Fluid;

Local string &RandomGuid;

Component Rowset &Lvl1, &RS_DocDefns;

Component HR_ATTACHMENT_FLU:Attachment_Fluid &call_attachment;

/*Initialize parameters for calling attachment constructor*/

&CKeys = CreateArray("WKPERM"); /*This array would contain the Context key values*/

&RandomGuid = GetJavaClass("java.util.UUID").randomUUID().toString();

&Store_Keys_Array = CreateArray(&RandomGuid); /*This array would contain the Store key values*/

/*Initialize component rowsets*/

&Lvl1 = GetLevel0()(1).GetRowset(Scroll.HR_ATT_KEYS_S);

&RS_DocDefns = GetLevel0()(1).GetRowset(Scroll.HR_ATTACH_FLU);

/*Calling attachment constructor*/

&call_attachment = create HR_ATTACHMENT_FLU:Attachment_Fluid("UC", "PUB", "", %Date, &CKeys, %UserId, %Component, "", &Store_Keys_Array, False);

Add Menus:

Security Setup:

Via PIA

Add Permission List: UC_PUBLIC &  Assign to Role UC_PUBLIC.

Set Page access in Permission list:

Create a Content Reference for this too!! Very NB for it to work!!

If you do not have a content reference created, you will get this terrible error:

URL to Visit:

Visiting the URL as a user with UC_PUBLIC Role:

https://urpsENv/psp/ps/EMPLOYEE/HRMS/c/UC_S_MENU.UC_S_FL.GBL

SQL:

This query shows where this is stored in the database:

select * from PS_UCPT_PUBFILE a join PS_HR_ATT_FILES_DD b on a.attachsysfilename = b.attachsysfilename;

Files that have been deleted appear as ‘D’ in the HR_ATT_TYPE column ~ where they’ll have to be cleaned up by the admin. (this setting is configurable on ‘Create New Authorization’ above).

Afterthoughts:

Obviously this creates data in your database, and steps should be taken to prevent any user from accessing this ~ and at certain intervals the data should be cleaned up.

PeopleSoft Fluid Push Notifications

Introduction

Deploying Push Notifications will touch a lot of tiers in your PeopleSoft environment.  On a vanilla demo PUM Image, Push Notifications can be enabled in a short amount of time. I have found in a production PeopleSoft environment a great deal of testing (and reconciliation in some cases) will need to occur along the way of a successful Push Notification Implementation.

This high-level diagram outlines some of the layers used to get a Push Notification sent to an end user.

Our Project Scope

We worked to turn on federated push from HCM and FSCM to our Interaction Hub using tools 8.55 for both Classic and Fluid Components.  An end user would sign into our iHub, and they would see outstanding approval workflow from any of our existing transactions; FSCM: (i.e. a journal) or HCM (i.e. a time entry). The transactions appear mixed together through the Push Notification Flag instantly.  The end user would do work on these transactions, and when the transaction is complete, the item would be removed from the Push Notification Flag.  The scope of this our current workflow transactions; we are not looking at Fluid approvals quite yet, but hope to in the near future.

Technical Setup

High-level overview of how Push Notifications are Federated

How to setup Push Notifications between a remote content provider (ex HCM) and your Interaction Hub, has been well documented here:

https://support.oracle.com/epmos/faces/DocumentDisplay?id=2029617.1

This document shows what is needed to get this working, and as a bonus shows how you can modify an existing transaction to also create a Push Message.

Testing

Deploying and Configuring Push Notifications is relatively easy, the testing is far more complex, and I would like to share a few things learned along the way.

The importance of a Pilot:

We opted to deploy this to a small (around 100) group of users for a multitude of reasons:

• This technology is still pretty green and with a pilot group, we can find proactive volunteers who can work with us to troubleshoot issues.
• It is nearly impossible for a Business Analyst to comb through and test every type and variance of transaction.  We came across Push Notification bugs with transactions like:
• Resubmitted journals
• Managers who submitted time on behalf of an employee. 

• Issues that directly involve integration between the iHub and a remote content provider are even more difficult to replicate, and therefore to solve.

Technical Findings / Issues

We have come across some technical issues:

• Ensure you are at the minimum version of web logic outlined in this document Doc ID 2060301.1
• PeopleSoft Security: Ensure the push notification flag and View All Components are enabled:

Menu: PTPNEVENTS, Push notifications
Components: PTPN_POPUP_WINDOW, PTPN_POPUP_WINDOW, PTPN_SEEALL
Query Permissions: PTPN_VIEWALL Access Group: PTPN_VIEWALL

• There is an known issue where if you do not have an account on all systems you connect with Unified Navigation, the instant websocket push real time feature doesn’t reliably work: a bug is open for this: Bug 25853033
• Certain layers of our infrastructure needed to be modified to allow Websocket Traffic through: we had to work with our ERP Firewall Vendor and our Netscaler config on this.
• A lot of Async IB Traffic gets created when Federating Push Notifications. We had to come up with an archive and purge strategy on async IB traffic.
• The Push Notification Cleanup tool is pretty broad: the current functionality (found in Nav bar >Navigator> Peopletools > Push Notifications > Notification Window > Configuration > System Config) doesn’t  allow you to differentiate between Actions or Alerts, nor can you setup a recurrence:

We have found the table where Push Notification messages are stored is flat, and relatively easy to manipulate.  Queries like the following:

delete from SYSADM.PSPTPN_MSG_TBL where PTPN_CATEGORY_TYPE = 'FYI' and LASTUPDDTTM < trunc(sysdate) - 14;

can be added to an app engine and run nightly to lower the number of Push Notification Messages.

Functional Findings / Issues

We have encountered some UX issues that should be clarified or fixed before a general release to our user base:

• It should be clearly defined the difference between actions and alerts.
• Power Users who get more than 10 approvals per day will not find this as useful.  It fares much better with users who receive a lower amount of transactions.
• The View All component for Push Notifications leaves a lot to be desired, the number one issue with it is the left menu appears hidden, making it far less useful as FYI items that were dismissed appear by default: https://community.oracle.com/ideas/19274

There is a custom fix that can be done to mitigate this for now:

On Page activate event of PTPN_SEEALL Page

Set HideLeftPane( True);  to HideLeftPane( False);

• It is hard to tell which items have been read versus un-read.  If you have 5 items in your Push Notification Flag, but 2 of them are new, they will all become the same after you click the flag.  We have put in an ask for this: https://community.oracle.com/ideas/19143. 

There is a custom fix that can be done to mitigate this for now:

Open StyleSheet PTPN_NOTIFICATION_CSS and make the following change:

Under: .ptpn_row_bgcolor_unread, set font-weight to bold

Under: .ptpn_wordwrap, set word-break to all.