Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Next »

https://openlibraryfoundation.atlassian.net/issues/?jql=issue%20in%20(DCB-1549%2C%20DCB-1541%2C%20DCB-1540%2C%20DCB-1530%2C%20DCB-1411)

Overview

The primary driver in determining item resolution is speed of delivery.

Factors used to determine item resolution are:

  • Circulation status

  • Loans

  • Holds

  • Geographic proximity

  • Preferred suppliers

  • Auto request balancing

Rules

  • On-shelf ranks above loans, ranks above holds 

  • When all items are loaned, the item due soonest is selected 

  • When all items have holds, the item with the least number of holds is selected 

  • When all item resolution determinants are equal (e.g. all items on-shelf) and geographic proximity is enabled and preferred suppliers are not enabled, use geographic proximity to determine which item is selected to place the request

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

Scope

Requirements, implementation and deployment are staggered by release and grouped by customer.

For MOBIUS, the scope of new development is limited to:

DCB-1530 - Getting issue details... STATUS

DCB-1549 - Getting issue details... STATUS

For GALILEO, the scope of new development is limited to

DCB-1541 - Getting issue details... STATUS

DCB-1540 - Getting issue details... STATUS

That said, all resolution capabilities must be compatible with one another and yet can stand independently without any of the other resolution capabilities. That said, there is no requirement to allow for reordering of the rules.

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

  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.

  • No labels