Other Uses of the AuditManagement Pattern

Introduction    Implementing    Other Uses     Parts

• Logging Field Values
• Dynamic Control of Logging
• Disabling of Dispatcher Logging

Logging Field Values

In the default Audit functionality, the table of the FieldValue entity is only used to store the field values in the WebInput variable on Event started Log Types.

The FieldValue table can as well be used to store selected field values from other Log Types - that either be from the pre-defined Log Types or from Log Types defined in the application.  In this way additional information can be specified for specific Log records.

In order to store the field values of a variable, you should define a meta-loop for the selected variable(s) and call the LogFieldValues within the loop(s).

Example:

The Inserted article failed logging is extended with the logging of the field values belonging to the WorkFields variable.

Before calling the LogFieldValues meta-function, the values of the AuditLog<SessionID> and the AuditLog<SequenceNo> fields must have been set to identify the Log record.

If logging the field values of more than one variable then be sure that the same field will not appear more than once in the selected variables.

Dynamic Control of Logging

Logging of individual Log types can be controlled dynamically by setting the field LogTypeEnabled of the Log type table to either Yes or No. This can be done from the AuditControlMenu function.

Disabling of Dispatcher Logging

When inheriting from the Abstract.EventDispatcher  pattern, a Dispatcher started record is created each time the Dispatcher function is called, i.e. each time the Web user triggers an Event Handler from his browser. This information will be relevant to record in the initial implementation and test of the Websydian application. Later on when it has been ensured that the Dispatcher function is properly called, it may be appropriate to disable Dispatcher started records.

The Dispatcher started Log Type can be disabled by setting the LogTypeEnabled field, but this would still require a read on the LogType table each time the Dispatcher function is called. For a heavy-traffic Web application, this trivial validation will sum up to a substantial amount of I/O operations.

These I/O operations may be omitted by not having the Dispatcher function inherit from the Abstract.EventDispatcher    pattern and instead define an InitializeEvents function scoped under the Dispatcher function that inherits from the Abstract.EventDispatcher.InitializeEventTypes function:

Example:

In the example above, it will be necessary to re-generate and run the InitializeEvents function each time new Event Handler functions are added to the Websydian application.