Page Comparison

...

1. Item is from borrowing library’s preferred supplier group

2. Item is available (on shelf)

3. Item is currently loaned

   1. due soonest

4. Item has holds

   1. fewest holds

5. 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.