2010 Sopac Cosugi

Lake Buena Vista, Florida – March 3-5, 2010

Sopac connectors for Sirsi

Sean Robinson Allen County Public Library

Fort Wayne IN


The history

• 4-5 years ago I meet John Blyberg in Ann Arbor, Michigan and they has just integrated III into Drupal 4 but it was a very customized solution.

• 2-3 years ago I came to my first Sirsi conference and there seemed to be an interest in the Sirsi community to separate the data from the presentation layer.

• 1 -2 years ago John wanted abstract the SOPAC design so it could be integrated into any OPAC and he asked if I would be interested in writing the connector code for SIRSI.

• I said, Yes! He gave me the source code for III and I translated the code into Sirsi speak and made a few alterations.


How in the H*LL was I going to do this?

• I wanted all the data that could be real-time data to be real-time data.

• I wanted the design to simple, clean and easily understood.

• I wanted it to work across Sirsi/Dynix versions.

• I wanted to follow John’s vision and completely separate data layer from the presentation layer.


Decisions

• How was I going to get the data? I had two choices, either the API or the XMLAPI. My choice was to use the XMPAPI.

• What is the most universally useful way to present the data? I felt that creating a set of independent building blocks that programmers could use independently was the design I wanted to follow. So, creating a set web services seem the most generic and logical solution. People could then use these services in the future for anything.

• The XMPAPI gave me the freedom to create these services in Perl simple and clear manner. Parsing XML would be easy.


Design elements


Webservices on Sirsi

• Hold_status.pl – Checks to see if in transit, available.

• Item_status.pl- Gets call number, home location, item number, item location now.

• Item_type.pl – Input is catkey and result it item type.

• Item_avail.pl – Does some location checking to find item. We want to check that the item is at the same location as the home location for the patron and then if this is not true to locate another item.


…more Webservices on Sirsi

• Patron_bib.pl – Dumps bib information based on cat key.

• Patron_details.pl – Gets patron information.

• Patron_dump.pl – Gets addition patron information.

• Patron_tools.pl Handles renew, cancel hold, place a hold.


How was I going to pass data to another computer?


Adding Drupal into the equation


Sopac structure


ILS Connector

• The connector is constructed using three standalone php classes. (Written in php because that is the development language of Drupal)

1 Sirsi_patronapi.php

2 Sirsitools_3125.php

3 Locum_sirsi_3125.php


Sirsi_patronapi.php

• This gathers patron information, name, address, holds, bills, charged items, home library etc…

• All this data is then held in various a data structures.

• Only item of information that is passed to the web service is the patrons library card.

• This was the first connector piece that I wrote.


Sirsitools_3125.php

• Creates and instance of the patron_api object and populates it with data.

• Renew of material.

• Cancel a hold.

• Places a hold.

• This was the second class that I wrote.


Locum_sirsi_3125.php

• Returns bibliographic information. in locum ready array. This is done with the catalog key rather than item key.

• Returns item status. Is the item available, on hold, copies available, now many etc…

• Here we are using both previous classes to get data and perform functions to pass as data structures to locum.

• This was the last class that I wrote.


Getting the data from MARC

Question: Why not just dump the data with the catalogdump command?

Answer: It would have involved a major rewrite of John’s code and effected compatibility and overall philosophy.





• Originally the catkey was feed to catalogdump and the MARC record was returned and then parsed into the MySQL database.

• Problem was that we had to spawn a catalogdump process to each catkey request. We have about 1.5 million records and it was going to take about a week to import the database.

• The other problem was the http protocol overhead with running this as a CGI.

• So here is the solution.





• We wrote a MARC server that has catalogdump running as a daemon. We only have to spawn the process once.

• The MARC server is constantly checking for connections.• Once it receives a connection is checks for completeness.• Sends it to the catalogdump.• Waits for response from catalogdump.• If there are errors they are sent to the errorlog file.• Sends MARC back to SOPAC• Performance increase of 200 records per second. • One day to process 1.5 million records.


Look and feel


Look and feel


Look and feel


Look and feel


Look and feel


Look and feel


Look and feel


Look and feel


Look and feel


Look and feel


Contact information

Sean RobinsonEmail : [email protected] : www.tscrobinson.com

Technology

2010 Sopac Cosugi