Commit 665644c2e7d3afa87d7baf4eb0059300a2ae00ed
1 parent
2324efe2
Added scheduler documentation in docu/scheduler.md.
Showing
2 changed files
with
25 additions
and
0 deletions
docu/project_documentation.md
... | ... | @@ -17,6 +17,7 @@ Pushing into this repository will automatically trigger a rebuild of the product |
17 | 17 | - Common - holding common classes used by all other subprojects |
18 | 18 | - [Drools](drools.md) - Business Rules Management System used to generate the right answer |
19 | 19 | - Global - global available services |
20 | +- [Scheduler] (scheduler.md) - Scheduling EJB, used to create and handle reminders. | |
20 | 21 | |
21 | 22 | #### Natural Language Processing |
22 | 23 | - [ApiAi](apiai.md) - simple RESTEasy client application calling googles Api.ai API | ... | ... |
docu/scheduler.md
0 → 100644
1 | +#Scheduler | |
2 | + | |
3 | +##Concept | |
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 | +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 | + | |
7 | +##The reminder object | |
8 | +The `date`-entity contains the given day on which this reminder should be sent. | |
9 | +`time` contains the time at which the reminder should be sent. | |
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 | +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 | + | |
13 | +##Scheduler class | |
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 | + | |
16 | +###Creating reminders | |
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 | +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 | + | |
20 | +###Sending reminders | |
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 | + | |
23 | +###Deleting reminders | |
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. | |
0 | 25 | \ No newline at end of file | ... | ... |