Notification Service

PeopleCOMP Services Description Notification Service The Notification Service supports notifications to users of events within the PeopleCOMP application. Generally these notifications are either: • “requests for action” such as “An Assessment has been created that you need to complete”; or, • “confirmation of actions completed” such as “You have successfully changed your password”. General Structure The Notification Service presents an interface to the application enabling: • submission of a notification for action; • reporting of the status of notification jobs; • the storage of notification templates or models; and, • the modification of notification templates. A suggested interface is presented as xxxxx. In the first version of the application it is planned to support notifications using email only. This may change for future revisions. Notification templates are to be stored in the application database. A schema is provided in the following sections. PeopleCOMP have chosen Hangfire ([login to view URL]) as the engine for background jobs. It is, therefore, anticipated that Hangfire will be used to process notification jobs. Design Thoughts The product will be supplied with a Notification Template for each possible Notification event. The customer must be able to edit these supplied templates to suit their own requirements. They cannot, however, add new types or delete existing types. Since all user supplied strings are stored as UserStringGroups, it is expected that this mechanism will be used to store the templates, names, etc for Notification types. The service clients will call [login to view URL]() to initiate message sending. The parameters supplied will list the required notification type, the recipient and substitution parameters for the message body. The service will receive the request, perform any validations and then retrieve the appropriate notification template. It will use the supplied substitution parameters to complete an email message body (be that plain text or HTML or whatever). The required number of parameters will vary by the notification type so validation may be indicated. The service will then call a message agent to dispatch the message. It is highly desirable that this call be behind an Interface so as to allow a choice of message agent. A choice of message agent has not been made. Please consider what may be available in Azure and such services as SendGrid. Hangfire is our chosen background task handler. Notifications should be performed as a background task. Hangfire is configured in the existing UsePComp() method. Requirements Apart from the several suggestions made above: 1. Discovery and learning. 2. Access the source tree as it stands after step 1. 3. Implement the Interface. 4. Review and remedy as required.