Difference between revisions of "AquilaCRS Audit Trail Rebuild"

From EHS Help
Jump to: navigation, search
(Added Change Status explanations)
m (Audit Trail Status)
 
(One intermediate revision by the same user not shown)
Line 68: Line 68:
 
Each entry in the audit trail has a "status" (stored in the change_status field).  Values are as follows:
 
Each entry in the audit trail has a "status" (stored in the change_status field).  Values are as follows:
  
* 0 never used, all recorded deltas should be processed (UnprocessedDelta)
+
* 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 (NewDelta)
+
* 1 - a freshly applied delta that is recorded in the audit trail. This status is what the Rebuilder looks for. (NewDelta)
* 2 i.e. a delta that passed through the app server that failed to apply on the database - rare occurrence (FailedDelta)
+
* 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 (DeltaSent)
+
* 3 - this delta has been transferred to another system, usually a central or national database (DeltaSent)
* 4 Delta partially rebuilt - see actual log entry for more details - in case of OldValueMismatch (PartialRebuild)
+
* 4 - delta partially rebuilt.  Usually caused by "OldValueMismatch", but review the actual audit trail entry for more details (PartialRebuild)
* 5 Delta fully rebuilt (RebuiltSuccess)
+
* 5 - delta fully rebuilt (RebuiltSuccess)
* 6 A bit like unknown exception really (FailedToRebuild)
+
* 6 - an unknown reason the rebuild has failed (FailedToRebuild)
* 7 some other reason for not rebuilding - see error message (UnknownException)
+
* 7 - an exception has occurred during the rebuild - see error log messages (UnknownException)
* 8 Old-value mismatch (ValueMismatch)
+
* 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 XML is badly formed or causing some other problem - shouldn't happen ever (DeltaInvalid)
+
* 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)
+
* 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 - should never happen (FieldNotFound)
+
* 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 - weird (NewValueNotFound)
+
* 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"''.

Latest revision as of 11:37, 1 August 2013

This is a Technical (IT) AquilaCRS topic


Overview

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.

Installation

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.

Configuration

The service and desktop apps use their own INI files for configuration. The INI files contain the following configuration items:

Key Name Values Description
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.

Logging

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".