Olly olly oxen free: users of Evergreen APIs, stand up and be counted


Does your project, service, or product interact with Evergreen in some automated fashion?  If so, we’d like to hear from you.

I’m using the phrase “automated fashion” very broadly.  There are many ways to receive data from an Evergreen system, update data in an Evergreen database, or make transactions happen.  A few of these ways include:

  • XML-RPC calls to invoke Evergreen service methods
  • SIP2 to perform patron and circulation requests
  • Z39.50, unAPI, and OpenSearch to retrieve catalog data
  • MARC exports and imports
  • Screen-scraping (although if you’re screen-scraping Evergreen, we may be able to suggest a better way to do it)
  • Interacting with the Evergreen staff client
  • Direct database access
  • And others

Some of the things we’d like to know include:

  • The name of your service or product
  • What it does for an Evergreen library
  • How it is accessing Evergreen
  • Whether there are specific APIs or entry points that your application depends on
  • If there are things that Evergreen could be doing to make your life easier

We want to hear from everybody, whether you are a consortium that has integrated Evergreen with other software, an Evergreen support group,  a vendor providing products or services to libraries, or a member of a free software project whose software talks with Evergreen.  If you work for an Evergreen library and know that Evergreen works with another service, we want to hear from you too, even if you don’t know how Evergreen is doing the talking.

Why do we want to know?  Our reasons include:

  • Finding out which entry points we should be particularly careful about changing as Evergreen gets enhanced.
  • See if there are things we could be doing better to encourage more people and applications to participate in the Evergreen ecosystem.
  • (Maybe) putting together a list of third-party services that interact with Evergreen.

To respond, please comment on this post.


5 thoughts on “Olly olly oxen free: users of Evergreen APIs, stand up and be counted

  • Dan Scott

    We (Laurentian University, part of the Conifer consortium) automatically provision user accounts and barcodes by polling our university LDAP directory for recently created accounts, searching for an existing account with matching username, and generating an account if required. In return, we push the newly created barcode back to the LDAP directory so it can be integrated into the university ID card.

    The bulk of the logic can be found in ldap_osrf_sync, along with the simple webui.py that enables staff to dynamically create an account via a Web form–useful for alumni or accounts that might have somehow escaped our regular polling.

    This commit points at some of the OpenSRF method and database tweaks we made to accommodate these requirements more generically, so that the University of Windsor was able to adopt a similar approach.

  • Art Rhyno

    Dan Scott’s great LDAP syncing work allowed Windsor to implement CAS (Central Authentication Service), this commit is the last step of the process, which was to support tpac’s ability to drop you anywhere in the catalogue at the point of authentication (for example, authenticating at the point you place a hold). We use Dan’s LDAP work to populate the patron database with the University of Windsor userids, and then CAS handles authentication without the need to store passwords or personal information in the patron database. Evergreen’s plug-in authentication support made this a breeze, and it also allowed us to fit into the campus mobile application which uses CAS for all campus systems that require authentication.

    I have only poked at this but opensrf’s json support fits really well into google document scripts. The only example I have looked at is using opensrf and OCLC’s xISBN service to check a workbook containing ISBNs to see whether an edition of a book is in the library, but I would think you could wire in anything from the library system to a google document with this approach.

  • Jason Stephenson

    I shall enumerate the main points:

    A program to export and import records to and from Backstage Library Works. This one makes heavy use of open-ils.cstore and CStoreEditor.

    A collection of Evergreen utilities that use open-ils calls via OpenSRF. A couple of these utilities use DBI rather than OpenSRF. We have another collection of utilities that are related to our own workflow and thus not shared with the community. This latter group mostly concerns things specific to our stat_cats and so on.

    Some database helper functions for creating circ matrix matchpoint, hold matrix matchpoint, and group penalty entries. We’ve offered these for inclusion in Evergreen proper, though not via Launchpad.

    A simple, menu-based console client that is used by our current statewide virtual catalog to perform actions in Evergreen via expect scripts.

    Another batch utility to update database records from our Safari Books Online subscription.

    We also have a web authentication page that uses SIP2 to authenticate patrons against the catalog. This is used by some database vendor or another in their authentication of patrons who are not in the library.

    Then, we have piles of one-off scripts, programs, and SQL used to fix specific issues or change specific settings.

    For the most part, we use the Perl libraries for OpenSRF/OpenILS or the Perl DBI. We also do some things directly with SQL. We’re not presently using XML-RPC or the gateway or translator directly in in-house programming.

  • Rob Klaus

    Unique uses the XML-RPC gateway to access the functions contained in the Collections.pm module, as well as a few miscellaneous other functions. We do this for 92 customers across 16 separate Evergreen installations. Happy to work with anyone involved to provide more detail if necessary. -Rob

  • Nick Lopez

    I’m just now putting the finishing touches on a script to automate adding patrons when they request access. The script directly manipulates the actor.usr and actor.card tables to add or update patrons when they request access through a web form. The webform gathers the information we need from university data sources and restricts submissions to the appropriate people. I looked for an API I could use to insert users so I went to direct DBI::Pg.
    Oh, I’m also pulling some data points out with perl/DBI to monitor and make some numbers available for mucky-mucks. (how much of the inventory is checked out right now, how many peopled have registered, etc).

Comments are closed.