KenyaEMR Startup Explained

Owned by Rowan Seymour
Last updated: Feb 20, 2014 by Gitahi Ng'ang'a
2 min read

A lot happens when you startup KenyaEMR so this page is an attempt to explain the details to help developers and admins debug any problems that might arise.

The KenyaEMR module is not designed to be stopped and started independently of OpenMRS even though this possible using the regular OpenMRS admin UI

Loading content

The CoreContext component class in KenyaCore is responsible for loading all EMR content. The KenyaCore module does not initiate this action itself. Rather it is left to KenyaEMR to fetch this component and call its refresh() method during its startup.

The CoreContext.refresh() method loads all content manager components, and invokes their refresh() methods in turn. If any one of these throws an exception then the entire refresh process is stopped. KenyaEMR and other modules can determine if the complete refresh process was successful via CoreContext.isRefreshed().

Error handling

Because KenyaEMR initiates the content loading, any problems that occur during that process can be caught and handled in KenyaEMR rather than delegated to the OpenMRS's module framework. If an error occurs during content loading:

  • KenyaEMR is still operational (i.e. we don't prevent the KenyaEMR module from loading)

  • A warning message is displayed to users to tell them to contact an admin 

  • Admins can login see information relating to the problem

    • If problem is a missing requirement (e.g. CIEL) they'll see this on the home page of the Admin app

    • When TRUNK-4267 is fixed, we'll send admins an alert with whatever exception occurred. For now they have to consult the log files

Content managers

All of the existing content managers gather up components defined in the application context. This makes it easy for add-on modules to provide new content to KenyaEMR. An add-on module can even provide new content managers, and by configuring the value returned by ContentManager.getPriority(), determine when in the loading process those content managers will be refreshed. 

The existing content managers are as follows (listed in the order in which they are refreshed)

Manager

Priority

Manages

On refresh

Manager

Priority

Manages

On refresh

RequirementManager

0

External requirements

Checks each requirement, throws UnsatisfiedRequirementException if one fails

MetadataManager

10

Metadata bundles

Installs all registered bundles

LabManager

20

Lab test catalogs

Loads all lab test catalogs

RegimenManager

30

Regimen definitions

Loads all regimen definitions from XML resource

IdentifierManager

40

Identifiers

 

CalculationManager

50

Calculation classes and patient flags

 

ProgramManager

60

Programs

 

FormManager

70

Forms

Saves form resources for XML content of all forms and registers custom tags

ReportManager

80

Reports and their builders

Builds and persists all report definitions

ChoreManager

90

Chores

Performs all chores not already performed

Performance

Startup time is dependent on the state and size of the database.

  • Metadata loading includes synchronization of all locations with a copy of the MFL. If locations in the database are up to date then no database updates are required so this will only take a few seconds. On a clean database, it will require the saving of ~9500 new locations which may take 1-2 minutes.

  • Chores are only performed once, so none of these will be performed on a up to date database. 

Typical startup times for an up to date database are 30-50 seconds.