Commit f5516df351892e8567c5a7920bcf1d11091a95f7
1 parent
1d14a303
Fixed scheduler-docu markdown problems.
Showing
1 changed file
with
7 additions
and
7 deletions
docu/scheduler.md
| 1 | -#Scheduler | |
| 1 | +# Scheduler | |
| 2 | 2 | |
| 3 | -##Concept | |
| 3 | +## Concept | |
| 4 | 4 | The Scheduler service is used to give users the ability to create scheduled reminders. For example, a user of the BeuthBot might want to be informed of the canteen menu on a daily basis. For this he would send a message to the bot, asking it to send him the menu every morning at nine o clock. |
| 5 | 5 | If Rasa identifies this message as an attempt to create such a reminder, it will extract a `createReminder`-intent, along with entities for `date`, `time`, `cycle` and `event`. |
| 6 | 6 | |
| 7 | -##The reminder object | |
| 7 | +## The reminder object | |
| 8 | 8 | The `date`-entity contains the given day on which this reminder should be sent. |
| 9 | 9 | `time` contains the time at which the reminder should be sent. |
| 10 | 10 | `cycle` contains a value defining the interval at which the reminder should be sent. This can either be `DAILY`, `WEEKLY`,`MONTHLY` or `ONCE` for reminders that should only be sent on one specific date. |
| 11 | 11 | The `event-entity contains the object of which the user wishes to be reminded. Currently, only canteen-menu-reminders are supported, but this can expanded to any type of object (e.g. course-timetables), given the data-infrastructure. |
| 12 | 12 | |
| 13 | -##Scheduler class | |
| 13 | +## Scheduler class | |
| 14 | 14 | The Scheduler-class is implemented as a singleton, using the `@Singleton`-annotation, along with a `@Startup`-annotation to make sure an instance of it is created during startup, without the need to be instantiated by another service. |
| 15 | 15 | |
| 16 | -###Creating reminders | |
| 16 | +### Creating reminders | |
| 17 | 17 | A reminder is created via the `createReminder`-function, which requires a `TaskMessage` and `AppUser` as parameters. The `TaskMessage`-object is required to read out the entities mentioned above, which are used as parameters to create a new instance of a `Reminder`-object which is then stored in the reminders-array and inserted into the database. |
| 18 | 18 | The `createReminder`-function returns the created reminder object which can then be further used by the Drools-service to create a response for the user. Should errors occur along the way, the function returns null, giving Drools the opportunity to tell the user that creation of the reminder has failed. This functionality could be expanded to explain to the user what exactly went wrong. |
| 19 | 19 | |
| 20 | -###Sending reminders | |
| 20 | +### Sending reminders | |
| 21 | 21 | To send users the reminders they have asked for, the Scheduler-class makes use of the EJB-annotation `@Schedule`, which is set to fire once every minute, searching the database for Reminder-objects whose `date` and `time` settings match the timestamp at which the function has fired, and if so, forwards this information to Drools, where the appropriate messages can be created and relayed to the users. |
| 22 | 22 | |
| 23 | -###Deleting reminders | |
| 23 | +### Deleting reminders | |
| 24 | 24 | If a user wishes to no longer be reminded of these events, he can ask the bot to stop sending him reminders, which will cause drools to fire the `delete reminder` rule, in turn causing the schedulerService to sift through all reminders associated with this user and removing them. |
| 25 | 25 | \ No newline at end of file | ... | ... |