Business Logic

Notification Services listens for events during the submission process and generates email notifications to relevant users. The main components of the business logic are SubmissionEventListener, NotificationService, and Composer. The business logic handles events, composes notifications, and includes deep links that guide users directly to the necessary actions within PASS. It ensures that notifications are accurate, secure, and properly validated to maintain workflow integrity.

SubmissionEventListener

The SubmissionEventListener is the component responsible for connecting to a messaging source and reading SubmissionEventMessage messages. Note the use of the Spring annotation JmsListener on the processMessage message. NS uses Spring for messaging configuration, which is managed by the JmsConfig class.

The NS responds asynchronously to modification of SubmissionEvent resources. A SubmissionEvent represents the state of the Submission in a workflow. Each time a significant step in the submission workflow is taken, a SubmissionEvent resource will be created. Notification Services do not create SubmissionEvent resources; SubmissionEvent resources are created by Ember via Pass-Core as the user moves through the submission workflow. Pass-Core will emit a SubmissionEventMessage message indicating the creation of the SubmissionEvent, and the Notification Service will listen for, and respond to these messages.

NotificationService

The NotificationService is the primary service that contains the business logic associated with reading the Submission for the SubmissionEventMessage and composing a Notification and handing it off for dispatch. If future requirements dictate multiple Notifications were to arise from a single SubmissionEvent, NotificationService would be the starting point for implementing the distribution.

Composer

The Composer class does the heavy lifting within the NotificationService. It is responsible for composing a Notification from the Submission and SubmissionEvent, including:

• Determining the type of Notification.

• Creating and populating the data structures used in the parameters map.

• Invoking the LinkValidator to ensure the SubmissionEvent contains valid links for the Notification type.

• Determining the recipients of the Notification, and from whom the Notification should come from.

After a Notification has been created and populated, it is sent to the DispatchService.

Notification Links

Notifications which prompt the recipient to perform an action are to contain a "deep link", that when clicked/activated, takes the user directly to the web page in PASS that requires their attention. For example, a "please review" deep link would resolve directly to the submission overview, with a button allowing the user to approve the submission, cancel the submission, or request further changes. A notification that requests corrections should deep link to a page that highlights the edits or actions required by the user, displaying the comments or instructions from the reviewer.

Link Replay

Because deep links are durably stored (i.e. they can be found in email and used at any time after receipt), they may be replayed after the action has been taken. For example, a user activates a "please review" notification link after they have already performed the review. The user interface or link resolution components will respond in an appropriate way when this occurs.

Link Security

If a user's permissions change between the time a link was generated and the time a link was activated - for example, a User was an Authorized Submitter at the time the link was generated, and they were removed from the Grant by the time the link was activated, the user interface or link resolution components will respond in an appropriate way ensuring the user cannot approve something they don't have permission for.

User Token Link

According to the proxy submitter use case, a preparer may request an authorized submitter review a submission without that submitter existing within PASS.

In this case, a SubmissionEventMessage with an associated SubmissionEvent of typeAPPROVAL_REQUESTED_NEWUSER will be created by Pass-Core and sent to the message queue. The SubmissionEventMessage object will have the User Token Link set in the SubmissionEventMessage.userApprovalLink attribute. This is the link that is included in the notification for the recipient to click on so a User object is created for them to authorize the submission.

Link Validation

The class LinkValidator will use link-validators in the notification configuration to validate that the correct URL is present in the Link object for the Notification type. The Link objects are created in the SubmissionLinkAnalyzer and then sent to LinkValidator. The link-validators field in the notification configuration file can be an array of Notification types or *, which will be a link validation rule that applies to all.