The notification architecture uses a synchronous model of notifying the notification handlers. FIM CM processing for the given operation is suspended while the notification handler is executing. Multiple notification handlers configured for the same event will be executed in succession. It should also be mentioned that notification handlers execute in the context of the FIM CM process thread. They should therefore avoid long timed activities which will impact the response times to client. In most cases, if the data from a notification object does not require immediate action, it is best to simply log the data to a file, or send it in an e-mail, so that it can be processed later.

In addition, FIM CM notifications are one-way events delivered from the FIM CM server to notification system. They are forwarded to each registered subscribing notification handler. Notification handlers do not communicate back to the FIM CM server.

To send notifications, the FIM CM Notification system must have information about subscribers and the events that the subscribers are interested in receiving. Multiple notification subscribers may subscribe for the same event. In this case, notifications are delivered in the same order as the notification handlers are registered. The same notification subscriber can register for multiple FIM CM event notifications. In this situation, FIM CM creates a new instance of the handler class for each subscription.

Subscription management is performed by registering the notification handler in the FIM CM’s web.config configuration file. Each notification handler should implement the INotificationSink interface. All events require the notification subscribers to implement the INotificationSink interface.

FIM CM notification handlers can leverage the programming model of the FIM CM Provision API to obtain additional information for the notification data received. For example, the notification handler receives a request Guid corresponding to the request associated with the current operation. The notification handler can then call GetRequest to load the request object for that request.

Notification event types are described in NotificationType. Depending on the type of event you are working with, Notification handlers may fire under different circumstances. For instance, some event types trigger only for software certificate profiles (such as DownloadPfx), some events trigger only for smart card operations (such as SmartcardPinRolloverExecute, SmartcardPrint, and SmartcardAssignCard), and some event types trigger for both (such as CreateRequest, CancelRequest, and ApproveRequest). One should also bear in mind that the same notification event may trigger in multiple situations. For example, a CreateProfile notification will fire during the execution of numerous different request types (such as EnrollProfile, RecoverProfile, and DuplicateProfile).