Evaluation System Email Notification Documentation

This document attempts to explain how notifications are sent for the Evaluation System in Sakai. It assumes that you have set ‘administrate’ > Control Email Settings > Send one email per student per evaluation. It does not attempt to explain the ‘consolidated’ aka ‘summary’ notifications.

When a new evaluation is created, there’s a chain of method calls# that eventually result in an entry being created in the table SCHEDULER_DELAYED_INVOCATION:

INVOCATION_ID INVOCATION_TIME COMPONENT CONTEXT 
782a8051-02b9-4eda-afc9-047f37266a1f 2013-03-15 14:58:00 org.sakaiproject.evaluation.logic.externals.EvalScheduledInvocation 97/scheduledActive 

The invocation time is set to the Start Date of the evaluation. The Context indicates the evaluation id (97) and what evaluation is scheduled to be sent - ‘scheduledActive’ means the ‘Available’ notification.

The ScheduledInvocationManager is a job that automatically runs in Sakai’s Job Scheduler. If you look, you’ll see that it will be listed in the log of events, but if you navigate to ‘Jobs’ it is not exposed there and there is no Trigger exposed through the GUI for you to schedule it.

The ScheduledInvocationManager automatically runs every 10 minutes, but you can make it more or less frequent with the sakai.properties setting: jobscheduler.invocation.interval=60. This setting is in seconds, so 60 would mean it would run every minute.
 
So, the next time the ScheduledInvocationManager runs, it looks in SCHEDULER_DELAYED_INVOCATION to see if there are any jobs where the invocation time has now passed. If so, it will call org.sakaiproject.evaluation.logic.externals.EvalScheduledInvocation and pass it the context.
 
If you look at ./impl/src/java/org/sakaiproject/evaluation/logic/scheduling/EvalScheduledInvocationImpl.java you will see the code that it calls. Once it has parsed out the evaluation id and the job type, it calls the method jobAction() in ./impl/src/java/org/sakaiproject/evaluation/logic/scheduling/EvalJobLogicImpl.java.
 
For the ‘scheduledActive’ job, it calls sendAvailableEmail() to send the Available notification#. This removes the ‘scheduledActive’ job in SCHEDULER_DELAYED_INVOCATION and then jobAction() calls scheduleJob() for the Due Date notification and scheduleReminder() for the reminder notification, if reminders are set for the eval.
 
This means that once the Available notification has gone out, it should be replaced by entries like this:
 
INVOCATION_ID INVOCATION_TIME COMPONENT CONTEXT 
c0a32b1d-f271-44c0-b2d0-989adb3d23232013-03-21 23:59:00org.sakaiproject.evaluation.logic.externals.EvalScheduledInvocation97/scheduledDue
e4f4da9a-3d36-4031-9950-ebce934282bb2013-03-14 15:20:00org.sakaiproject.evaluation.logic.externals.EvalScheduledInvocation97/scheduledReminder 
The invocation time for the scheduledDue is the Due Date of the evaluation. When that date is reached, jobAction() will check to see that the Due Date has in fact passed, and if so, it will schedule the Closed job to run immediately. The Closed job will check to see when the reports are to be viewed and by whom, and it will schedule Viewable jobs to make those reports available when appropriate (may not be the same dates as the Due date). Those Viewable jobs will send out the notifications about reports to instructors or students or whoever is supposed to see the reports based on when they are scheduled.
 
Reminder emails are little more complex because there are different options. If the evaluation creator sets ‘Email reminder to non-respondent students’ to ‘Never’, then the scheduledReminder job will never be added to SCHEDULER_DELAYED_INVOCATION and that particular notification will never be sent.
 
However, ‘Email reminder to non-respondent students’ has a couple different options:
  • Daily
  • Every other day
  • Every 3 days
  • Every 4 days
  • Every 5 days
  • Every 6 days
  • Every week
  • 24 hours before the survey closes
When the Active job calls scheduleReminder(), it creates the first scheduledReminder entry in SCHEDULER_DELAYED_INVOCATION and the invocation date will be set to the start date + the reminder interval. Once that time is reached, the Reminder job calls sendReminderEmail() and then scheduleReminder() is called again to set up the NEXT reminder, which will be the current time + the reminder interval.
 
I encourage you to look at the logic that determines the next reminder time: scheduleReminder() calls getReminderTime() to determine this and there’s quite a bit of logic here.
 
(You’ll see that there’s special handling in getReminderTime() for the ‘24 hours before the survey closes’ case, which isn’t dependent on an explicit interval.)

Â