...
Scope: This document focuses solely on Polaris LMS.
| Table of Contents | ||
|---|---|---|
|
Current Polaris Patron Methods
Finding Virtual Patrons
...
The DCB Service utilizes the PAPI Service API method "Patron Search" to locate virtual patrons. This method relies on the "PATNF" field (Name - First, Middle, Last) and the "real" patron's barcode. Documentation for this API can be found here: https://documentation.iii.com/polaris/PAPI/current/PAPIService/PAPIServicePatronSearch.htm#papiservicepatronsearch_3172958390_1270206
Creating Unique Virtual Patrons
...
The DCB Service creates virtual patrons using the "PatronRegistrationCreate Version 1" method within the PAPI Service API. Details and request body example can be found here: https://documentation.iii.com/polaris/PAPI/current/PAPIService/PAPIServicePatronRegistrationCreate_v1.htm
Patron Field Usage in DCB Polaris Patron Creation
PatronBranchID:
Usage: Specifies the item location ID.
Source: Derived from the items assigned branch ID.
...
Usage: A mandatory field in Polaris.
Value: A fixed date "1999-11-01".
Potential Issues with Patron Search
Missed Patrons
...
In some cases, the search might miss existing virtual patrons, leading to the error “Unable to create virtual patron at polaris - error code: -3529” when the DCB Service attempts to create a new one. Examples of such requests can be found here:
Ambiguous Matches
...
Due to relying on the "PATNF" field, situations can arise where the real patron's barcode is also a name. This leads to finding multiple virtual patrons, stopping the DCB Service from processing the request. Examples can be found here:
False Positives
...
There's a possibility of finding the wrong virtual patron due to limitations in barcode-based searching. If the initial search returns a single (incorrect) match, the DCB Service might proceed with that patron, potentially leading to issues with supplier-side requests.
Improving Patron Search Reliability
Addressing Ambiguity
Leverage Unique Identifiers that DCB currently holds such as; Existing Local patron ID (Patron Identity), DCB’s Patron UniqueId and DCB Patron UUID.
Expand the search criteria to include checks when multiple patrons are found to improve accuracy and reduce ambiguity.
Implement a strategy to validate exact matches by cross-checking multiple criteria, helping to minimise false positives.
Improving Diagnostics
Enhance patron search logging to capture specific details about search failures, including search criteria, results, and potential reasons for mismatches.
Monitor the performance of patron search queries to identify success rate/failure rate.
Develop more rigorous testing strategies for testing current known issues.
Identifying DCB Virtual Patrons
Consider using the PATNL field to search by DCB’s Patron Unique Id.
Consider using the existing Patron identity local ID if it already exists in DCB.
A script querying the patron barcode prefix can potentially identify all virtual DCB patrons that exist in a local Polaris system.
Assessing the Viability of Virtual Patron Deletion
Prerequisites
A reliable patron search mechanism is essential to accurately identify and target virtual patrons for deletion.
Conduct a thorough impact assessment to understand the potential consequences of deleting virtual patrons, including data loss and system disruptions.
Key Considerations
In-Flight Requests: Identify and address any in-flight requests associated with the virtual patron before deletion.
Data Retention Policy: Establish a clear data retention policy to determine how long virtual patron records should be retained before deletion.
Backup and Recovery Strategy: Develop a robust backup and recovery strategy to minimise data loss risks associated with deletion.
Testing and Pilot: Implement a phased approach with rigorous testing and a pilot program to evaluate the feasibility and impact of virtual patron deletion.
Outstanding questions:
How can we ensure that the correct
UniqueIdis used from the list ofUniqueId'sthat DCB stores to find the virtual patron? I.e., theUniqueIdstored on the virtual patron record matches the one DCB chooses to search by.Are local patron IDs reused in Polaris? If so, could this lead to matching the wrong patron?
Which field in the patron record would be best suited for storing our chosen unique identifier? Is the
PATNLfield a valid option? Which is currently in use.If multiple virtual patrons are found, what criteria should we use to identify the correct one?
What cross-checking criteria can we apply to minimise the risk of false positives?