Drawio | ||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
According to the feature requirements, audit data from several modules should be captured and stored. Once put into storage, the data should be available to users so that they could generate a report by using them.
Audit logs interceptor component should be created to collect audit data and pass it to Audit log storage. The component should interact with target Folio modules to collect the data. For instance, one of the target modules is mod-circulation. The captured data should have an original schema. The original schema is one, which defined for the data in the target modules that process and store it. Audit logs interceptor could be a library, which is used by a target module to send audit data to the storage. Alternatively, it could be a dedicated module, which either receives all requests/responses from a particular module (acts as a proxy) or from all Folio modules, filters them, and sends target audit data to the storage.
Audit log storage should store all audit data in JSON format with original schemas. It should provide the ability to receive audit data records one by one as from a queue and provide delivery guarantees for all the records. It should also provide the ability to subscribe to it, so that receiver could get new log records as they published.
Audit logs aggregator should receive the data from Audit log storage, purify them by removing all unnecessary fields, convert to target schema, and store them into a target Materialized view. The target schema is one, which is used to store data in the Materialized view.
Materialized view is storage that keeps a subset of Audit data for a particular report type. Each Materialized view has its own data schema and data format that should be selected to easy up the report generation.
There could be multiple Materialized views and Audit logs aggregators - one per report type.
Audit reports provider component is responsible for querying a particular Materialized view to provide its records for a report. A User could leverage query conditions/filters to populate a report with records in which he/she is interested in.
Folio UI should contain a dedicated page for each report. The page should display the report records with appropriate schema and in appropriate format. It should provide a user set of filters to get a subset of report records. It could also contain aggregate numbers, such as total number of records found with the specified filter values.
The described model could be applied as a solution for the collection and reporting of concrete Audit data from the Circulation module. It also can be considered as a general solution, which could be extended later to collect Audit data from other Folio modules and provide new report types.