Skip to main content
Version: 1.13.0

Notifier API

Overview

Notifier reponsabilities:

  • Manage rules and recipients configuration,
  • Send notifications to external users or components according to its configuration.

At the moment, 2 API are available :

  • A REST API to manage configuration,
  • A messaging API (AMQP) for the receipt of the requests to be processed.

Notifier architectural concepts

This microservice receives requests from Feature manager and Ingest.

All requests are then processed as they arrive:

  • All rules are applied to all requests in order to identify target recipients,
  • Notifications are then sent to these recipients.

Under the hood, all the real work is done by the plugins :

  • Plugins to manage the rules for dispatching notifications by recipients,
  • Plugins to make the notification.
note

Format of the notification is totally free as the notification is fully delegated to a plugin.

AMQP API

Send an event to notifier

Message has to be published on this exchange : regards.broadcast.fr.cnes.regards.modules.notifier.dto.in.NotificationRequestEvent

With following properties:

PropertyType
metadataA free JSON element
payloadA free JSON element

And following headers:

HeaderValue
regards.tenantThe tenant
regards.request.idString of max 36 characters long
regards.request.dateISO 8601 date
regards.request.ownerString of max 128 characters long

Integration with Feature Manager and Ingest

Creations, updates or deletions of features or AIPs are optionnaly sent to Notifier, this consist of the payload.

metadata is a field allowing Ingest or Feature Manager to send additionnal information to Notifier that rules and notification plugins might use or require.

Template of notified feature

{
"metadata": "{whatEverIsNeededOrWanted}",
"payload": "{feature}"
}
Migration from 1.4 to 1.5

Notification format using RabbitMQSender plugin has been updated between version 1.4 and 1.5:

  1. element has been renamed to payload
  2. action has been moved into objet metadata and is now located at $.metadata.action instead of $.action

Notification management

How to retry notifications that failed

To retry notifications that failed, you need to send a new AMQP event with the same regards.request.id header.

  • If your event does not contain any body, it will retry the same event
  • If you provides a body, it will be taken into account before retrying.