Wiki Spaces


Get Help from Others

Q&A: Ask OpenMRS
Discussion: OpenMRS Talk
Real-Time: IRC Chat | Slack


Page tree
Skip to end of metadata
Go to start of metadata

In order for Sync 2.0 to be transparent to administrators, it has to provide visibility into it's operations, as well and show what was synced. Sync must also be more reliable and allow administrators a way to troubleshoot more easily into how it operates.

Because of this, it should be possible to configure sync to store information about the failures it faced, as well as provide the ability to retry a failed transaction. It should be also possible to store details about all messages in order to provide a more comprehensive audit of Sync operations.

Sync should provide a UI for each Child that gives an overview of the transactions and failures that happen along the way, combined with the ability to retry operations that have failed. Each failure should have enough information attached to it, so that an admin can act on it. and resolve the potential issue.

Configuration variables

NameDescriptionDefault Value
sync.audit.persistSuccessWhether Sync should persist successful transactions in the auditTrue
sync.audit.persistFailureWhether Sync should persist failed transactions in the auditTrue

Audit domain object

Each Sync transaction would create an audit entry in the table. This entry would store the state of the operations as well as the ability to identify the resource, by storing the url from the feed event.

IdUUIDUnique id of the log entry
successBooleanWhether the operation was successful
timestampDatetimeThe timestamp of the operation
resourceNameStringThe name resource that failed, i.e. Patient or Concept
resourceUrlStringThe url of the resource, either local or remote
actionEnum, values: PUSH, PULLWhether this was push to Parent or pull from Parent
errorTextThe error message message persisted by Sync. Should contain the response from the server if this was a network issue.


The data from this table should presented to administrators in a grid, with the ability to filter it by timestamp, resource name, success/failure and type . All interaction with this audit log,  both reading and writing, should be facilitated by a SyncAuditService that will also allow programmatic access to the audit log.

Audit UI

The UI below show the audit UI that lists the Sync operations. It allows filtering by certain fields, as well as selecting the date range. The grid is refreshed after the user finishes to alter the search parameters. Datepickers should be added for date selection and the grid should be paginated on the backend side. Each of the rows allows examining the message further and shows a detailed view of the message, as well as an option to retry an action failed. 


Once a user views the details for an operation, he will have an option to view the details of the message as well as to retry it if it failed. The details of the message should not be editable, but should allow the user to identify the problematic object, so that it can be dealt with. It is important to include all the details of failure


  • No labels