Troubleshooting when a patron is not loaded into Alma as expected or being updated by the patron loader as expected
- 1 If new patron: double-check the search in Alma
- 2 If existing patron: check for multiple accounts
- 3 If existing patron: check the identifiers
- 4 If existing patron: check the record type
- 5 If existing patron: are they a recent DKU graduate?
- 6 Check the directory for the patron affiliation
- 7 Check the Alma job report for the day the patron was loaded and/or the most recent full patron loader run
- 8 Check Identity Management data - users.txt file
If new patron: double-check the search in Alma
If a new patron, check Alma to be sure the account doesn’t exist, in case there was a typo when searching.
If existing patron: check for multiple accounts
Patrons may have had multiple accounts in Aleph, and the identifiers may be wrong on the account that you expect to be updated.
If existing patron: check the identifiers
The patron record must have an identifier of type Duke ID with the value set to their Duke Unique ID. If the Unique ID is not on the record, it will not be updated.
If existing patron: check the record type
If the record type is set to Internal, the patron loader will not update it. The record type must be toggled to external.
If existing patron: are they a recent DKU graduate?
If the patron graduated from DKU in the past year, they might be still showing up in the feed with a DKU primary affiliation of STUDENT, and a DKUinDurham flag of '0', which will cause them not be added to the XML file for the patron loader. See Users Administration | A student recently graduated from DKU and started a graduate program at Duke th...
Check the directory for the patron affiliation
Check the directory (https://directory.duke.edu) - they must have a status there of faculty, staff, or student to be loaded. If it says only says Affiliate, they won’t load automatically.
Check the Alma job report for the day the patron was loaded and/or the most recent full patron loader run
If there is a specific date they anticipated the patron would be loaded, review the patron loader job report for that day. Review the error list to see if the patron appeared there. (Admin > Monitor Jobs > History, select the date or date range, filter to Users.)
NOTE: The “Records processed” number for this job is meaningless for troubleshooting, it is a number that means something to ExLibris developers but is not the number of patron records. (link)
Check Identity Management data - users.txt file
If none of that is helpful, next step is to review IdM data.
Review the users.txt file from the last full patron loader run. This is the user-friendly file delivered to us by IdM, one patron per line. We get a copy of the file every day, but we only have it scheduled to load into Alma once a week, on Saturday mornings.
The most recently used file can be found at /home/dul-lsis-ftp/alma/production/users/full/users.txt. Download it locally to review.
User not in users.txt file
If you’re not looking at the users.txt file from the current day, run the gitlab full pipeline to get the current day’s file. In Gitlab, the full pipeline can be kicked off from Build > Pipeline Schedule > All Users. Click the Play button. It will download a fresh “users.txt” file to that directory, and build a fresh users.xml file for review in step 2 below. If the user still is not in the fresh “users.txt” file, then there is a problem with their appointment, and they should be referred back to their HR person.
Remember to delete the users.xml file that was created so that you don’t have problems when the next full user synchronization happens (Saturday AM)
User record is in users.txt file
If the patron has a record in the full users.txt file, review the XML generated in /home/dul-lsis-ftp/alma/production/users/full/users.zip. Download it locally to review. Note that it is a very big file when extracted and can be slow to page through / search.
If the patron is in the users.zip XML file and it looks as expected, run the full patron integration (General > Integrations > Patron Loader - Full > Actions > Synchronize > Run).
DO NOT CHANGE ANY OF THE SETTINGS IN THIS INTEGRATION. You can inadvertently break a lot of stuff!
Note that this can take 20-30 minutes to complete, depending on available resources in Alma. After it finishes running, check for the user account - it should have loaded into Alma.
If the patron is not in the XML file, or there is an error that cannot be easily understood, create a Jira for a developer to investigate.
If you don’t run the user synchronization as described above, remember to delete the users.xml file that was created so that you don’t have problems when the next full user synchronization happens (Saturday AM)