Tech Blog

Technical Services Toolbox for Alma

Introduction

The Technical Services Toolbox for Alma (TSTA) is a Windows desktop app that pulls together a number of functions to automate some of the more onerous tasks that Technical Services has to do (at the University of Manitoba anyway, also in some other libraries no doubt).  Some of these tasks were post-migration data cleanup (we migrated from Sirsi Symphony in 2014).  Others are ongoing.  Since these are Technical Services functions, the app is intended to be installable and runnable by Technical Services staff.  The app uses Alma APIs.

How to Get It

A download link is included in the manual.  Please read the manual before you use the app.  Some of the modules can change thousands of records in Alma at a time and you should know what you’re doing before you try it out.  You can also set the app up to run in your Sandbox (if you have one), which I strongly encourage before you use it on your production data.  The app itself will also warn the operator before it does anything that can make changes in Alma.

Modules

The app is organized into several modules, each of which performs a specific set of tasks:

Volume Designation Mover

Because Sirsi Symphony didn’t use holdings records, Alma had to create them on the fly during migration.  For some reason we ended up with a holdings record for each volume of our print serials and many of our monograph sets, with the volume designation residing in the holdings call number.  Furthermore, the entire call number was in a single 852 subfield ($h) instead of in two separate subfields.  A single item record was attached to each holding record, and the item record contained no volume information.  For example:

Holdings Record 852

8520_ |b SCI_TECH |c FOURTHFLR |h 574.W287 V. 34-38:1976-80

There would be a single item record attached to this holdings record with no enumeration, chronology, or description.

At U. Manitoba we don’t use enumeration or chronology for our serials; instead, we put the volume designation into the Description field of the Item record.  What we wanted was a properly-constructed 852 in the Holdings record and the volume designation in the Description field of the Item record.  The corrected Holdings record would look like this:

8521_ |b SCI_TECH |c FOURTHFLR |h 574.W287

And the attached item record would have the volume designation in its Description field.

Doing all this manually for the millions of affected records would have taken many people many years to do.  TSTA automates most of this work and enabled us to finish the project in about a year with only a few people working on it part time.

852 Reformatter

Another legacy of migrating from a system that didn’t use holdings records was that our 852 fields in our Alma-generated holdings records were all improperly formatted.  The entire call number was in the $h subfield instead of $h for the LC class number and $i for the book number, which caused sorting problems in Alma.  The indicator for non-LC call numbers (which we use for some collections) was incorrect (always set to “0” for LCC), which was causing problems in Alma Analytics when we tried to create reports that used call numbers.  Finally, our formatting of LC call numbers was idiosyncratic – a legacy of the 1980s (maybe earlier?) that we wanted to get away from because it often caused problems when we shared our records.  Like the volume designation problem above, doing all this work manually would have taken many years, so the 852 Reformatter was designed to analyze all our call numbers and reformat them to comply with MARC standards.  It allowed us to complete this work in a matter of months and most of that time is just waiting for it to run in the background.

Funds Monitor

We have hundreds of acquisitions funds (mostly because of gift funds), with various people managing each.  Our Finance Office had to spend weeks monitoring them every year, sending reminders to the people who are responsible for the funds when they either over-committed or under-committed them.  This work was done periodically during the fiscal year but intensified as we approached year-end, which was already her busiest time.

The Funds Monitor now does most of the monitoring for her.  She sets up targets for each fund:  the minimum and maximum percentages that should be spent out at various points in the year.  Then once a month or so she goes into the Funds Monitor and tells it to do its check.  It automatically identifies which funds are either overcommitted or undercommitted according to the targets and sends notification emails to the people who are responsible for the funds.  What used to take hours now takes minutes.

Import Inspector

The Import Inspector is designed to do some automated checks on records recently imported into Alma (“incoming records”).  It can generate shelflisting warnings and receiving alerts based on data in the bibliographic record.  For shelflisting, it can warn you if an incoming record doesn’t seem to be sitting with other editions of the same work on the shelf or if an incoming literary work doesn’t seem to be sitting with other literary works by the same author.  For receiving alerts, it can add a message to the order record based on data it finds in the bibliographic record so that receiving staff can take appropriate actions.  For example we have to add bookplates to books purchased with specific gift funds.  Our cataloguing vendor puts the fund in the bibliographic record and the Import Inspector looks for these fund codes and when it finds one that needs a bookplate it adds a note to the order record telling them what bookplate to add.  Receiving staff see this note when the book arrives and affix the necessary bookplate.

More Information

The Technical Services Toolbox for Alma manual has detailed information on everything in this blog post.  Please make sure you read the part related to each of the functions before you try them on your production data.  You can also contact me if you have any questions or issues.

5 Replies to “Technical Services Toolbox for Alma”

  1. Ooh, I’ll have a look at the 852 Reformatter. We have tens of thousands of call numbers in 852 $h with no $i for the same reason (data originally created in Symphony 8+ years ago).

  2. I’m pleased to report it’s working a treat – it’s made the impossible possible. (I may email you some feedback about the UI.) I received an email from ExL today about TLS 1.0/1.1 being deprecated for API beginning this month, and the traffic report confirms those calls were coming from this tool. Will you be updating it to use TLS 1.2?

  3. Hey Lisa,
    I thought I’d replied to your post but apparently not. First, I’m really glad that TSTA has helped you out, and I’d be happy to hear your UI comments. Regarding TLS, I’m not well-versed in it but have done some reading. I *think* TSTA uses the most recent version of TLS supported by Windows on the computer it’s running on, but it’s also possible that the version of .NET that TSTA is built for doesn’t support TLS 1.3 so I’m going to rebuild it for the latest .NET version. Interestingly (and a little confusingly!), although we’ve been getting the TLS warnings from Ex Libris as well, the API keys Ex Libris identified are *not* the ones used by TSTA, but by a single user’s installation of an old version of SpineOMatic. But maybe some of the TSTA functions that we no longer use are responsible and that could be why you’re seeing this and we aren’t. Anyway I hope to rebuild, test, and post an update sometime today that will hopefully ensure that deprecated versions of TLS are no longer used. Thanks for letting me know about this!

Leave a Reply