Evergreen is an open source ILS (integrated library system) used by libraries to provide their public catalog interface as well as to manage back-of-house operations such as circulation (check-outs and check-ins), acquisition of library materials, and sharing resources among groups of libraries.
Because of the nature of ILSs, Evergreen has an interesting mixture of functionality. For example Evergreen is a metadata search engine, a transaction processing engine, a web application, and Evergreen is based on a robust, scalable, message-passing framework called OpenSRF.
Evergreen is built upon the Open Scalable Request Framework, or OpenSRF (pronounced “open surf”). OpenSRF provides communication between various “Applications” and the clients that wish to call them. Each application provides a service, and usually the applications are referred to as services because of this.
These applications are mostly written in Perl although some are written in C including:
1. opensrf.settings (Perl): Handles loading, parsing, and distributing configuration file information. This can include things like database connection information.
2. opensrf.math (C, Public, XML-RPC):Primarily for testing use, this service accepts requests and passes them on to the opensrf.dbmath service. Success demonstrates that not only can requests be sent and answers received but that services can communicate with each other.
3. opensrf.dbmath (C, XML-RPC):Primarily for testing use, this service does the actual processing for the opensrf.math service.
4. opensrf.validator (Perl):Implements a set of configurable validator chains for various data, such as email addresses.
5. open-ils.acq (Perl, Public):The Evergreen Acquisitions module.
6. open-ils.actor (Perl, Public, XML-RPC):Public and Staff Client access to user and org unit information.
7. open-ils.auth (C, Public, XML-RPC): Authentication service. Implemented in C for performance reasons, handles logins and authentication token validation.
8. open-ils.booking (Perl, Public):The Evergreen Reservations module.
9. open-ils.cat (Perl, Public, XML-RPC):The Evergreen Cataloging module, handling creation and editing of bibliographic and asset information.
10. open-ils.circ (Perl, Public, XML-RPC):The Evergreen Circulation module, handling checkins and checkouts, as well as Hold related information.
11. open-ils.collections (Perl, Public, XML-RPC):The Evergreen Collections module.
12. open-ils.cstore (C): CStore is a database search and retrieval service, and the default target for the CStoreEditor Perl class. It does not check or require authentication tokens. It can be used to perform complicated queries via json_query calls.
13. open-ils.fielder (Perl, Public):Currently unused(?) service for loading FieldMapper information.
14. open-ils.ingest (Perl):Currently unused pre-indb Ingest module.
15. open-ils.justintime (Perl, XML-RPC):Action/Trigger revalidator for use with things like external telephony.
16. open-ils.pcrud (C, Public):PCrud is a database search and retrieval service that checks and requires authentication tokens to control access to information. Unlike CStore it cannot "flesh" data at this time, requiring individual calls to retrieve data across links.
17. open-ils.penalty (Perl):A wrapper around the OpenILS::Utils::Penalty module for calculating patron penalties.
18. open-ils.permacrud (Perl, Public):A Perl authentication checking wrapper around CStore calls.
19. open-ils.reporter (Perl, Public):The Staff creation and query service for the reports system.
20. open-ils.reporter-store (C):Effectively CStore with a different name, so as to support a different set of IDL tables.
21. open-ils.resolver (Perl, Public):OpenURL holdings retrieval service. Note: Disabled by default.
22. open-ils.search (Perl, Public, XML-RPC):Searching related functions, including Catalog and Z39.50.
23. open-ils.serial (Perl):Serials-related tasks such as receiving items and generating predictions.
24. open-ils.storage (Perl):Direct database calls for various actions, intended in part to support databases other than PostgreSQL at some unspecified point in the future that will likely never come. Similar to a Perl-based CStore, but with more utility functions included.
25. open-ils.supercat (Perl, Public):Additional search and browse routines for various catalog elements, such as authorities, subjects, topics, call numbers, etc.
26. open-ils.trigger (Perl):The Action/Trigger subsystem, responsible for various notices and other automated tasks based on things such as circulation due dates, holds being available and/or canceled, etc and so forth.
27. open-ils.vandelay (Perl, Public):The bib import/export/overlay module.
Evergreen uses PostgreSQL. PostgreSQL databases are split into schemas, allowing for logical groupings of related information.
Below is a list of all schemas currently used by Evergreen.
1. public: This is a default PostgreSQL schema. No tables should be created here, although some generic functions are. New generic functions should be created in the evergreen schema, however.
2. acq: This is where Acquisitions specific data and functions live.
3. action: The action schema is used for storing data on things that have and/or are going to happen, such as Circulations, Holds, Surveys, and Transits. Note that reservation related information is stored in the booking schema, however.
4. action_trigger: This is where all Action/Trigger related information is stored, from event definitions to outputs.
5. actor: Actor covers Org Units and Users and information about them.
6. asset: Asset includes call numbers (volumes) and copy information. In addition, URI information is stored here as they are linked to call numbers.
7. auditor: The auditor schema contains non-acquisitions auditing information. Beyond functions for creating auditors nothing should be manually created here. Instead call the create_auditor function to create the auditor tables, views, and triggers.
8. authority: The authority schema covers all authority related information and functions.
9. biblio: The biblio schema is for bib records and related items. Note that most search and other indexing actually happens in the metabib schema.
10. booking: The booking schema covers the reservation system's information.
11. config: Most (but not all) configuration related tables live in the config schema. The tables are commonly used as lookup tables for values stored elsewhere.
12. container: The container schema is the storage location for buckets. Note that OPAC Bookbags are a type of biblio record entry bucket.
13. evergreen: A generic schema mainly for holding generic functions. Ideally tables and views should be created elsewhere.
14. extend_reporter: For the most part the extend_reporter schema is intended for local table, function, and view additions for reporting purposes.
15. metabib: The metabib schema holds pre-parsed metadata about bib records, including search information, pre-extracted MARC data, and facet data.
16. money: The money schema contains billing and payment information for billable actions throughout the system. For note, the action.circulation and booking.reservation tables inherit the billable_xact table contained within it.
17. offline: Evergreen contains a built-in offline mode. The offline schema handles information about processing of the offline circulations.
18. permission: Permission covers all of the permissions and permission groups in the system. Note that user profile groups are actually permission groups.
19. query: The query schema houses data for the Query Store (qstore) service.
20. reporter: Evergreen's reports interface stores its data here, and some helpful views are kept here.
21. search: The search schema's major function is to hold the query_parser_fts function.
22. serial: Information on serials (like magazines) is stored in the serial schema. Note that serial.unit is inherited from asset.copy.
23. staging: The staging schema is used to stage potential new users, complete with addresses, cards, and statistical category entries.
24. stats: The stats schema is created alongside the config schema, but is currently unused.
25. unapi: Information and functions pertaining to unapi output is stored here.
26. vandelay: The vandelay bib import/export/overlay system stores its data here.
Fieldmapper IDL (IDL)
In addition to PostgreSQL, IDL is one of the ways Evergreen is told how to interact with the database.
The IDL is comprised of a set of class nodes, each of which contains a list of fields at a minimum. In addition to a list of fields they may also contain links, permissions, and in the case of fully virtual classes a block of SQL that defines the data to be retrieved.
Clients and services (except stored procedures) cannot talk to database elements unless they are defined within Fieldmapper IDL.
The fm_IDL.xml file is parsed for the information on various tables, views, and other information in the database.
TPac development comes in two flavors: Perl “backend” code in the OpenILS::WWW modules for processing and data retrieval . Template Toolkit template code in the Templates directory for formatting and display.
The Evergreen Staff Client is currently a XULRunner application built on the XULRunner 3 series, which is equivalent to the Firefox 3 series. One goal is to eventually move to a later version of XULRunner, another is to create a new staff client built on other technologies.
In addition to the core OpenSRF and Evergreen code there are other projects commonly used with Evergreen that may require work for development projects. The most common is currently SIPServer, which provides a SIP2 interface for Evergreen that can be used with Self Check units, Automated Materials Handlers, PC Reservation systems, and some third party services for authentication.
SIPServer is maintained as a separate project, is written in Perl, and interacts with Evergreen through the OpenILS::SIP Perl package.
|Evergreen Backgrounder for Developers_rev1.pdf||33.85 KB|