Integrated Notification Broadcast
Introduction
The JSLEE provides a common notification interface common to all applications that generate notifications. Notifications in this sense refers to application-specific occurrences that generate JSLEE-internal events that can be consumed by other JSLEE applications. These destination applications may then decide to generate external events or notifications or perform other processing as required.
To configure a JSLEE service to have notification support, add the notification
configuration
section to the application’s JSLEE configuration, e.g.:
{
"applications": {
"app1": {
"configuration": {
"notification": {
"enabled": true
The notification
section can also be inserted into the global configuration, e.g.:
{
"notification": {
"routing-rules": [
<notification routing rules>
]
},
"applications": {
"app1": {
"configuration": {
"notification": {
"enabled": true,
Global notification configuration will apply to all services, but parameters specified at the service level will override those defined at the global level.
If no notification
configuration is provided at all or if the enabled
flag is either
not present or set to false
, no notifications will be generated by the application.
Routing Rules
The primary configuration for notifications is the routing-rules
section. This is an
array of rules that are tested for generated notifications to determine their destination(s),
if any.
Rules will be applied in order and continue through all rules unless explicitly told
to stop by the terminal
flag.
Notifications that do not match any routing rules will be silently consumed within the generating application and will not be on-sent.
The available parameters for routing rules are:
Field | Type | Required? | Default | Description |
---|---|---|---|---|
name |
String | Yes | - | A distinct name for this rule to identify it in log output. |
terminal |
Boolean | No | false |
If this rule matches and terminal is set to true , no further rules will be applied. |
destinations |
Array of String | Conditional | - | The JSLEE application addresses to send matching notifications to. One (and only one) of destination and destinations must be configured. |
destination |
String | Conditional | - | Shorthand for destinations with a single value. One (and only one) of destination and destinations must be configured. |
match-types |
Array of String | No | - | The string value to match for a generated notification’s type , as set out in the application documentation. |
match-type |
String | No | - | Shorthand for match-types with a single value. Up to one of match-type and match-types may be configured. |
match-subtypes |
Array of String | No | - | As for match-types but for a generated notification’s subtype . |
match-subtype |
String | No | - | Shorthand for match-subtypes with a single value. Up to one of match-subtype and match-subtypes may be configured. |
If no match-type
, match-types
, match-subtype
, or match-subtypes
are configured, the rule will match all notifications.
An example routing rule set might be:
{
"notification": {
"enabled": true,
"routing-rules": [
{
"name": "First Rule",
"destination": "app1",
"terminal": true,
"match-type": "Type 1",
"match-subtype": "Subtype 1"
},
{
"name": "Second Rule",
"destinations": [
"app2",
"app3"
],
"match-types": [
"Type 2",
"Type 3"
]
},
{
"name": "Third Rule",
"destination": "app4"
}
]
}
}
These rules say:
- For notifications of type
Type 1
and subtypeSubtype 1
, send the notification to the addressapp1
and do not apply any further rules. - For notifications of type
Type 2
orType 3
, send the notification to the addressesapp2
andapp3
and process further rules. - For all notifications, send the notification to the address
app4
.