Events and notifications

Event-based subscriber notifications

The IAM modules Adminapp and Loginapp produce events on various occasions. Events are (Java) objects instances that are aimed to be processed asynchronously by an event subscriber. Any of the available events can be consumed by an Event Subscriber to send an e-mail, an SMS or forward information to a REST API.

Example

Example:
A User Locked event can be used to trigger an e-mail to inform an end-user that his or her account has been locked. The content of event-triggered e-mails may contain further information to inform and support the user.

By design, the event bus is limited to the boundaries of the module (Adminapp or Loginapp) as shown in the illustration below:

Note that:

An event must be consumed within the same module. It is impossible to produce an event in the Loginapp and consume it in the Adminapp.
Some events, e.g., User Locked, can be triggered by producers in both the Loginapp and the Adminapp. To consume all these events, separate subscribers must be configured in both the Loginapp and the Adminapp.
By default, events are not persisted, so they may be lost if an error occurs during processing or delivery. To prevent this, events can be stored in an outbox repository (e.g., a database table) and forwarded asynchronously to a message broker. This ensures reliable delivery, even in the presence of temporary failures. For more information, see Reliable event delivery.
Events are asynchronous. Once the producer creates the event, it will continue processing. No response is expected.
In the Loginapp, every flow step generates a Generic Step Result event upon completion. Since the Generic Step Result event is limited to flows, it is preferable to use more specific events if possible.