Overview
Introduce new item resolution capabilities that increases the volume of OpenRS borrowing and the speed of item delivery to patrons. Other item resolution capabilities will better balance the distribution of item requests for suppliers.
In the first release of new item resolution capabilities, OpenRS will allow requests on items with holds and, items that are checked out.
In a subsequent release, two additional capabilities will be introduced. One is to prioritize item resolution by preferred suppliers. The other is to use automated request balancing to provide more even distribution of item requests to suppliers.
All request capabilities must be compatible with one another and yet must stand independently without reliance on any other resolution factor. A set of rules and the ordering of those rules is intended to funnel down to the item which best achieves the goal(s) of the capability. For the first release, the order of rules will remain static. For the subsequent release, it is yet to be determined whether static or dynamic ordering will be required.
Scope
Releases
Requirements, implementation and deployment are staggered by release and grouped by customer.
Release 3 will meet the delivery of MOBIUS contractual development:
DCB-1530 - Getting issue details... STATUS
DCB-1549 - Getting issue details... STATUS
Release 6 will meet the delivery of GALILEO contractual development:
DCB-1541 - Getting issue details... STATUS
DCB-1540 - Getting issue details... STATUS
DCB-1550 - Getting issue details... STATUS
Functionality
Item resolution factors
Following are the item resolution factors corresponding to each capability. The list includes existing and new capabilities by release:
Circulation status (existing)
Geographic proximity (existing)
Loans (release 3)
Holds (release 3)
Preferred suppliers (release 6)
Auto request balancing (release 6)
Rules
Loans and holds
The following rules ranked by order of evaluation are intended to support the goals for each capability:
On-shelf ranks above loans, ranks above holds
When all items are loaned, the item due soonest is selected
Overdue items are not resolvable.
When all items have holds, the item with the least number of holds is selected.
If a library system is unable to supply an item count of holds because the platform does not support it (e.g. Polaris), rank items from that library lower than other libraries that are able to provide hold count.
When all item resolution determinants are equal (e.g. all items on-shelf) and geographic proximity is enabled, use geographic proximity to determine which item is selected to place the request
If no other resolution determinants are enabled, choose an item at random.
Preferred suppliers and auto request balancing
When preferred suppliers are also enabled, use a preferred supplier from the same group.
If more than one supplier in the same group, use geographic proximity OR load balancing to make the selection
If a preferred supplier is not found, and more than one supplier is outside the preferred group, use geographic proximity or load balancing to make the selection
Acceptance Criteria
When an item is not selectable…
When an item…
Filter and Sort / Pool and Rank
Selectable Pool
Applies to all resolution strategies (including manual selection)
These suppression and selection factors determine (and limit) the pool of potentially resolvable items
CONTRIBUTED / DISCOVERABLE (BIB)
Bib suppression / discovery flag
Per library bib suppression rules
DISPLAYABLE (ITEM)
Display Suppression
Deleted items
Per library suppression rules
Shelving location
CIRCULATABLE (ITEM)
Item is from cancelling supplier
Item Ranking
Applies to all resolution strategies, except manual selection
Items are sorted and resolved in order
Item is from borrowing library’s preferred supplier group
Item is available (on shelf)
Item is currently loaned
due soonest
Item has holds
fewest holds
Geographic proximity
Technical Notes
Previously included in the context of DCB-1411
How re-resolution should work with preferred supplier and load balancing features
Currently org.olf.dcb.request.resolution.PatronRequestResolutionService has a method resolvePatronRequest which is called once in the flow. This story will cause re-execution of this method.
Currently the method performs the following steps
return Mono.just(Resolution.forPatronRequest(patronRequest))
.zipWhen(this::getAvailableItems, Resolution::trackAllItems)
.map(this::filterItems)
.flatMap(this::decideResolutionStrategy)
.flatMap(function(this::applyResolutionStrategy))
.doOnError(error -> log.warn(
"There was an error in the liveAvailabilityService.getAvailableItems stream : {}", error.getMessage()))
.switchIfEmpty(Mono.defer(() -> Mono.just(noItemsSelectable(patronRequest))));
There are three item resolution strategies currently defined:
FirstRequestableItemResolutionStrategy.java
GeoDistanceResolutionStrategy.java
ManualSelectionStrategy.java
The default for normal book lending is Geo Distance. Any implementation can change the default strategy with an environment variable. New strategies can be added at any point. It is important to maintain the item resolver interface ResolutionStrategy.
public interface ResolutionStrategy {
String MANUAL_SELECTION = "ManualSelection";
// Resolution Strategies must return a code which can be used to select
// an implementation based on config
String getCode();
Mono<Item> chooseItem(List<Item> items, UUID clusterRecordId, PatronRequest patronRequest);
}
As long as we maintain this clean separation, different choices with requesting groups and load balancing are constrained to the applyResolutionStrategy section - so this code does not interact in any way with requesting or re-reqesting. All that happens is that the resolutionStrategy has to return a specific item to try and get hold of. It is essential that any resolution strategy tries to reduce the list of possible items down to a specific one to “Try next”.
It is expected that a new GeneralResolutionStrategy will be created which allows systems to specify the sort and filter criteria of the items in the input List. For example - Filter [“available items”, “Not already tried”], sort by [“MyLendingGroup”, “GeoDistance”] or “Sort by [“My Lending Group”, “SupplierLoad”].
GeneralResolutionStrategy will then choose the item that sorted highest as the next item to try and request.
In this way resolution strategies are entirely isolated from the re-request process.