Page Comparison

...

1. Infopath forms are filled out in the remote site (is ongoing throughout this workflow)
   • Behind the scenes: The xml forms that infopath submits back to OpenMRS are stored in the formentry queue table
2. The user transporting data from remote to central visits the "Export Forms" page (linked from the Administration screen)
3. Using that page, the user downloads a zip file to a usb key, cdr, or cdrw
   • Behind the scenes: The xml forms are zipped and timestamped.
   • The xml forms are moved from the formentry queue to the remoteformentry pending queue.
4. ...User walks/jogs/drives/flies to central with the usb key to the central server...
5. User visits the "Import Forms" page (linked from the central server's Administration screen)
6. Using that page, the user uploads the zip file on the usb key.
   • Behind the scenes: The xml forms are put into the remoteformentry pending queue. (Note to testers: Both the remote and central server use the pending queue to store data. If your server is both remote and central, you'll have parsing issues)
   • This upload was tagged as from a certain location. A list is kept for "forms received successfully" from this location.
7. The transport user is done for now. He/she can leave for the day or jump to #9
8. The openmrs scheduled task "Process Central Server Imported Queue Items" processes items in the remoteformentry pending queue
   • Behind the scenes: When an xml form is processed it is attempted to be matched to a current patient.
   • Patient matching is done on the patient's "Identifiers", aka Medical record numbers. (NOT on patient.patient_id)
     • If the patient is found, the patient's patient_id is put into the xml form and the form is moved from remoteformentry pending queue to the formentry pending queue.
     • If the patient is not found and this form is marked as an "initial" form, the patient is created from the data in the form
     • If the patient is not found and this form is NOT marked as an "initial" form, the xml form is put into the formentry error queue to be analyzed later by a data manager
9. The user transporting data from central to remote visits the "Download Data for Remote Server" page (linked from the Administration screen)
10. Using that page, the user downloads a zip file onto a usb key, cdr, or cdrw to be taken to a specific remote server
    • Behind the scenes: The zip file contains two things:
      • A backup of the entire central database (made overnight by the OpenMRS scheduled task "Generate Remote Return Data")
        • This backup is simply a sql file made by the mysqldump program. The obs table data is not included.
      • A list of all xml forms received from this remote server.
11. ...User walks/jogs/drivers/flies to the remote server...
12. User visits the "Receive Data from Central" page (linked from the remote server's Administration screen)
13. Using that page, the user uploads the zip file from central off the usb key
    • Behind the scenes: The items in the remote server's remoteformentry pending queue that the central server says it has received are moved to the formentry archive
    • The database backup from the zip file is run immediately on the remote server. All data and tables in the remote server's database are overwritten with what came from the central server's database.
14. (Repeat, starting at #2)

Upgrading

Upgrading should be a relatively easy process for central and remote servers.  The remote server is only storing the xml schema of the submitted forms, so those should be both backwards and forwards compatible with openmrs versions.  The only time you need to be careful is when the form schema changes drastically in either the formentry module or in core (which would be very rare)

Upgrade workflow:

1. Be sure all forms are processed on central
2. Upgrade central's openmrs/war file to the desired version
   1. (meanwhile filling out of forms at remote sites can continue)
3. Take central data to remote along with the new war file upgrade
4. Perform a 'receive from central' on the remote server
   1. (this may or may not complete successfully due to db+code differences
5. Shut down this remote server
6. Upgrade this remote server's war file.
7. Start remote server again and everything should be good to go
8. Perform a 'send to central' to move the forms back to the central

Troubleshooting

java.io.IOException: Cannot run program "mysqldump"

...