Requirements:

Jira Legacy
server System

...

JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 01505d01-b853-3c2e-90f1-ee9b165564fc key FOLIO-2269

Use Cases

1. Check Out / Check In

...

Story: 

...

Story: 

...

Story: 

...

• An item record has been introduced into circulation

...

• Messaging system must be able to send messages directly to a module (for command based approach)
• Message system must be able to publish messages to any subscriber (for event based approach)

Questions

• Who owns that an item is checked out, is it circulation or inventory? This question is important because it likely changes the nature of the integration
  • If inventory owns the fact that an item is checked out, then updating the item might be a required part of the check out process
  • If circulation owns the fact that an item is checked out, then updating the item could happen afterwards, if a degree of eventual consistency is acceptable

Event Based Process (circulation owns that an item is checked out)

• Client attempts to check out an item (business logic steps omitted)
  • Create the loan in circulation storage
  • Update the item in circulation storage
  • Update the request (if required) in circulation storage
  • Circulation publishes
  an 
  •  an item checked out  event
• Circulation responds to client confirming check out
• Inventory receives an item checked out event
• Inventory reacts by updating it's representation of the item in storage

Alternative Flow - Inventory Item Update Fails

• Inventory may Inventory  may choose to retry the storage update
• Circulation is unaware that this update has failed
• There would need to be a way to detect and correct this inconsistency

...

Considerations

• Circulation is not dependent upon inventory for performing check outs (assumes there is already a synchronisation process in place for inventory information)
• Whose responsibility is it to detect inconsistencies?
• Event can be used by other processes

Command Based Process (inventory owns that an item is checked out)

• Client attempts to check out an item (business logic steps omitted)
  • Create the loan in circulation storage
  • Update the item in circulation storage
  • Update the request (if required) in circulation storage
  • Circulation sends a command to change the status of an event to inventory 
  • Inventory reacts by updating it's representation of the item in storage
• Circulation responds to client confirming check out

Alternative Flow - Inventory Item Update Fails

• Circulation may choose to retry issuing the command to inventory
• Check out would fail (and other compensating actions taken) if item in inventory cannot be updated

Considerations

• How does circulation know that the command has failed? Is is based upon:
  • a request / reply protocol (meaning the messaging infrastructure needs to support reply addresses and correlation)
  • the absence of an error in a given time
  • polling for the state change in inventory
• Inventory must be available for check out to occur, even with the use of messaging (unless move the command issuing to after check out succeeds, then need similarly compensation / recovery to event based approach)

Notes

• Individual storage module requests could still fail, this would need to be addressed separately, with appropriate compensating actions
• The UI / client uses the state of these records to guide the user experience, so it is not possible to defer some of these operations till after the check out (e.g. in the background)
• It is not possible to resubmit the check out as it is not idempotent, it refuses any attempt to check out an item that is already checked out or already has an open loan

...