Configuring Alerts
This topic describes how to configure a production to alert users about important events, such as events that require user intervention.
About Alerts
An alert sends notifications to applicable users while a production is running, in the event that an alert event occurs. The intention is to alert a system administrator or service technician to the presence of a problem. Alerts may be delivered via email or other mechanism.
The alert mechanism works as follows:
-
As part of the development process:
-
Within business host classes for the production, the developers include code that generates alerts when applicable.
For information, see Generating Alerts.
-
The developers define an additional business host class called an alert processor (also called an alert target). The alert processor contains the logic to contact each user in the most appropriate way.
The developers might also develop business operations for the alert processor to call.
For information, see Defining Alert Processors.
-
-
You configure the production to include the alert processor, along with any business services that it requires. For details, see the next section.
All alerts also write messages to the Event Log, with the type Alert.
Configuring an Alert Processor
Each time any alert is sent, the alert text is added to the Event Log. This mechanism might be too passive for the most urgent messages. If you want the production to also actively seek the user, you must define and configure a business host that has the ability to contact a user device. This business host is known as an alert processor or an alert target.
To add the alert processor to the production:
-
Add the business host class to the production. This class is a business operation or business process class, depending on its implementation.
-
For the configuration name, specify Ens.Alert
-
If the alert processor has settings such as email addresses and telephone numbers, configure those.
-
Add any business services that the alert processor calls.
Any production can include no more than one alert processor.
Configuring Alerts on Errors
A production can send alerts automatically whenever a business host encounters an error condition. The Alert On Error setting controls this behavior. If Alert On Error is True, then whenever the business host encounters an error, InterSystems IRIS triggers an alert.
Note that business hosts provide an optional grace period that enables the business host to retry before triggering the alert. Depending on the kind of business host, this grace period is specified by the setting Alert Grace Period or Alert Retry Grace Period.
Configuring Alerts on Queue Buildups
A production can send alerts when a business host’s queue has too many messages or has messages that have waited too long. To enable these alerts, specify the following settings with nonzero values:
-
Queue Count Alert—When the number of items in the queue exceeds this threshold, an alert is triggered. This alert has the prefix QueueCountAlert: (not localized). This alert is useful in situations where large queues are building up.
-
Queue Wait Alert—Length of time that a message can wait in the queue or be the active message before an alert is triggered. This alert has the prefix QueueWaitAlert: (not localized). This alert is useful in situations where a queue is not processing messages.
Other System Alerts
A production generates alerts on other occasions, including the following:
-
When a job is marked as dead.
This alert is prefixed with the non-localized text: DeadJobAlert: for simplified routing and handling.
-
When a business host is marked as inactive, according to its Inactivity Timeout setting.
-
When a business operation suspends its current message.
