APIS for Back-Office Functions Helping customers help themselves Andy Kohler - UCLA - Voyager Developer Meeting - February 1-2,

What’s an API?  API = Application Programming Interface  Allows programs to interact with other programs  Examples:  SOAP / REST APIs for Voyager 7+ OPAC  Voyager BatchCat.dll Andy Kohler - UCLA - Voyager Developer Meeting - February 1-2,

APIs are for more than OPAC  Acquisitions  Cataloging  Circulation  System Administration  Staff searching, including suppressed records Andy Kohler - UCLA - Voyager Developer Meeting - February 1-2,

Why not use macros?  Macros require a user interface  Macros are fragile, subject to  User interface changes  Network & display latency  A carelessly-written macro can be as destructive as any API-based program… and is likely to be written by a non-technical user Andy Kohler - UCLA - Voyager Developer Meeting - February 1-2,

Key API characteristics  Platform-neutral  Programming language-neutral  Enforce business rules  Enforce data integrity  Fully documented  Same APIs used by vendor for its own development Andy Kohler - UCLA - Voyager Developer Meeting - February 1-2,

Why APIs are important  No vendor can anticipate every customer need, nor build an interface which supports every workflow  Allow customers to do whatever the business rules permit – safely Andy Kohler - UCLA - Voyager Developer Meeting - February 1-2,

Why APIs are important  Staff time is precious – save it for tasks requiring thought  Automate routine tasks  Do batch updates quickly  Exchange data with other systems  Enhance and extend functionality Andy Kohler - UCLA - Voyager Developer Meeting - February 1-2,

Automate routine tasks  Cancel old orders automatically, without manual review via Problems report  Delete old “on-the-fly” records after items are returned Andy Kohler - UCLA - Voyager Developer Meeting - February 1-2,

Automate routine tasks  Adding a new location in SysAdmin requires:  Add to Acq/Cat/Circ policies  Add to Acq/Cat/Circ/Master security profiles (UCLA has 39)  Several clicks for each = a tedious & error-prone process Andy Kohler - UCLA - Voyager Developer Meeting - February 1-2,

Do batch updates quickly  Add/change/delete MARC records  Consistent notes & formatting  Retroactively improve records  Location changes & merges  Set prices on items based on subject / location / publication place  Delete unused vendors Andy Kohler - UCLA - Voyager Developer Meeting - February 1-2,

Exchange data with others  Two-way exchange of patron billing data with campus system (campus bills the students, we load payments into Voyager to clear blocks)  Add check/payment information to Voyager invoices from campus accounts payable system Andy Kohler - UCLA - Voyager Developer Meeting - February 1-2,

Enhance functionality  Retain patron/item history based on time (e.g., 1 year), not number of patrons (e.g., last 3 patrons)  Overcome client design limitations (e.g., web app for adding operators to all relevant security profiles at once) Andy Kohler - UCLA - Voyager Developer Meeting - February 1-2,