Service - Notification Manager: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
No edit summary |
||
Line 43: | Line 43: | ||
: optional (? might have to set something) key that specifies a unique notification group within the receiver's grouping id | : optional (? might have to set something) key that specifies a unique notification group within the receiver's grouping id | ||
: eg: a uuid created by UserContactManager | : eg: a uuid created by UserContactManager | ||
; notificationGroupName | |||
; | : string name set by reciever service, optional | ||
: | ; consolidated | ||
: true|false | |||
; consolidatedType | |||
: overview|detailed | |||
; consolidatedFrequency | |||
: not sure, maybe use some sort of standard like cron | |||
; consolidatedNextSendDue | |||
: timestamp for next due time to send notification | |||
; consolidatedSendIfEmpty | |||
: true|false | |||
== Notifications == | |||
* no sort key | |||
=== Fields === | |||
; notificationId | |||
: (partition key) | |||
: random UUID | |||
; notificationGroupId | |||
; serviceName | |||
; msgTag | |||
; triggers | |||
: array/list of triggers that must match for this notification to happen, see [[#Triggers structure]] | |||
= Triggers structure = | |||
Record of the triggers for a notification, saved in Notifications table | |||
<syntaxhighlight lang="JavaScript"> | |||
[ | |||
{ | |||
"property": {can be a nested property, use dot notation} | |||
"value": {string or number} | |||
"values": {array/list of values} | |||
"meta": true|false // default false, if true will search message attributes or other special cases like msgTag | |||
}, | |||
.. | |||
] | |||
</syntaxhighlight> | |||
* either value or values is set, not both | |||
= Consolidated notifications = | = Consolidated notifications = | ||
Line 53: | Line 95: | ||
* .... | * .... | ||
* maybe can use some sort of queue to store a list of NotificationGroup’s that are due to be sent (either because consolidatedSendIfEmpty == true or there are some activities waiting to be processed) | * maybe can use some sort of queue to store a list of NotificationGroup’s that are due to be sent (either because consolidatedSendIfEmpty == true or there are some activities waiting to be processed) | ||
= Formating notifications = | |||
* Initially the format will be hardwired and simple, but in the future we could create templates for formating the notification body | |||
= Working documents = | = Working documents = |
Revision as of 10:34, 8 November 2020
Overview
Consolidates and sends notifications to any number of receiver services. Will be used for user notifications but can have other types of receiver services added. Activities are received from Activity Switchboard service.
Notification groups set whether activities are considated (eg per day/per month/per x number of activities), if considated activities are stored here until sending is triggered, according to the considation rules. If not consolidated they are sent on immediately.
Repository
https://bitbucket.org/stb_working/notification-manager/src/master/
DynamoDB tables
Standard Config Table Per Service
Configuration tags
- configKey = receiver, configTag = {receiverTag}
- configValue example
{
// .. other method level configuration options, eg max length of notification body
"endpoint": {
"endpoint": {eg: Lambda function name}
"service_type": {eg: "Lambda"} //service type tag, at the moment only "Lambda"
}
}
NotificationGroup
- Groups many notificatons into groups
- Simplifies management of similar notifications
- Allows for consolidation of notifications at notification group level
Fields
- notificationGroupId
- (partition key)
- comes from: {receiverTag}_{grouping id given be receiver service}
- eg: userId or userId+methodTag hash
- receiverSortKey
- (sort key)
- optional (? might have to set something) key that specifies a unique notification group within the receiver's grouping id
- eg: a uuid created by UserContactManager
- notificationGroupName
- string name set by reciever service, optional
- consolidated
- true|false
- consolidatedType
- overview|detailed
- consolidatedFrequency
- not sure, maybe use some sort of standard like cron
- consolidatedNextSendDue
- timestamp for next due time to send notification
- consolidatedSendIfEmpty
- true|false
Notifications
- no sort key
Fields
- notificationId
- (partition key)
- random UUID
- notificationGroupId
- serviceName
- msgTag
- triggers
- array/list of triggers that must match for this notification to happen, see #Triggers structure
Triggers structure
Record of the triggers for a notification, saved in Notifications table
[
{
"property": {can be a nested property, use dot notation}
"value": {string or number}
"values": {array/list of values}
"meta": true|false // default false, if true will search message attributes or other special cases like msgTag
},
..
]
- either value or values is set, not both
Consolidated notifications
How to trigger processing for time based consolidations
- ....
- maybe can use some sort of queue to store a list of NotificationGroup’s that are due to be sent (either because consolidatedSendIfEmpty == true or there are some activities waiting to be processed)
Formating notifications
- Initially the format will be hardwired and simple, but in the future we could create templates for formating the notification body