Wiki Spaces

Documentation
Projects
Resources

Get Help from Others

Q&A: Ask OpenMRS
Discussion: OpenMRS Talk
Real-Time: IRC Chat | Slack

Documentation

Page tree
Skip to end of metadata
Go to start of metadata

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)

ManagerPriorityManagesOn refresh
RequirementManager0External requirementsChecks each requirement, throws UnsatisfiedRequirementException if one fails
MetadataManager10Metadata bundlesInstalls all registered bundles
LabManager20Lab test catalogsLoads all lab test catalogs
RegimenManager30Regimen definitionsLoads all regimen definitions from XML resource
IdentifierManager40Identifiers 
CalculationManager50Calculation classes and patient flags 
ProgramManager60Programs 
FormManager70FormsSaves form resources for XML content of all forms and registers custom tags
ReportManager80Reports and their buildersBuilds and persists all report definitions
ChoreManager90ChoresPerforms 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.

  • No labels