Withdrawn Items - Design Options

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