The notification system supports sending messages via:
Notification type tells, which channel (⇒ which notification sender) will be used, when notification with given type will be send.
email
- default sender emailNotificationSender
(leads to DefaultEmailNotificationSender
implementation).websocket
- default sender websocketNotificationSender
(leads to DefaultWebsocketNotificationSender
implementation).sms
- no sender is configured by default. Sender implementation has to registred by custom module and then configured.console
- default sender consoleNotificationSender
(leads to DefaultConsoleNotificationSender
implementation).
Sender names above can be used in sender configuration in impl
property, this ones are configured by default.
A notification (with 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).
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. Consumers 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.
A concrete implementation of the notification sender via email (a wrapping of the camel emailer
).
Emailer
(or rather EmailNotificationSender
) 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 (recommended) by entering the user name instead of the recipient's (or sender's) email address.
The emailer can be configured via application.properties or application settings agenda. A functional testing emailer settings.
If you want to test some project specific feature with sending email you can use AbstractNotificationTest
, this class allow setup your own SMTP server (port and etc.), class allow add your own implementation of Observer, or is possible to use this implementation: NotificationObserver
with solved concurrent thread.
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.
Sending messages is done by NotificationManager
, which inherits from NotificationSender.java
. In class NotificationSender
we can find overloaded methods send
, which are used for sending notifications.
The priority of evaluation is as follows:
send
. Even if there was a template, the directly filled-in text is used
Senders are configurable thanks to interface Configurable
via the standard application configuration. More than one implementation of notification sender for one notification type can be installed into CzechIdM. We need to configure, which one is used, when notification with given type is send. Sender with the lowest order is used as default. Core senders using order 0.
impl
. Any module can be registered in this way and also the behaviour of the existing senders, which are implemented via interface NotificationSender
, can be changed.
Everything is explained in the following examples:
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);
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);
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.