Project Open Custom E-Mail Notifications - Part 5

In Parts 1-4, I presented the concepts that I could exploit to build a Project Open e-mail notification system. In Part 5, I'll present the actual application, which I've affectionately called PONotificationsBuddy. You can download version 1.0.0 here. Or you can visit the SourceForge project page here. I used Netbeans 7.0 to build the application, and I left the nbproject folder intact. If that doesn't mean anything to you, you shouldn't worry. I think you can safely ignore it and use Eclipse or your favorite Integrated Development Environment (IDE). Or vi if you're adventuresome!

Before you look at the code, please let me apologize. I code in whatever language makes sense at any given moment in time. That means I can code in a lot of languages, but I'm not outstanding in any. In my defense (and to the great annoyance of my detractors), my code does have a tendency to both run and be friendly to the people who have to later maintain the code. To me, that's the definition fo success. A Java purist will probably be horrified at my code; just as a Visual Basic genius would be aghast at my VB code. But, to each their own! And if you really, really hate my Java implementation of PONotificationsBuddy, at least I've given you the queries and other background information that you can use to build a better implementation!

If you unzip the code, it should great a PONotificationsBuddy directory with a number of subdirectories. First, look in the Scripts directory. You should see four files:

1. pona_notifications_sent.sql: This script will create the PostgreSQL table that'll track what e-mails have already been sent.
2. stage1.sh: This is the script that you'll run to execute the program. It'll take care of invoking the PostgreSQL scripts (see the next entries) and executing the Java program PONotificationsBuddy.
3. stage1.sql: This is the SQL described in a previous article. It will extract the tasks that are currently open.
4. stage1b.sql: This is also described in a previous article. This query brings back newly closed items.

Another important directory is src. It contains the Java source code and properties files. If you look in src, you'll see two packages:

1. ponotificationsbuddy: This contains the Java Main class that controls the Java program. That program, Main.java, contains one loop that'll process the open items and a second loop that processes the newly closed items. This directory also contains the two property files, which are PONotificationsBuddy.properties and Spectator.properties.
2. com.interstell.PONotificationsBuddy: This contains the helper classes that the Main class leverages.

Let's walk through how this would run after it's compiled and installed in /web/projop/filestorage/apps/PONotificationsBuddy:

Note: You can configure the actual installation directory by adjusting the *.sh files and the properties files. For the purposes of consistency, I'll use /web/projop/filestorage/apps/PONotificationsBuddy for this example.

1. stage1.sh: Either invoked by cron or from the command line, stage1.sh will run the query contained in stage1.sql and will output the results to a file called stage1.output. After that, it'll run the query contained in stage1b.sql and place the results into stage1b.output. Once the results are available, stage1.sh invokes the application PONotificationsBuddy, which is contained in a single jar. Note that PONotificationsBuddy requires the location and name of its properties file as an argument.
2. PONotificationsBuddy.jar: This Java Main application sets some constants that'll help it read and parse the two output files. After verifying that the properties file (PONotificationsBuddy.properties) is present, it reads the properties into variables for easier use. The Java Main class then creates three helper objects: SentEmailUpdater, MailSender, and SpectatorEmailProcessor (the creation of which includes the step to read the Spectator.properties file) before it begins parsing the first output file (stage1.output). Using a StringBuffer to create the e-mail body, it invokes MailSender to actually sent the e-mail.
3. MailSender.java: This is a simple program whose guts I more or less borrowed from Tutorials Point. It basically sends the e-mail where it's directed to send it.
4. PONotificationsBuddy.jar: After sending the e-mail via MailSender, the Main program makes a note of the task ID that represents the open task for which it just sent an e-mail. It notes that task ID using the helper class SentEmailUpdater.
5. SentEmailUpdater.java: This program is responsible first for keeping a running list of the task IDs for which e-mails have been generated and second for making sure it doesn't track the same task ID twice. The table that tracks the task IDs has a unique key contraint on the task ID column, so an attempt to insert the same ID twice would generate an error. SentEmailJavaUpdater uses a HashMap to track the IDs it's working on.
6. PONotificationsBuddy.jar: The e-mail has been sent and the ID tracked. The last function to perform is to see if any spectator e-mails need to be sent. It invokes SpectatorEmailProcessor's checkSpectators method to do that.
7. SpectatorEmailProcessor: The file Spectator.properties defines what workflows and what steps generate a spectator e-mail. A spectator is someone(s) who will receive an e-mail even through the workflow step is not assigned to them or a group to which they belong. At initialization, this class reads its properties file into a HashMap so it can quickly search the workflow/step definitions. If the current workflow/step is eligible, it will use the MailSender class to send an e-mail.
8. PONotificationsBuddy.jar: After cleaning up the objects it used to read the open items file, PONotificationsBuddy reads the newly closed items from stage1b.output and conducts the same steps for it that it did for stage1.output. Finally, it invokes SentMailUpdater's writeOutputFile method.
9. SentEmailUpdater.java: This class, as you may remember, has been busily tracking the task IDs representing the open or newly closed items for which PONotificationsBuddy has generated an e-mail. Its method writeOutputFile will write a PostgreSQL script that'll insert these items into the tracking table, pona_notifications_sent.
10. stage1.sh: Now that PONotificationsBuddy is done, stage1.sh is back in control. It invokes the psql command line to execute the script that SentEmailUpdater wrote (stage2.sql).

And that's all there is to it!

In the next section, I'll cover how to install the code onto a running Project Open server.