Auditing and error handling
- Paweł Gesek
- Tomasz Mueller
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
Name | Description | Default Value |
|---|---|---|
sync.audit.persistSuccess | Whether Sync should persist successful transactions in the audit | True |
sync.audit.persistFailure | Whether Sync should persist failed transactions in the audit | True |
|
|
|
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.
Field | Type | Description |
|---|---|---|
Id | UUID | Unique id of the log entry |
success | Boolean | Whether the operation was successful |
timestamp | Datetime | The timestamp of the operation |
resourceName | String | The name resource that failed, i.e. Patient or Concept |
resourceUrl | String | The url of the resource, either local or remote |
action | Enum, values: PUSH, PULL | Whether this was push to Parent or pull from Parent |
error | Text | The 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