AlertProcessor

AlertProcessor is a microservice that is responsible for sending Genesys Pulse Advanced Alert emails. When AlertProcessor detects that some Advanced Alert condition have changed its value it waits for the alert delay interval and then executes the alert action.

AlertProcessor sends emails in the following cases:

* Advanced Alert condition changes it's value from the no-alert value (null, false, 0, empty string, etc.) to some alert value. In this case the Alert is triggered.
* Condition changes it's value from one alert value to some other alert value (e.g. from 1 to 3, from "Elevated" to "Severe"). In this case the Alert remains triggered, but AlertProcessor sends email notifying about the change of alert condition value.
* Condition changes it's value from alert value to a no-alert value. In this case the Alert is reset.

This is an example of an email that AlertProcessor sends: {noformat} Subject:

Alert "TooManyInternalCalls" in widget "Agent Calls" was triggered for 5 and reset for 1 object(s)

Text:

Alert "TooManyInternalCalls" in widget "Agent Calls" was triggered for 3 and reset for 1 object(s)

Alert was triggered for the following objects:

- Emily Peterson: condition value has changed from false to true - John Smith: condition value has changed from false to true - Peter Johnson: condition value has changed from false to true

Alert was reset for the following objects:

- Anthony Small: condition value has changed from true to false {noformat} You need to have AlertProcessor configured and running in order to receive Advanced Alert emails.

• Configuration*

AlertProcessor depends on other Pulse microservices. These microservices should be properly configured and running:

* StatServerDataProvider
* FormulaProcessor
* WidgetWatcher
* UserPermissions

AlertProcessor also requires an external SMTP server to be available for sending emails.

AlertProcessor itself is configured using *alertprocessor.properties* configuration file. It should be placed in a directory with AlertProcesor jar file. There are several configuration options that can be specified in alertprocessor.properties file. The following configuration options must be filled:

* *aeron.driver.directory*
Directory used by aeron driver. On linux it is better to use a directory inside /dev/shm/.
_Valid values_: Path to a directory
* *email.from*
Email address that will be written in "from" field of emails sent by AlertProcessor
_Valid values_: Email address
* *email.smtp.host*
Host of an SMTP server to be used to send emails
_Valid values_: hostname or an ip address
* *email.smtp.port*
Port of an SMTP server to be used to send emails
_Valid values_: positive integer
* *service.widgetwatcher.servers*
WidgetWatcher service instances defined by host and port pairs in a comma separated list
_Valid values_: comma separated list of host and port pairs
* *service.userpermissions.servers*
UserPermissions service instances defined by host and port pairs in a comma separated list
_Valid values_: comma separated list of host and port pairs
* *service.statserverdataprovider.aeron.control*
StatServerDataProvider aeron control address.
_Valid values_: Host and port pair
* *service.formulaprocessor.aeron.control*
FormulaProcessor aeron control address. Host and port pair.
_Valid values_: Host and port pair
* *storage.h2.directory*
Path to a local directory where AlertProcessor can store the data that will be persisted during service restarts
_Valid values_: Path to a directory

There are also some other options that can be used to tweak the way AlertProcessor works:

* *limits.alert_queue*
The maximal allowed size of an alert queue. If size of the queue with Alerts waiting to be reported reaches this value then new Alerts will be dropped and users won't receive emails for dropped alerts.
_Valid values_: Positive integer
_Default value_: 500000
* *log.level*
The log level. Note that logging can be customized further by supplying a full log4j.xml file. To use a custom log4j.xml configuration file pass -Dlog4j.configurationFile=<path to an xml file> when starting AlertProcessor. When customizing the log4j.xml file it is strongly advised to use AlertProcessorLayout as a layout for every file appender because it supplies a header with application version info. Look at the log4j.xml file inside AlertProcessor jar to see how to use it.
_Valid values_: One of log4j log levels
_Default value_: INFO
* *processor.alert_group_interval*
Alert grouping time interval in seconds. This allows to group more alerts into a single email. The bigger the value the more alerts will be reported in a single email and the bigger the alert delay.
_Valid values_: Positive integers
_Default value_: 5
* *processor.retry_alert_action_after*
Number of seconds to wait before trying to redo the alert action.
_Valid values_: Positive integers
_Default value_: 2
* *service.widgetwatcher.reconnect_interval*
WidgetWatcher reconnect interval in seconds.
_Valid values_: Positive integer
_Default value_: 10
* *service.userpermissions.expire_cache_after_seconds*
Number of seconds after which an entry in user permissions cache expires
_Valid values_: Positive integers
_Default value_: 240
* *service.statserverdataprovider.aeron.channel*
StatServerDataProvider aeron channel full specification. Should be used if a channel with a single control specification is not enough. Control address option is ignored if this option is filled.
_Valid values_: Aeron channel definition
* *service.formulaprocessor.aeron.channel*
FormulaProcessor aeron channel full specification. Should be used if a channel with a single control specification is not enough. Control address option is ignored if this option is filled.
_Valid values_: Aeron channel definition

• How to run*

AlertProcessor is shipped as a java jar file with  a simple run_processor.sh file that can be used to run it.

• Limitations*

* AlertProcessor does not currently support any authentication with SMTP server.
* AlertProcessor does not currently provide High Availability.
* AlertProcessor does not guarantee that some Alert email won't be sent twice, but it will send a single alert email in most of the cases
* AlertProcessor has a bigger priority on sending emails for triggered alerts. In some cases the emails about reset alerts won't be sent:
** When Alert is removed from widget, the reset emails won't be sent for all the objects this Alert was triggered for.
** When Widget is deleted, the reset emails won't be sent for all the already triggered alerts in this widget.
** When object is removed from widget, the reset emails won't be sent for all the Alerts that were triggered for this object.