Understanding the Notifications Framework
The Notifications Framework provides a consistent, extensible communication mechanism that Campus Solutions product areas (consumers) can use to enable communications from their areas and a generic extensible framework which meets the real-time notifications needs of current features.
Customers can also craft their own solutions to use the framework without reinventing the lower level coding that enables notifications to be sent and tracked.
Notifications encompass a broad area of communications between the Campus Solutions system and users and also between users themselves. A notification may take these forms (referred to as channels):
Email
SMS
Alerts (for example, an informational message that appears on a portal homepage)
Worklist Items (an actionable hyperlink that appears on a portal homepage)
Push Notifications (for mobile apps on iOS/Android)
Announcements
The Notifications Framework:
Delivers an extensible, light-weight PeopleCode framework that can adapt to future needs.
Provides options to co-exist with, consume or be utilized by the existing COMMGEN processing.
Supports both real-time and batch notifications.
Provides a generic configurable notification solution that is not bound to any particular consuming application or to any particular UI technology.
Provides a Notification code level API that is flexible enough to be useful to all consuming applications; for example, Application Classes, Components, Application Engine programs, web services and so on.
Supports Timeout processing for worklist items.
Provides the ability to generate Reminder notifications for existing notifications.
At the deeper, technical level, the solution architecture uses the Entity Registry to generalize all notifications into a single structure. The architecture is modeled on a pluggable channel-based approach. Each notification type is supported by a dedicated channel that supports the idiosyncrasies of the particular notification type. All notification channels conform to the standard interface of a Notification Channel. As new notification types are identified, a new channel that conforms to the standard Channel interface will need to be created and registered with the framework.
The architecture has been implemented using vanilla PeopleTools application classes and Object Oriented design principles.
A vital point to understand is that the framework is not directly exposed to system users, but is used by consuming applications, also known as consumers (for example Delegated Access, New User Registration, Campus Mobile), which, in turn, interface with system users. PeopleSoft developers, rather than regular users, would directly interact with the framework, aside from the set up pages described below.
The Notifications Framework is used to send notifications to interested parties (determined by the consumer setup), via a notification channel (such as email, SMS, alerts or worklists) based on some transaction performed by a consuming application (the consumer). For example, if an employee wants to share some data with a person via email and hence grants access to some of his/her data (as is the case with Delegated Access functionality), then the consumer can use the Notifications Framework to send email notifications to the person.
The content to be sent to the concerned parties must be created as a Generic template, which is then used to create the notification. The templates are grouped together under a common consumer. Based on the consumer setup, valid templates for a transaction are selected, and a notification item is created against each valid template.
Finally, the items are checked for any errors or warnings, and if the items are found to be eligible for sending, then they are sent using the People Tools Notification Classes provided (PT_WF_NOTIFICATION.Notification App Class). The following diagram illustrates the relationships between the components of the framework:
Image: Notifications Framework High Level Architecture
This example illustrates the Notifications Framework High Level Architecture.
In the diagram above, the AbstractNotification class acts as a layer of encapsulation over the NotificationManager, which is the gateway for all consumers using the Notifications Framework. This is the Abstract Base class that consumers of the Notifications Framework should extend and implement in order to minimize consumer effort in sending notifications. After all processing is completed the NotificationRouter calls the applicable Notification Channel to deliver the notification type item/items created.
Image: Notifications Framework Communications Diagram
This example illustrates Notifications Framework Communications.
Notifications Framework Entities:
|
Entity |
Record |
Notes |
|---|---|---|
|
Notification Request Header |
SCC_NTFREQ_HDR |
N/A |
|
Notification Request Detail |
SCC_NTFREQ_DTL |
N/A |
|
NotificationRequestDetailER |
SCC_NTF_DTL_ER |
The NotificationRequestDetailER Entity is used to support multiple recipients like TO, CC, BCC for Email. This entity allows the framework to:
When an Email notification is to be sent to multiple recipients (TO, CC, BCC), the consumer needs to set the notification context property SCC_NTF_AUDCE to ‘ER’, EMPLID to null, and populate all the below properties as appropriate: /* Multiple Recipients for Email (To,CC,BCC) */ property array of string arrEMPLID_TO; property array of string arrEMPLID_CC; property array of string arrEMPLID_BCC; |
|
Notification Request Item |
SCC_NTFREQ_ITM |
N/A |
|
Notification Recipient |
SCC_NTFREQ_RECP |
N/A |
|
Notification Data |
SCC_NTFREQ_DATA |
N/A |
|
Notification Reminder |
SCC_NTFREQ_RMDR |
The Notification Reminder Entity is only used when a reminder notification is created for a previously generated notification. The Notification Reminder entity allows the framework to:
|
Image: Entity Hierarchy for Notifications
This example illustrates the Entity Hierarchy for Notifications.
