Page Comparison

...

Affected modules and event types

mod-circulation-storage

mod-circulation

mod-patron-blocks

mod-feesfines

mod-remote-storage

mod-audit

"?" means that, most likely, it was added due to a PubSub (fixed) bug that required a module to subscribe to the same event types that it produces. Because of that, developers used to make publications and subscription lists identical.

Phase 1 implementation plan

See the feature

For each of the affected modules:

...

Phase 2 implementation plan

...

See the feature

Jira Legacy
server System JIRA serverId 01505d01-b853-3c2e-90f1-ee9b165564fc key UXPROD-4381

The effort required to implement Transactional Outbox pattern varies depending on the module and the event type. They can be split into 3 categories based on the level of complexity:

1. Modules that publish events and have their own database (e.g. mod-feesfines). Publishing stays in the same module, but Transactional Outbox pattern needs to be implemented. 
2. Modules that publish events and don't have their own database (e.g. mod-circulation). Publishing of these events has to be moved to corresponding storage modules in order to have an ability to implement Transactional Outbox pattern.
3. Log events - these modules can fall into either category 1 or 2, but it should be discussed separately whether they should also implement Transactional Outbox. The only functionality that can suffer from these messages not being delivered is Circulation Log.

Event types that need to be published in mod-circulation-storage instead of mod-circulation:
ITEM_CHECKED_OUT
ITEM_CHECKED_IN
ITEM_DECLARED_LOST
ITEM_AGED_TO_LOST
ITEM_CLAIMED_RETURNED
LOAN_DUE_DATE_CHANGED
LOAN_CLOSED

Event types that need to be published from mod-feesfines (the same module that is publishing them now to PubSub):
FEE_FINE_BALANCE_CHANGED
LOAN_RELATED_FEE_FINE_CLOSED

Module name	Has a DB
mod-circulation-storage	Y
mod-circulation	N
mod-patron-blocks	Y
mod-feesfines	Y
mod-remote-storage	Y
mod-audit	Y

Pattern implementation:

• Create table message_outbox with fields: id, kafka_topic, payload, status
• Every process that wants to publish messages should create a new entry in the message_outbox table with status NEW. It should be part of the same transaction as the change that the message is related to (e.g. loan update during check-out).
• Create a timed process that will check for the new entries in the message_outbox table and publish messages if needed. 

Note. Additional complication comes from the fact that Transactional Outbox pattern doesn't guarantee that the message will be sent exactly once (could be more than once). This means that we need to introduce some unique identifier and check it on the consumer side.

Technical details and examples

...