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.

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.

PostgreSQL

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. 

OPAC

The OPAC is the primary interface for locating materials in the system and placing holds on those materials for staff and patrons alike. There are two OPAC interfaces in Evergreen right now. The classic JavaScript based AJAX OPAC, somewhat commonly referred to at this point as the JSPac, is the older and more commonly used OPAC.  The newer Perl template Toolkit based OPAC (aka TPac or TTOpac) replaced JSPac as of version 2.2.

JSPac is built on the JavaScript OpenSRF interfaces and builds almost everything outside of the base page layouts client side. Search results and account information are populated after the initial page load as the system makes backend calls with the AJAX technologies the browser supports. Development is thus more oriented towards JavaScript programming and XHTML pages than anything else. This includes use of the Dojo Toolkit, though for a number of reasons Evergreen is currently limited to the somewhat outdated Dojo version 1.3. This may change soon, however, as a Google Summer of Coder was working on updating Dojo.

TPac is the location new features should ideally be implemented, and one of the goals is to use as little, if any, JavaScript as possible.  All pages are processed server-side with the Template Toolkit Perl Module. This provides a distinct split between the processing and display layers that is not present in the JSPac.

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.

Staff Client

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.

The staff client is a combination of local and remote XUL pages, JavaScript, and the OPAC itself. It is compatible with both the JSPac and the TPac, and also loads a number of interfaces that work like the JSPac and/or TPac. Some of these interfaces can be easily used outside of the staff client itself, others expect to be loaded from within it.

Development for the Staff Client can thus involve XUL, JavaScript, (X)HTML, and OPAC development. Perhaps all at the same time, depending on your goals. 

SIPServer

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.