KenyaEMR Startup Explained
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 |
|---|---|---|---|
| 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.