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 in managed.json to something other than _notifications, you must also update the corresponding reversePropertyName in internal.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.

Read a different version of :