Tech Blog

Alma – OCLC Tipasa NCIP integration

At Leiden University Libraries we were sort of a development partner in cooperation with both Ex Libris and OCLC for the integration between Alma and OCLC Tipasa.  We are using the integration in our Alma/Primo production environment since January 2019.

The purpose of this post is to share our experiences and knowledge gained during the implementation.

NCIP 2.0
The Alma – Tipasa integration is broker-based, supported by the NCIP 2.0 protocol.
The following messages are supported:

Borrower side

  • Accept Item – When physical item is received
  • Check In Item – When physical item is sent back to the lender
  • Create User Fiscal Transaction – For creating a request fee

Lender side

  • Check Out Item – When item is shipped to the borrower
  • Check In Item – When item is received back from the borrower

Authentication
We use the Dutch identity management service SURFconext to authenticate our users (students, employees and guests) for Tipasa. After authentication a brief user record is created in Tipasa containing name, e-mail address and identifier. Tipasa uses the SURFconext eduPersonPrincipalName attribute (usually filled with user@domain) as identifier. This identifier is used in the NCIP messages sent between Tipasa and Alma. Because the eduPersonPrincipalName wasn’t available as an identifier type in Alma, we had to update all our Alma user records with this new identifier.

In the Alma Resource Sharing Partner record the user identifier type that should be used in the NCIP communication can be selected.

Patron Load
It’s possible to use the Tipasa Patron Load (initial and ongoing, sent via SFTP in either tab-delimited or XML format). This allows for the creation of more robust patron records and keeping the patron data up to date more easily.

We’ve decided not to use this option. According to OCLC an API (based on SCIM 2 protocol) will become available in the near future. We’ll use that for managing our Tipasa user records.

Borrower workflow

  1. There are 2 ways our patrons can place an ILL request:
  • Via a direct link to the Tipasa ILL request form. After login via SURFconext the patron has to fill in the form.
  • Via the “Request through ILL” link in WorldCat. This link appears on item level in WorldCat and directs the patron to the Tipasa ILL request form. After login via SURFconext the form is populated with title data from WorldCat:

    We also offer this service to patrons outside our Library network via EZProxy.
  1. Depending on your Tipasa configuration settings a request can either be sent directly to the Lending library or needs to be approved in Tipasa first. We’ve decided to route requests from newly registered patrons to “New for Review” so their account can be verified prior to processing the request.
  2. After our staff has approved a patron in Tipasa the request is sent to a lending library.
  3. The item arrives at our library containing a print slip with a Tipasa Request ID.
  4. We look up the item in Tipasa by scanning the Request ID and mark the item as received:

  5. The NCIP Accept Item message is sent, creating a Borrowing Request and a Temporary, suppressed, item in Alma.
  6. Alma can be configured to automatically receive the item and either place it on the hold shelf for the patron or place it in transit to the desired pickup location. Unfortunately Tipasa doesn’t (yet) send the pickup location along in the Accept item message to Alma. So for now we first have to check the desired pickup location in the Tipasa request. If the pickup location is different than our default pickup location, we’ll have to change that in the Alma Borrowing request first.
  7. In Alma, “Currently at” the Resource Sharing Library, the item is received:

  8. After receiving the item it’s placed on the hold shelf or goes into transit to another location where it can be scanned in and loaned to the patron. We’ve chosen to ignore the request’s due date from Tipasa and, when loaning the item to a patron, calculate the due date according to our own Terms of Use. This can be configured by setting the ignore_lender_due_date parameter to true (Fulfillment – Other Settings).
  9. The Alma NCIP profile also supports the Renew and Recall messages via NCIP, but unfortunately Tipasa doesn’t yet. This means that the renewal of an item in Alma doesn’t also renew the item in Tipasa and the recall for an item in Tipasa will not automatically recall the item in Alma.
    Instead you can manually renew an item in Tipasa:

          And manually recall an item in Alma:

          

  1. When the item is returned, we mark the item as returned in Tipasa:

  2. The NCIP Check In Item message is sent which deletes the borrowing request and the temporary item in Alma.
  3. Currently we don’t use the NCIP Create User Fiscal Transaction message for creating a request fee. During our testing/implementation this message was sent at the moment the Lending library shipped an item. Resulting in a request fee for the patron before the item even arrived at our library.
    How Alma should use the Create User Fiscal Transaction message can be configured in the Resource Sharing Partner record:

 

Lender workflow

  1. Alma supports the NCIP Request Item message, Tipasa doesn’t yet. This means that when a new Lending request arrives in Tipasa, we manually have to add the Lending request to Alma.
  2. In Alma, “Currently at” the Resource Sharing Library, go to “Fulfillment > Resource Sharing > Lending Requests > Add > From search” and look up the requested item.
  3. Select the right title and fill in the Resource Sharing Lending Request form, add the Tipasa Request ID as External identifier.
  4. An internal move request is created for the Lending request and a Pick from Shelf Slip is printed automatically. Make sure your resource sharing library is able to ship items from your other libraries. Use the Library Relation configuration menu (in the scope of the resource sharing library) to activate the Supply from relation:

    You’ll have to activate this relationship for any other library whose items the resource sharing library should be able to ship.
    Also, the relevant terms of use should be set with the ‘Is Requestable for Physical Resource Sharing’ set to ‘Requestable for physical resource sharing ’:

  5. We’ve changed the Pick from Shelf Slip so that the Tipasa Request ID is printed as a barcode on the slip:

  6. When the item arrives at the Resource Sharing Library we look it up in Tipasa by scanning the Request ID on the Pick from Shelf slip.
  7. We scan in our item barcode in Tipasa and select “Can you supply” Yes:

  8. The NCIP Check Out Item message is sent. In Alma the status of the Lending Request is changed to “Shipped Physically” and the item is placed in a Temporary Location.
  9. In Primo the item is marked as “Checked out from Resource Sharing Library”:

    We’ve changed the relevant Discovery Interface Labels so the status shown is “On Loan”:

  10. Following our Loan Policy the item can be requested. We scheduled an Analytics report to notify our staff in case an item that’s away for ILL is requested:

    Based on this report, staff can recall an item in Tipasa when it’s requested by one of our own patrons.

  11. When the item returns we mark it in Tipasa as “Checked-in/Complete”:

  12. The NCIP Check In Item message is sent. The item in Alma is received and goes into Transit to its permanent location.

Leave a Reply