Refine Module Administration Project

Owned by Former user (Deleted)
Last updated: Aug 18, 2010Version comment
5 min read

General Information

  • Name of Organisation : OpenMRS
  • Project Title : Refine Module Administration
  • Assigned To : Shazin Sadakath
  • Contact Person : Burke Mamlin and Ben Wolfe
  • Contact Information : Burke - email|bmamlin|regenstrief.org, Ben - email|bwolfe|regenstrief.org
  • Project Timeline : 27th April 2010 - 30th August 2010

Abstract

OpenMRS supports a great way to integrate Modules into the core system. But these modules are not hot swappable but gives the impression of hotswappable. Each time a module is uploaded, stopped or restarted the OpenMRS system literally restarts itself to put that action into effect. All scheduled tasks and background processes currently running will be interrupted. This project proposes an effective solution for this problem.

Problem Statement

OpenMRS supports modules integration and administration using its current user interface. Users of OpenMRS depend extensively on robust execution of some modules, all scheduled tasks, background processes and they would require modules to be uploaded, started, stopped also. But this is the problem current OpenMRS module administration faces. Since each module upload, download, start, stop, unload action performed by the user will result in a full OpenMRS Spring Context refresh. This refresh will interrupt all the currently executing modules as well as other background processes thus degrading the robustness.

To ensure the robustness there should be a mechanism which allows to do the above mentioned actions to be performed by the user without an OpenMRS Spring context refresh. This refresh should take place only when the user explicitly wants it to happen. Which means refreshing of OpenMRS Spring context should be decoupled from each above mentioned actions and should be an explicit action which can be performed by clicking a "Restart" button. Thus the OpenMRS Module Administration will guarantee uninterrupted and smooth execution of running modules and background processes.

Further more OpenMRS allows to add module as well as upgrade existing modules. Currently there are individual actions for adding and upgrading modules. These should be consolidated together to be performed as one action. With the basis of "To upgrade a module it must exist" a module adding and upgrading can be distinctly identified. Thus appropriate action can be performed.

Project Primary Objectives

  • Writing code that allows module upgrade or deletion to be queued for a subsequent manual restart of the OpenMRS.
  • Modifications to module administration page.

Project Mentoring and Evaluation

  • Mentoring will be done by Burke Mamlin
  • Mid Term Evaluation deadline is on 16th July 2010
  • Final Evaluation deadline is on 20th August 2010

Documentation and Sharing Source

Project Plan

Task

From

To

Activities

Community Bonding Period

27 Apr

23 May

  • Analysing existing OpenMRS Module Administration.
  • Communicating with mentor to clear out any problems encountered.
  • Come up a with an appropriate design for Queuing of Module Actions.
  • Verifying whether the proposed design is feasible
  • Creating mock up of proposed chages to Module Administration Page.

Code/Documentation I

24 May

14 June

  • UI Modifications according to the proposed mock up.
  • Changing back end code of ModuleListController class to enable one upload to Add/Upgrade Module
  • Testing of the correct functioning of above changes.
  • Presentation on 10 June would include these changes.
  • Documentation

Code/Documentation II

15 June

11 July

  • UI Changes to show appropriate message and confirmation of user whether or not to restart.
  • Doing necessary changes in ModuleFactory class to enable queuing of Module Actions.
  • Doing necessary changes in ModuleFactory class to enable execution of Module Actions.
  • Introducing a ModuleAction enum which will show each individual pending action PENDING_START, PENDING_STOP, PENDING_UPGRADE, PENDING_UNLOAD, PENDING_NONE
  • Doing necessary changes in ModuleListController class to enable queuing of actions rather than performing them followed by a restart.
  • Testing of the correct functioning of above changes.
  • Documentation

Mid Term Evaluation

12 July

16 July

  • Getting ready and completing mid term evaluation

Code/Documentation III

17 July

15 Aug

  • Doing changes in ModuleUtil refreshApplicationContext method to call execution of queued module actions before an explicitly called restart takes place.
  • Doing changes in ModuleUtil startup method to call execution of queued module actions after a server crash or explicit stopping of server.
  • The module repository listing is loaded on demand or in the background (it should not slow down page load and should fail cleanly if there isn't an internet connection)
  • Persisting suppress confirmation of upgrade for each user.
  • Introduction of a ModuleImportHandler class which specializes on importing modules to OpenMRS web application (Upload, Download) This would layout the first step to Bundled Modules to be uploaded and make the ModuleListController class look more maintenance friendlier.
  • Testing of the correct functioning of above changes.
  • Presentation on 22 July would include these changes.
  • Documentation

Final Evaluation

16 Aug

20 Aug

  • Getting ready and completing final term evaluation

Awaiting final evaluation results

21 Aug

23 Aug

Submitting code samples to google

24 Aug

30 Aug

Recurring steps planned to adhere are;

  • Sending weekly review on work done to mentor on every Sunday
  • Merging trunk and branch every 3 days.
  • Committing to branch as early and as often as possible.
  • Blogging progress on every Monday at http://shazsterblog.blogspot.com/.

Proposed UI Changes

The Module Administration UI Change I

The Module Administration UI Change II

The Module Administration UI Change III

The Module Administration UI Change IV

The Module Configuration Page

The JQuery Confirmation Widget aka jConfirm

Confirmation Utility

Additional Information

This project requires knowledge of Spring Web MVC, OpenMRS Core API, Modules, Module Administration, JQuery, JSTL, etc. At the end of this project the Module Administration would become a smooth uninterrupted process.