Reporting Issues + Sync

[hngondoki]

The team has reported that:

• Sync is dragging

• The reports are not generated fully in the daily tallies.

[hngondoki]

As per meeting held on 29th Oct the below observations were made:

1. The sync process had issues completing in some devices, and several retries would mean reporting would keep getting stopped and never finish

2. On a device that completed sync, we turned off the internet, several retries then ensued in trying to sync, and it eventually failed. This enabled the report refresh button to be visible. However, the reports did not complete 3 hours later.

3. Another device managed to produce the October reports, however it had not finished sync. This might indicate the 2 processes are conflicting at some point.

[hngondoki]

04/Nov/2020 Notes: The initial sync of 46k events was taking approximately 7 hours. In addition, the reporting job was being automatically triggered after 6 hours. There was competition for the resources within the device as both jobs were executed. Reports job cannot be stopped once started, and this process would take upwards of 2+hours as it generates daily tallies for the full year.

Immediate solution: Make the reports manually triggered always and recommend switching off wifi connection during the reports generation process. This is mostly for the initial sync that would calculate reports for the full year.

Another immediate solution that can be explored: Divide the villages into location groups within the location hierarchy. This is such that the main health center groups outreach staff into location groups that contain a subset of the villages, and assign the outreach staff into the specific location groups. This will reduce the number of clients in the device and thereby increase performance.

Possible Long term solutions:

1. Server side processing of all events, such that the processing is not done by the device

2. Have reports done via OpenSRP server and displayed in OpenSRP Web, with subsequent push to DHIS2. This is currently being done by the device which increases the load on the device.

3. Reduce the clients per device by allowing the client to only sync the records they need. This would involve a redesign of the application to include functionality that enables choice of location and trigger sync for those specifi villages only. Thus when going out to the field, the end user can choose the villages they want to sync the data. If an out of catchment client is found, have the functionality(Advanced search) to pull specific records for that client. Though this would require internet connection. OR to record the out of catchment service provided with the right identifier for upload when internet is available.