To setup multiple instances of OpenMRS, follow this general procedure:
- Checkout the latest source code from Subversion
- Create separate instances of your database (i.e. openmrs1, openmrs2)
- Create separate instances of your OpenMRS runtime file (i.e openmrs1-runtime.properties)
- Build an instance of the WAR file
- Rename openmrs.war to openmrs1.war
- Copy the openmrs1.war to openmrs2.war
- Modify runtime properties to point to correct database
- Copy openmrs1.war, openmrs2.war to Tomcat webapps
- Start tomcat
[runtime] Make sure Database connection URL is pointing to the right database.
[global] Make sure that the form entry global properties are distinct.
In Malawi we had an issue that caused the creation of duplicate encounters for each form entry. We realized that it was due to the fact that we had multiple instances of OpenMRS running. In our scenario, the form entry queue processor was scheduled on both instances and was looking at the same queue directory. Therefore, both tasks got to the queue at the same time and processed the incoming form entry submissions. We happened to be using the same database instance for each (one was a read-only OpenMRS instance).
Modules could also potentially be a problem. You might be able to skip all these problems by simply setting the application_data_directory runtime property to different folders in the two different runtime property files.
If one was a read-only instance, how were they both able to create an encounter from a form?
By "read-only" I mean that users had only "view" privileges of the data. At this time, there's no option for setting OpenMRS to be read-only (i.e. preventing all writes to the database).
... well, other than creating a new database user (say openmrs_read) and granting that user SELECT privileges only.
Post a Comment