Overview
This page describes the design for supporting notification consolidation for the notification service. It is an output of theĀ - OLMIS-5953Getting issue details... STATUS .
Class diagram
Tag
This new addition to the notification class would let us group notification together to be sent as a single, consolidated message later.
DigestConfiguration
Digest configuration will define how messages can be consolidated. The idea here is to let each of the services define possible ruling for the message digest. Each configuration will contain the following fields:
- Id - the UUID of the configuration.
- Time - time at which the digest should occur.
- Message - consolidated message to be sent instead of the individual ones. This would be a string accepting a single parameter (the number of sent notification) at the start, we could then think about a way of making this more configurable.
- Tag - which tag should be digested by this configuration.
DigestSubscription
This entity would let each of the user to decide whether or not they would like to use each of the digest configurations.
Activity diagram
Below is the activity diagram describing how notification would deal with digesting notifications and sending them daily. It is split into 4 workflows (from left to right):
- Registering a digest configuration. This step is done by the service and provides possible notification consolidation options.
- A user subscribing to a specific digest configuration. From this step, the user will no longer receive the notifications for a specific tag as they come but in a form of a single, digested notification.
- Notification receiving a notification to send. This workflow deals with deciding whether to send the notification immediately or store it to be digested.
- Notification coursing through the digest configuration and sending messages for all the subscribers when the time is appropriate.