December Tech Report
Bahmni provisioning using ansible
Slight delays due to unforeseen work on other features caused delays in release of the ansible releases, but we are doing quite good on testing. We have setup showcase environments using the ansible installers and early previews to some customers are well recieved.
1. We are planning to release v0.80 with ansible installers
2. We have added a shiny new command line utility named, what else, “bahmni”. So you could do stuff like -
- bahmni install
- bahmni start/stop (to start/stop all bahmni services)
- full list or tasks -> bahmni [ help | install | start | stop | restart | status | setup-replication | update-config]
using this utility from the controller machine. And of course, this utility is built to manage multi machine scenarios as well.
3. We are now releasing our final builds through bintray, the build pipeline has been automated to upload builds to https://bintray.com/bahmni/rpm/
4. Daily builds will be available as usual, on our .14 boxes (and its online alias )
Bahmni component packaging
Late this October we started working on upgrading our packaging of Bahmni artifacts — our components — openmrs, lab, erp and connects. We decided to version, transport and install our components using standard yum packaging (RPMs) — using Netflix’s Nebula gradle plugin. This was tested in some local and showcase environments and improvements have been made. Overall, the feedback has been favourable.
Bahmni Offline
Work for Bahmni for offline users is right now focused on the registration app. We are planning for a release with v0.80
1. Synchronising data from the bahmni server to the device and vice versa requires some engineering effort, here’s our approach
a. reference data that are smaller in size (gender etc.) are all cached called via service worker proxy
b. all static content will be cached via service worker
a. This is a new service endpoint (a full application actually), that runs a daemon to copy events from the event_records table in temporal order
b. This service will be a single source of all events happening in the bahmni/openmrs object model. This mean changes to reference data (drugs, addresses, etc.) and transactional data (patients, encounters) will all be logged and be available for reading here.
c. On existing installation, we will run a one time copy operation that will copy events from existing event_records table
d. We needed, and will in future, need some more entities to be tracked for changes, specifically reference data like addresses required to build a transactional record like patient on the device.
e. Devices, or infact any other listener should be able to keep a single marker (time) using which they could keep track of events happening on the bahmni server
f. Events could be filtered by an attribute like geographical location etc.
- offline devices (planned for Jan)
a. The offline devices will keep a queue of changes made locally when offline or online
b. A single process running in the background will push the changes made to the server one at a time from the queue
c. Offline devices should be able to filter bahmni server events by login location so as to minimise local data
2. Bahmni offline app will have a local sign-in option wherein a user could log out from the application and log back in when offline. To make this secure, we have in place an encrypted password storage on the device.
3. Bahmni database on the offline device is already an encrypted file.
4. We faced some friction while writing a database driver to the offline Chrome app using lovefield (a SQL layer over indexeddb) that behaved similarly to the android sqlite driver. Most of the issues are ironed out now and we have a working version of the offline app that could be used to search patients on android and chrome apps.
5. Encryption of the offline android database was implemented using SqlCipher, which is a library that provides transparent 256-bit AES encryption of Sqlite databases.
Performance
We continued work towards better performance in December -
1. Uglification of javascript is now in place, and we have reduced the download size significantly.
2. With correct SSL certificates, we should see significant reduction in traffic on the bahmni server, since browser caching on Chrome is disabled with self-signed certificates. Our situation on this front will change favourably with LetsEncrypt certificates (planned for v0.80)
3. Newrelic is now set up in the JSS environment and we are getting very useful insights from production environments. Notifications have been set up and are sent to the #jss-prodnotifications slack channel
Security
Bahmni uses https for accessing the EMR, Lab and ERP. We need to install valid SSL certificates on the server without which we see an annoying message called “Your connection is not private”. It essentially means that the domain is not validated and there might be a risk in accessing the site. This has effect on browser side caching too. To fix this, we spiked out Letsencrypt for generating SSL Certificates. Letsencrypt is an opensource tool which generates SSL certificates in a free, open and automated fashion. We have created valid SSL certificates using it. The detailed process of how to configure and use is available here.
Currently, we are testing this workflow and it will be released with v0.80. We plan to assist customers with existing internet domains with LetsEncrypt in future.
Build
On the 31st, we renamed the github organisation from Bhamni to Bahmni. Happy new year!!
In other news on the build front -
1. We are facing unplanned issues because of our dependencies on snapshots version of openmrs core and emrapi (which leads to dependency on other snapshots). To isolate the issues, we have forked webservices.rest (https://github.com/Bahmni/openmrs-module-webservices.rest) and work on releasing emrapi with orderset is on highest priority, so we can get out of this mess.
2. Release artifact uploads to bintray are automated.
3. From v0.80 onwards, branching strategy will change to make us carry on with build numbers post branching (this is a problem right now, since build numbers get reset on branching in our current CI setup)
4. We have been a bit tardy with managing customer facing showcase environments, especially around moving metadata configuration and data dumps. We need to work on this aspect this January.
