AquilaCRS Audit Trail Rebuild
AquilaCRS records all database actions in an audit trail that can be used to rebuild the database. The rebuild program is available in two editions:
- svcAqRebl: Windows service for continual rebuild processing; for replication purposes.
- AqReblWin: Windows desktop app for ad-hoc database rebuilding.
Both apps use the same internal rebuild engine.
The service and the desktop app are installed using a single wizard installer. The service is installed by default as "manual" start up & requires correct configuration before starting.
The service and desktop apps use their own INI files for configuration. The INI files contain the following configuration items:
|AuditURL||url||Specifies the location of the server containing the audit trail records to use as a basis for rebuilding.|
|TargetURL||url||Specifies the location of the server that is to be used as the rebuild target database. Can be the same as the AuditURL if the same server is used for both source and target.|
|BatchSize||Number||Defaults to 200. This is the number of audit trail records to retrieve from the audit trail table at a time for processing. The higher the number the longer the delay in retrieving records initially.|
|UnitID||Blank or a specific unit id.||Defaults to blank. If specified, then the rebuild process will only rebuild data for the unit specified.|
|IncPrivateDeltas||1 or 0||Defaults to 0. If this setting is on, the patient identifiable audit data is also rebuilt. Defaults to off, which does not rebuild patient identifiable data.|
|UseTargetDateTime||1 or 0||Defaults to 0. If set to 1, then the rebuild process stops at the date/time specified by TargetDateTime setting. This is ideal for rebuilding a database to a specific date point.|
|TargetDateTime||Date in format: DD/MM/YYYY HH:MM:SS||If UseTargetDateTime is on, then this date specifies the point at which to stop rebuilding the database.|
|MatchOldValues||1 or 0||Default is 1. When rebuilding the audit trail, the rebuild app will ensure that the existing value in the database matches the old value in the audit trail (where available). If the old value doesn't match the audit trail record is flagged as having failed and the next audit trail record is processed. Only turn this setting off if there have been manual alterations to the database contents that were not included in the audit trail.|
|Verbose||1 or 0||If 1 the level of logging is increased. To be used for debugging/problem solving only. Default is 0.|
The service app (svcAqRebl) sends its output to the Windows Application Event Log. The desktop app (AqReblWin) logs its output the application directly.
Audit Trail Status
Each entry in the audit trail has a "status" (stored in the change_status field). Values are as follows:
- 0 - unprocessed delta. This is never used as all recorded deltas should be processed (UnprocessedDelta)
- 1 - a freshly applied delta that is recorded in the audit trail. This status is what the Rebuilder looks for. (NewDelta)
- 2 - failed, i.e. a delta that passed through the app server that failed to apply on the database (FailedDelta)
- 3 - this delta has been transferred to another system, usually a central or national database (DeltaSent)
- 4 - delta partially rebuilt. Usually caused by "OldValueMismatch", but review the actual audit trail entry for more details (PartialRebuild)
- 5 - delta fully rebuilt (RebuiltSuccess)
- 6 - an unknown reason the rebuild has failed (FailedToRebuild)
- 7 - an exception has occurred during the rebuild - see error log messages (UnknownException)
- 8 - Old-value mismatch. You will not see this in the change_status field, but you might encounter this in the CS attribute in the audit trail XML (ValueMismatch)
- 9 - the audit XML is badly formed or causing some other problem - shouldn't happen ever (DeltaInvalid)
- 10 - about to process the delta -- this is a temporary status, and if it appears in the database there's a problem (BeforeProcessDelta)
- 11 - refers to an individual change where the field in question isn't found in the table - this is indicative of the central database not being in step with the client databases (FieldNotFound)
- 12 - for update/insert change types, there is no NewValue attribute (NewValueNotFound)
As well as the audit trail entry as a whole being marked with a status code, each change within the audit trail is also marked with a status code. This appears as the CS attribute for each CH node, e.g. CS="8".