Low-level design (Transient architecture)

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.

API

Method

Path

Provided permissions

Request

Response

Description

Notes

GET

audit-data/circulation/logs

audit-data.logs.collection.get

object

query

200 OK (LogRecord Collection)

Get LogRecord Collection

LogRecord

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

Field	Type	Default	Required	Note
eventId	UUID	N	Y
userId	UUID	N	N
itemId	UUID	N	N
Object	String	N	N	enum: Fee/Fine, Item Block, Loan, Manual Block, Notice, Patron Block, Request
Action	String	N	N
Date	DateTime	N	N
ServicePointId	UUID	N	N
Source	String	N	N
Description	String	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, fees_fines, item_blocks, patron_blocks, manual_blocks, requests, notices

Table structure: jsonb.

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 (PubSub client can be considered as alternative for custom event sender).

3) LogListener listen to the event bus and gets event (PubSub event handler in the mod-audit).

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.