Configure Notifications
The customizable notification service sends messages, based on changes to objects. The notification service uses filters to assess incoming requests. If the filter conditions are met, the service sends the corresponding notification. Notification messages are sent to whatever routes you specify, and include the "End User UI Notifications").
In a JDBC repository, notifications are stored in the notificationobjects
table. The notificationobjectproperties
, serves as the index table. In a DS repository, notifications are stored under the DN "ou=notification,ou=internal,dc=openidm,dc=forgerock,dc=com"
.
The notification service is enabled by default, and configured in your project's conf/notificationFactory.json
file. This file has the following structure:
{ "enabled" : true, "threadPool" : { "steadyPoolThreads" : 2, "maxPoolThreads" : 10, "threadKeepAlive" : 60, "maxQueueSize" : 20000 } }
To disable the notification service, thereby disabling all notifications, set "enabled" : false,
in notificationFactory.json
.
Important
Changing the notifications thread pool settings can adversely affect performance.
Notifications for a managed object are injected into a property in that object. The name of this property is specified in the managed object schema, in conf/managed.json
. For example, notifications for managed user objects rely on the following construct in the user
object definition in managed.json
:
{ "objects" : [ { "name" : "user", ... "notifications" : { "property" : "_notifications" }, ... }, ... ] }
This excerpt indicates that notifications are injected into the _notifications
property of the user object by default. The notifications
object is mandatory for notifications to be generated for that managed object type. However, you can change the name of the property that is injected into the managed object when notifications are generated. If you omit the property
field from the notifications
object, notifications are stored in the _notifications
field by default.
Important
The ability to tie a specific notification to its corresponding managed object is regarded as an internal object relation. Notifications are therefore also configured in
conf/internal.json
with the following object:{ "name" : "notification", "properties" : { "target" : { "reversePropertyName" : "_notifications" } } }
If you change the
property
field inmanaged.json
to something other than_notifications
, you must also update the correspondingreversePropertyName
ininternal.json
to reflect the change.Note
The internal object service does not support runtime changes. If you update
conf/internal.json
over REST, you must restart IDM for the change to take effect.If you have configured notifications for more than one managed object type, all the object types must use the same notification property name.