The event-driven processing feature allows any system event (e.g. the publication of a report, a system error, a server being restarted) to trigger email notifications to be sent to a specified list of users (both local and remote (internet)). Any message or attachment can be included with the notification, and an event can be set to trigger other events if required (e.g. a data load might trigger a report to be run). The list of messages and users to be notified is maintained in a series of database tables. When a server-side task, such as loading data into a data warehouse, is completed, it triggers an event with a specific code. The event is then broadcast to a list of specified users that are subscribed to receive the event.

The goal of the Expresso event system is to send email messages to a specified number of people when a specified event occurs. The configuration of the Event system is done through database tables, while the triggering of an Event can take place in one line of code. Events are always asynchronous, and depending on how the system administrator sets up the website, when events are triggered, it is possible that nothing will happen.

An example of an event is a system error - this is a pre-defined event that comes with the system. This event can then have a list of users associated with it that get notified when the event occurs, in the case of a system error, you would probably want to notify your system administrator.

The developer then simply has to specify that an event is triggered and the appropriate notifications are sent out automatically by the system.

Every event is either "successful" (such as a load completing correctly) or "unsuccessful" (such as a load aborting due to a database problem). Successful events can have a different group of users from unsuccessful events - for example, a number of people might want to know that the data load is completed, but you might want to tell the system administrator only if the load fails. Of course, the same people can also be notified of both success and failure if so desired.

The Event configuration tables can be reached through the Operations page from the main Expresso frame. The two tables are:

The Event Definitions table is fairly straight forward. The two fields are event name and event description. A pre-built example is SYSERROR which has the description of "System Error." The name SYSERROR is the name of the event that gets triggered in code as will be demonstrated shortly.

The Event Email Recipients contains the rest of the Event configuration information. When adding a new recipient, you decide on who to send the notification to, what event, and why. For SYSERROR, for example, you could select "System Error." from the dropdown box for Event code, and 3 for the user ID (Usually Administrator).

Now the last part of the Event Email Recipient is a little bit different. Each Event has a status associated with it: Success or Failure. For example, if a user successfully downloaded a file, the download controller could trigger a DOWNLOAD event with a success status, whereas if the connection died for some reason, the download controller could trigger a DOWNLOAD event with failure status. Each of these statuses is configurable with who gets what notifications. For example, you could send a DOWNLOAD success event to an automated mail archival system for statistical reference, while you would want to send failure events to the administrators so they can see if there are an unusual number of failures occurring.

You can trigger an event from code with very little code:

import
  com.jcorporate.expresso.core.misc.EventHandler;
  EventHandler.Event("default", "SYSERROR","Successful
  Test Message", true);

EventHandler.Event is an asynchronous call. If you watch the runtime logs, you will see the mail going out a few seconds after the call. The parameters for the call are:

The framework has email integration as part of its base feature set. Instead of the application programmer having to develop his/her own email notification system, there is a base level email integration built right in. From that base email class, there are several different classes that make use of the email notification class.

Some facilities provided for email include:

EventHandler.notify(dataContext, // the database context
  tSubscribe.getFieldInt(ThreadSubscribe.FLD_UID), // the user id to send
  email to msgSubject, // the email subject message); // the email message