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.