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:
Components: PTPN_POPUP_WINDOW, PTPN_POPUP_WINDOW, PTPN_SEEALL
Query Permissions: PTPN_VIEWALL Access Group: PTPN_VIEWALL
- 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:
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.
