Alerts - Architecture and mechanism

The alerts are stored in a local Apache Cassandra. You can create, edit or delete them from the alerts.html page which communicates with the Alerts servlet. This servlet creates a connection towards the database with the info contained in the alerts.properties file.

An alert is composed of seven fields:

• an _id created by the Cassandra,
• a keyword which will be used to make the request on the solr core,
• the core on which the query will be made, default : FileShare,
• a frequency: Hourly, Daily or Weekly. Frequency changes the time lapse between two requests but also the recency of the documents returned.
• a mail to which the results (if any) of the query will be sent,
• a subject which describes the subject of the email
• a user: the one who created the alert in the UI. It is only used for now to allow for the monitoring of the alerts by the admin and the search expert.

The alertsAdmin UI and servlet are used to modify the alerts.properties file. It is used to:

• configure the initial delay of the execution of the alerts of a specific frequency,
• print the date of the previous execution
• print the date of the next planned executions.
• configure the mail address from which Datafari will send its emails.
• configure the host and port of the Cassandra and the name of the Database and of the collection where the alerts are.

The AlertsManager class is a Singleton and is called at each start/stop of the server by the StartAlertsListener.

At each start it reads the alerts.properties file to fill its own fields, and check if the alerts were on or off at the end of the previous execution of Datafari. If it was on On, the alerts Manager schedules the task according to the dates in the file. However if those are invalid, it will calculate the delays according to the original execution schedule of the alerts.

For instance the hourly alerts are set to begin at midnight, if everything is going smoothly, the hourly alerts will run at 00:00 then at 01:00 and so on. Now let's say that the date was already past at the start of Datafari. Then the AlertsManager will plan the execution for the next expected hour.

This allows the alerts to be run regularly, even after one or more restart of the server.

In order to run an alert:

• the AlertsManager creates a connection with the Cassandra database at each execution
• the AlertsManager then retrieves all the alerts with the matching frequency.
• For each alert, the AlertsManager creates an Alert object, and delegates the execution to them.
• An object alert will use its attributes to make a solrQuery
• If the solrQuery contains results, it will use the email object passed at its creation to send a mail. To avoid re reading of the alerts.properties file for each alerts, this object is initialized in the alerts manager and passed as a parameter to the Alert constructor. If the configuration file is modified through the admin UI, Datafari will automatically restart the alerts, if it is manually modified, you will need to turnOff/turnOn the alerts in the alertAdmin UI to take into account the modifications.