7.3:dev:notification

← Logging  
 Notification templates →

Notifications

TODO: Extend the introduction

The notification system supports sending messages via:

  • Email
  • SMS
  • WebSocket
  • ESB - coming soon
  • …

Notification system functions:

  • One message can be sent in more ways (e.g. according to the configuration of a user's account) or sent by a specific channel.
  • Messages are saved into the database - there is a notification agenda available for the application administrator
  • Sending messages can be disabled by configuration (e.g. for testing purposes)
  • If the recipient of the given notification isn't entered (e.g. a blank email), a record of not sending the notification is done in the log with level information

A notification (message) is represented by entity IdmNotification, which keeps information about the notification itself (from, recipients, cc, bcc, subject, message, sent date). From the entity IdmNotification can be inherited by individual more specific types of notifications (i.e. IdmEmail). A notification for the identity is sent via service NotificationService. It is also possible to use a specific way of sending the notificaction, e.g. via EmailService, if the application requires it (e.g. from workflow). For saving the IdmNotification entity serves IdmNotificationRepository, which makes records via rest for the notification agenda accessible.

Sending of notificanions itself is done by Apache Camel. The producer (ProducerTemplate) registers the notification (via NotificationService) - the route setting deals with propagating of the notification to concrete consumers (EmailService …), which send the notification and make a record in the db (IdmNotificationRepository) and the log. Comsumers can be implemented via ConsumerTemplate or spring beans (preferred spring bean).

Apache Camel is used not only for the above mentioned reasons but it also supports sending of emails, SMSs, websockets and jms.

Emailer

A concrete implementation of the notification sender via email (a wrapping of the camel emailer). Emailer (or rather EmailService) is also injected into the workflow engine in order to be able to turn off sending of notifications for testing purposes. It is also possible to send emails for a specific identity by entering the user name instead of the recipient's (or sender's) email address.

Emailer settings

The emailer can be configured via application.properties or application settings agenda. A functional testing emailer settings.

Sms

Currently there is a support for sending sms messages from IdM, but administrator must provide concrete implementation of sender for particular sms gateway. This can be done by extending AbstractSmsNotificationSender and registering this implementation in application context.

Note that there should be only one implementation of AbstractSmsNotificationSender registered in application context at a time, since there is currently no way of telling the IdM which sender for particular type should be used.

Sending notification and processing

Sending messages is done by NotificationManager.java, which inherits from NotificationSender.java. In class NotificationSender.java we can find overloaded methods send, which are used for sending notifications.

The priority of evaluation is as follows:

  1. The text is filled directly into method send. Even if there was a template, the directly filled-in text is used
  2. sending the template directly via IdmMessage into method send, overwrites the template used in configuration
  3. sending the template via topic. The template will be substituted from IdmNotificationConfiguration

Examples

Everything is explained in the following examples:

number 1.

notificationManager.send(
	AccModuleDescriptor.TOPIC_NEW_PASSWORD,
	new IdmMessage.Builder()
		.setLevel(NotificationLevel.SUCCESS)
		.addParameter("systemName", provisioningOperation.getSystem().getName())
		.addParameter("uid", provisioningOperation.getSystemEntityUid())
		.addParameter("password", password)
		.setSubject("I cannot be stopped")
		.setMessage("Hi, I'll overwrite everything!!")
		.build(),
	identity);

number 2.

notificationManager.send(
	AccModuleDescriptor.TOPIC_NEW_PASSWORD,
	new IdmMessage.Builder()
		.setLevel(NotificationLevel.SUCCESS)
		.addParameter("systemName", provisioningOperation.getSystem().getName())
		.addParameter("uid", provisioningOperation.getSystemEntityUid())
		.addParameter("password", password)
		.setTemplate(template)
		.build(),
	identity);

number 3.

notificationManager.send(
	AccModuleDescriptor.TOPIC_NEW_PASSWORD,
	new IdmMessage.Builder()
		.setLevel(NotificationLevel.SUCCESS)
		.addParameter("systemName", provisioningOperation.getSystem().getName())
		.addParameter("uid", provisioningOperation.getSystemEntityUid())
		.addParameter("password", password)
		.build(),
	identity);

If there is no message and template, the notification will not be sent. A notification log will be saved instead saying that message content doesn't exist.

Future developement

  • It will be possible to configure a testing receiver, where notifications will be sent to instead of the original one.
  • Sending a notification will be tied to the configuration of the given entity, which will give the way of sending the notification (channel).
← Logging  
Notifications  
 Notification templates →