Withdrawn Items - Design Options

Owned by Marc Johnson
Last updated: Apr 29, 2020
2 min read

Feature Overview

Librarians need to be able to differentiate between items that have gone missing, are lost or have been deliberately removed from the library’s collection. This feature covers the deliberate withdrawal of items.

Interesting Scenarios

At first, this feature does not appear to be particularly interesting from a design perspective, until we encounter a part of the process that requires crossing the domain boundary between inventory and circulation.

Resetting request fulfilment when item is withdrawn

When an item is withdrawn, a request for that item that is being fulfilled needs to change:


Given an item Dune that John has requested and is awaiting pickup

When this copy of Dune is withdrawn

Then request should become Open - Not yet filled

Key Aspects

  • Withdrawing items is an inventory domain process
  • Asynchronous cross-domain processes are unusual in FOLIO
  • Asynchronous publish-subscribe mechanism is unfamiliar in FOLIO at present
  • Cyclic dependencies are not allowed in FOLIO

Options

Circulation Implements Withdrawing Items

Circulation could implement the whole withdrawal process. Circulation would synchronously update the item using request-response HTTP APIs.

Considerations

  • Process modelled in circulation
  • Circulation already understands requests and items
  • No dependency introduced between inventory and circulation
  • Inventory UI would need to be dependent upon circulation (it already is)
  • Uses familiar synchronous request-response HTTP API integration
  • Process oriented APIs are a familiar style in circulation

Inventory Updates Requests

Inventory could implement the whole process. Inventory would update requests synchronously using request-response HTTP APIs.

Considerations

  • Process modelled in inventory
  • Inventory would need to understand requests for items
  • introduces dependency between inventory and either circulation or circulation-storage
  • Uses familiar synchronous request-response HTTP API integration
  • Process oriented APIs are an unfamiliar pattern in inventory

Remarks

If a dependency is introduced on circulation it stops circulation depending upon inventory. A workaround for this is to depend upon storage interfaces instead of business logic interfaces.

Inventory Notifies Circulation When An Item Is Withdrawn

Inventory could implement the primary part of the process where the item is withdrawn. That would include notifying interested parties that the item had been withdrawn. Asynchronously, circulation could then, at some point later, react to the item being withdrawn by updating the request.

Considerations

  • Primary process modelled in inventory synchronously
  • Secondary process modelled in circulation asynchronous
  • Inventory remains unaware of circulation
  • Circulation only aware of request aspects of process
  • Uses unfamiliar event publishing mechanism
  • May need to consider different kinds of failures
  • Introduces event publishing and subscription dependencies in inventory and circulation

Remarks

Asynchronous processes are a process modelling decision that should be made by POs and SMEs. They require acceptance of latency between sub-processes, the potential for eventual consistency and likely different forms of failure

FOLIO often does not reliably handle failure between contexts when using synchronous request-response HTTP APIs, so it might be acceptable for the time being for failures to be tolerated when using publish-subscribe APIs


TODO

  • Diagrams outlining the high level architecture of each option