Auditing

During the day to day operation of Vitalware there may be times when an administrator or user requires details about who changed a record, when it was changed and what changes were made. An auditing facility creates audit trails, a sequence of records that describe the operations performed by a user and the time at which the changes were made. These records generally include the:

  • operation performed (e.g. insertion, update, etc.)
  • module affected (e.g. eparties)
  • name of the user
  • date and time
  • IRN of the record affected
  • data specific to the operation performed (e.g. fields changed for an update)
  • database sub-system that performed the operation

Vitalware has a fully integrated auditing facility. The facility includes an Audit Trails module (eaudit), which contains complete audit trails for all operations registered for monitoring. There are five levels for which audit records may be generated:

  • change (insertions, updates, deletions)
  • search (queries)
  • display (viewed, sorted, reported)
  • login (first access of a module in current session)
  • all (all database operations)

Each of these may be set on a per module basis, which means that it is possible to monitor all changes to records in the Parties module, for instance, while Multimedia records may be audited for changes, searches and records viewed.

Every Vitalware module contains an Audit tab that lists all audit trail records for the current record. Each record details the operation performed, who performed it and the date on which it was performed. From this tab it is also possible to view the complete audit trail record in the Audit Trails module.

The Audit facility is extensible, which allows other services that require access to detailed information about record changes to take advantage of its framework. In particular two other services use the audit framework to monitor record modifications. The first is the archiver service, which allows raw XML audit trail records to be stored in a file. The second is the sync service, which is used to ensure that dependent records are updated when the master record is changed.

Another service that uses the auditing facility is the archiver. All XML audit records generated are passed to the archiver service to determine whether a copy should be placed in a file for archiving. The service allows administrators to keep a backup copy of all XML audit records (which can be used for reference or supplying to other software as input).

To enable the archiver service the directory logs/audit must exist on the Vitalware server. By default, the directory does not exist when Vitalware is installed and must be created by an administrator. When the directory is first created the auditing sub-system must be restarted via:

vwload stop audit

vwload start audit

All XML audit records for a day are placed in a single file under the logs/audit directory. The file name is in the form yyyy-mm-dd . Once all the entries for a day have been added, the file is compressed (with gzip) and renamed to yyyy-mm-dd.gz . To view a compressed archive file use:

gzcat yyyy-mm-dd.gz

The archiver can be disabled by either renaming the logs/audit directory or removing it. Once disabled the auditing sub-system must be restarted via:

vwload stop audit

vwload start audit

The sync service is used to ensure that all records that extract data from another record are up to date. For example, a Births record may copy the NamOrganisation field from the Parties module into the Hosp./Clinic field for a hospital. The copy is used to allow high speed searching on the Hosp./Clinic field in the Births module. If the record in the Parties module is changed so that the value of the NamOrganisation field changes, all Births records that copy in the NamOrganisation value must be updated to the new value.

A table is maintained automatically in etc/syncmap and is used by the sync service to determine which fields need to be updated when a field is modified. In the example above the map would contain:

eparties    NamOrganisation    ebirths    BirthFacilityNameRef

This indicates that when the NamOrganisation field in the eparties table is changed, the BirthFacilityNameRef field in the ebirths table is checked to see if the value needs to be updated.

The sync service is implemented as a background load and is controlled by the vwload command. In the day to day working of the system the sync service must be running to ensure that records are always up to date.