On the Quartz Scheduler Project

I have been trying (in vain) to get the Quartz Scheduler project page up on the OpenMRS wiki, but keep getting the following error when posting my changes:

So for now, the project page will just have to be left here.

Overview

There are many activities within a healthcare information system which benefit from automation. For example: daily clinic reports might need to be generated the morning before a clinic opening, decision support rules might need to be run over a patient group once every week, or healthcare data coming in from outside sources might need to be analyzed every 30 mins. To give end implementations the flexibility to define these sorts of automated conveniences, the OpenMRS community has added scheduler functionality to the core software application. The OpenMRS scheduler (based on the JDK Timer) currently supports executing tasks on regular basis (i.e. a task will execute every X seconds, minutes, hours, days). However, there's no way to schedule a task to recur at a particular time every week. The data model supports this type of feature (start time and repeat interval), but we need to add some logic to the Scheduler to handle triggering these tasks to occur at exact times.

We want to support more complex scheduling (i.e. cron-like) in the very near future, where we can specify rules that will allow Tasks to run more more/less frequently based on the day/time. For instance, an implementation might want to schedule a Task to run once every day at midnight, but also at 6pm on Saturday and Sunday. This type of scheduling would be difficult to support using the JDK Timer, so we would like to add an extension point to the scheduler to allow a developer (probably myself) to create a module based on the [http://www.opensymphony.com/quartz Quartz Scheduler]. This will allow us to handle more advanced scheduling requirements.

Requirements

High Level Goals

• Decide whether to build as a module to extend current functionality or as a core component to replace the current functionality.
• Decide whether to include Quartz tables in the OpenMRS data model (there are about 7 Quartz-specific tables).
• Implement a Quartz version of the scheduler to extend (possibly replace) the current JDK Timer implementation.
• Implement features that allow a user to manage scheduled tasks.
• Redesign the Manage Scheduler user interface to provide a more user-friendly and intuitive experience.
• Create unit tests for each expected behavior of every method within the scheduler service and its domain objects.

User Stories

Student will be responsible for soliciting requirements (user stories) from users/implementers. Here are just a few examples of user stories that might be applicable to this project.

• Allow a user to view all available tasks.
• Allow a user to view all scheduled tasks.
• Allow a user to create a scheduled task.
• Allow a user to update a scheduled task.
• Allow a user to delete a scheduled task.
• Allow a user to schedule tasks to be run on an interval (i.e. every 30 seconds) or at specific moments in time (Tue, March 24 at 10:42pm).
• Allow a user to schedule emails to be sent at a specific time.
• Allow a user to schedule reports to be generated and sent to stakeholders at a specific time.
• Allow a user to start an available task.
• Allow a user to stop a scheduled task.
• Allow a user to check whether a task is currently executing.

Planning Process

1. Identify user roles that will be using the scheduler
2. Identify user stories for each role by interviewing users / stakeholders
3. Prioritize user stories using MoSCoW rating (Must, Should, Could, Want)
4. Estimate user stories (a.k.a Planning Poker) using ideal days (0.5, 1, 2, 3, 5, 8, 13, 20)
5. Discuss acceptance criteria (expected behavior) for each user story with stakeholders.
6. Create a Release backlog for the current sprint / iteration
7. Estimate / calculate velocity (i.e. 20 story points)
8. Create an Iteration backlog of stories
9. Create tasks for each user story in the iteration
10. Assign estimated hours to each task
11. Mockup user stories prior to start of sprint to solicit feedback.
12. Run sprint for iteration duration (between one to two weeks)
13. Deploy features completed during sprint to labs.openmrs.org
14. Solicit feedback from users/stakeholders
15. Re-prioritize and re-estimate users stories / tasks
16. Recalculate velocity
17. Create an Iteration backlog for stories that fit into
18. After X iterations, deliver final release

Timeline

This section will be completed by the mentor and student.

• Iteration #1:
• Iteration #2:
• Iteration #3:
• Iteration #4:
• Iteration #5:
• Iteration #6:
• Release:

Mockups

This section will be completed by the student.

FAQs

Still compiling questions/answers. Will post by Friday.

Resources

Project Resources

• [http://docs.google.com Project Discussion] (has not been created yet)
• [http://docs.google.com Release Backlog] (has not been created yet)
• [http://docs.google.com Iteration Backlog] (has not been created yet)

OpenMRS Resources

• [http://openmrs.org/wiki/Scheduler_API Scheduler API]
• [http://openmrs.org/wiki/Quartz_Scheduler_Developer_Guide Quartz Scheduler Developer's Guide]
• [http://openmrs.org/wiki/Quartz_Scheduler_User_Guide Quartz Scheduler User Guide]
• [http://openmrs.org/wiki/Technical_Discussion#Task_Scheduling Technical Discussion about existing Scheduler]
• [[ticket:357|Ticket #357]]
• [[ticket:359|Ticket #359]]
• [[ticket:1056|Ticket #1056]]

Blogs

• [http://blog.justinmiranda.com Justin Miranda]
• [http://www.openmrs.org Student Blog]

External

• For more information on Quartz, please see the [http://www.opensymphony.com/quartz Quartz Project] home page.
• more resources to follow