Circulation Audit logs

Circulation Audit logs of all actions filtered by a patron and/or an item with additional filters.

Circulation supports interaction with PubSub. So we can use it for logging of actions. The following approach can be applied:

1) Interceptor generates event for some action and send it to PubSub;

2) Listener handles these events and saves it in storage;

3) Client retrieves logs from Logs Storage.

LogRecord

LogRecord is the main entity for saving/retrieving log info:

Field	Type	Default	Required
EventId	UUID	N	Y
User	UUID	N	N
Item	UUID	N	N
Object	Enum<String>	N	N
Action		N	N
Date	DateTime	N	N
ServicePoint	String	N	N
Source		N	N
Description	String	N	N
LinkTo	UUID	N	N
Notes	Text	N	N

DB structure

DB should contain table for each logged object. This will improve performance by reducing the size of the table.

Tables: loans, feesFines, itemBlock, patronBlock, manualBlock, request

Typical table structure:

id	user	item	action	date	servicePoint	source	description	linkTo	notes
...	...	...	...	...	...	...	...	...	...

HL Flow Design

Flow description:

LogRecord saving:

1) LogUtils provides inline handler that construct event message with request (optional), response (mandatory), metadata (TBD). This handler is built into the logic of each method that handles a specific business process.

2) LogUtils sends event to PubSub/Kafka.

3) LogListener listening to the event bus and gets event.

4) LogRecordResolver determines type of record, extracts needed information, populates LogRecord and saves record to DB.

LogRecord retrieving:

1) Client makes call to LogsService /audit-data/logs with CQL query and shows result.

Open questions