Notification Engine

The ITSM Notification Engine provides a back-end workflow model for defining which notifications should be sent, based on events in the application. To configure notifications, the primary option provided with BMC Helix ITSM is exposed on the People form for support staff. Additional behind the scenes configuration is available through back-end forms, but you must understand how all of the pieces fit together before attempting these types of changes.

Primary functions

The Notification Engine provides the following primary functions:

• Determines notification recipients (group or individual)
• Specifies the notification text
• Initiates the notification delivery (email notifications for desktop clients and push notifications for mobile clients)
• Logs the notification details

For more information about the Notification Engine, see Configuring the Notification Engine.

Architecture

The BMC Helix ITSM notification subsystem is available to all BMC Helix ITSM applications and is connected to the Email Engine provided with AR System.

The following major components make up the notification subsystem architecture:

• System Events and Message Catalog—Defines notification events and notification text.
• System process control—Processes each notification event received from various BMC Helix ITSM modules.
• Notification interface—Sends the formatted notification (alert, email, mobile).
• Notification audit—Audits each notification that is visible from the BMC Helix ITSM modules.
• Configuration settings and user preferences—Manages system default notifications and user notification preferences.

Notification transaction process

A notification transaction uses the major components of the Notification Engine, as shown in the following figure:

The NTE:SYS-NT Process Control form is the center of the Notification Engine. All notifications are pushed to this form first. Depending on which parameters are included, it determines whether the notification is a group notification or an individual notification. Calling applications pass this information to the NTE:SYS-NT Process Control form. This information includes details such as the application, the recipient of the notification, and information about the parent record.

1. Escalations are run to process the pending notification events. 
   The application uses the 1, 2, and 3 out-of-the-box escalation pools  to enable multithread processing for the records contained in the NTE:SYS-NT Process Control form.

   Important

   Escalation pools are enabled through the AR System Administration Console. BMC Helix ITSM does not set the pooling automatically, so the AR System administrator must configure the escalation pools before running the notification process. If you do not properly configure the escalation pools, all escalation workflow runs within escalation pool 1.

   A single record created in the NTE:SYS-NT Process Control form is used for both group and individual notifications. All group and individual notifications are processed asynchronously.

2. SYS:NPC:TriggerGroupNotifications runs every minute against the NTE:SYS-NT Process Control form for group notifications. This escalation runs within escalation pool 3.
   • SYS:NPC:TriggerNonGroupNotifications runs every minute against the NTE:SYS-NT Process Control form for individual notifications. This escalation runs within escalation pool 2.
   • SYS:NPC:ProcessHeldNotifications runs every 11 minutes to process records held for business hours. This escalation runs within escalation pool 1.
3. Individual processing gets the user's notification preferences, ticket information, and message from the Notification Messages catalog. Group processing expands the group list to individuals, and then runs the individual process.
4. The NTE:Notifier sends the notification using the appropriate method (email or alert). If the notification is through email, NTE:Notifier workflow creates a record in the AR System Email Messages form, which is processed by the Email Engine.