Integrations
General
What integration types are supported by Alma?
Alma supports a wide range of integration types. Following are a few examples. For more detailed information see here.
- 3rd Party Discovery system
- Publishing
- Fulfillment services
- Services page
- Bursar
- Fine/fee Export
- Digital (Remote)
- Finance
- Invoice Export
- Invoice Import
- Order (PO) Export
- Synchronize Fund Information
How are files transferred to third party systems?
SFTP (ssh port 22) or FTP (port 21) connections are supported for file-based integration profiles:
- ISO ILL
- NCIP
- Broker Resource Sharing
- Remote Storage
- OAI
- Self Check
- SMS
- SRU
- Student Information System
- Import and synchronize users
- Export user blocks
- Export users
- LDAP
- SAML
How does Alma integrate with third party systems?
Alma provides exceptional integration with a range of third-party applications and key enterprise systems used on campuses today, including for services such as financial and ordering systems, self-check, interlibrary loan, proxy services, collection agency services and ERP systems, and discovery.
Achieving Alma’s seamless handshaking with external systems, integration points are based on both evolving and well-established trend market standards. In addition to standards, Alma’s integration approach makes use of plugin -capabilities, allowing institution-specific adaptations to specific systems and needs. The framework for utilizing integration points with third-party systems is the Integration Profile. The Integration Profile is where integration definitions may be set up for many types of Alma-supported integrations, including systems such as:
- Self-check
- Resource sharing systems
- Link resolution and proxies
- Collection agency services
- Discovery interfaces
- Cataloging clients
- Learning management systems
- Financial management systems
- Student Information systems
A unified and centralized platform, the Integration Profiles provide a single interface for defining the different required attributes for a variety of integrated systems.
The diagram below shows the variety of integration interfaces of Alma with multiple third-party systems using its open platform.
Does Alma support APIs for integration with 3rd party systems?
Alma supports a wide array of RESTFul APIs as well as other integration points. APIs cover many different functional areas in Alma such as Bibliographic records, Physical Resources, Electronic Resources, Digital Resources, User Records and related fulfilment transactions, Configuration, Resource sharing requests and more. Details can be seen on the Developer Network site at https://developers.exlibrisgroup.com/alma/apis
Alma supports the ability to integrate with a wide variety of systems, using both the above RESTFul APIs as well as other open interfaces (e.g. z39.50, SIP2, NCIP, ISO-ILL, etc…) as well as file based data exchange. Alma can integrate with your institution’s financial systems, user management systems, Self Check machines, RFID software and more. For more details please see https://developers.exlibrisgroup.com/alma/integrations
How does Alma integrate with OAI-PMH?
Alma implements the following OAI roles:
- Data Provider - OAI-PMH is supported by Alma for exposing metadata via the ‘General publishing’ module
- Service Provider - Alma uses OAI-PMH as a basis for importing metadata
For more details see https://developers.exlibrisgroup.com/alma/integrations/oai
How does Alma inter-operate with external systems?
Alma supports the exchange of data using interfaces like EDI, OAI-PMH, SIP2, NCIP, import and export metadata in MARC-XML format as well as extensive Restful APIs.
Alma integrates with external systems, such as vendor systems, Enterprise Resource Planning (ERP) systems, metadata management systems, and remote storage systems, via standard protocols, such as S/FTP.
Main data exchange options:
Metadata Import
You import bibliographic or authority metadata into the Alma repository using import profiles. Profile definitions include source format, mapping definitions, and normalization routines to be executed during the import process.
Metadata Export
Alma allows you to export repository metadata to external systems. The files containing exported metadata (bibliographic records for example) are made available to the external systems in the following ways:
- placed at an FTP location
- sent via email to a requester
- downloadable from a dedicated Alma page
Publishing
Ex Libris maintains an increasingly versatile, generic publishing model to be used for integrating Alma with third party systems. This model provides:
- The ability to incrementally publish data through files or OAI PMH.
- Library (b)
- Location (c)
- Call number (h)
- Optional enrichment of inventory related data. Specifically, the enrichment adds a holdings representation field (852), including the following subfields:
- The ability to perform normalization (reformatting) of the published data.
- In addition to this, a deletion indication appears in the leader position 5, so that when a record is deleted from Alma or removed from the set, the third party system receives this indication.
Alma lets you configure publishing profiles for RSS feeds, Primo, Primo Central, Google Scholar, OCLC, COPAC, SUNCAT, Libraries Australia, and PubMed.
EDI
The following acquisition activities can support EDI enabled vendors:
- Purchase orders – When purchase orders (POs) are ready to be sent to an EDI enabled vendor, they can automatically be exported to a specified FTP location where they are fetched via a vendor system number.
- Invoices and Order Responses – When invoices or order responses are placed at an FTP location by an EDI enabled vendor, Alma automatically loads and parses them. Order Responses can be used to support a shelf?ready process. An Order Response contains the status of orders: a list of PO lines and the item?related data to update in Alma (typically bar codes and receiving information). After receiving the Order Response, Alma updates the relevant PO lines.
EOD
EOD files that contain bibliographic titles, inventory (electronic or physical), or purchase order information from a vendor can be loaded into Alma from a local network or an FTP location.
Finance
The Alma acquisitions process includes ordering and receiving materials from vendors, which involves the handling of both orders and invoices by vendors.
Invoices are handled outside of the library’s scope, usually by the institution’s Enterprise Resource Planning (ERP) system. Invoices can therefore be exported from Alma to the institution’s financial system.
Institutions that want to receive confirmation about the invoice status in the Enterprise Resource Planning (ERP) system, can import the invoices from the ERP back into Alma.
Some institutions may want to keep track of sent orders in their finance system, in addition to tracking this information in Alma. Such institutions can export POs from Alma.
In addition, it is possible to update fund amounts in Alma in order to synchronize the financial system and Alma’s fund information.
In general, the export and import processes between Alma and the financial system are performed using XML files that are placed at a predefined FTP location. These XML files can be fetched by the financial system (in the case of invoice or PO export) or by Alma (in the case of invoice import). Note that the fund allocation loader process is different because the format is an Excel or CSV file.
Selfcheck
Most libraries today offer users self-service check-in and check-out ability, utilizing self-service systems from vendors such as 3M, Bibliotheca, Envisionware, and Checkpoint. Almost all of the self-service systems in the market today utilize the Standard Interchange Protocol (SIP) as the standard interface for communications between the library management system and the self-service machines.
Alma supports communication over the SIP2 protocol, which is used primarily for communication with local self-service machines. The communication is bi-directional. Since the vast majority of the SIP-based systems were built and designed without the cloud in mind, the SIP2 protocol lacks several components in order to fully support a cloud-based SaaS – namely, a unique institution ID and secure communication channel (which is supported in SIP3). Once SIP3 becomes the de-facto standard with cloud capabilities, Ex Libris will support it as well.
As the messages sent during SIP2 communication contain patron personal information, the traffic must be secured to comply with privacy requirements. SIP2 generally communicates over a TCP connection. To secure SIP2 communication, Alma uses an open source TLS encryption wrapper called Stunnel, which is a lightweight component installed locally on standard operating systems. This component creates a secure "tunnel" communication over port 6443 with Alma and also serves as a means to uniquely identify each institution.
SMS
Using SMS messages as the notification channel is now quite popular, as this has become an efficient and effective way in which to contact users. In general, the transmission of SMS notifications is based on an external SMS service provider, which handles the actual SMS message delivery. Alma’s role is to identify the need to text the patron and produce a message with the required information in the format defined by the institution. Alma places the required information at a configured FTP location for the service provider to collect and subsequently deliver to the patron.
Users
External users are users that are stored and managed outside the library’s scope, usually in another system maintained by the institution (for example, in a Student Information System). These users’ information is loaded into Alma and synchronized on a regular basis. It is possible to update an external user’s information manually in Alma, but these updates are overridden by the next synchronization with the user information system (Only the following fields are not replaced if they were updated manually or if they are empty in the incoming user record: User group, Job title, PIN number, User language, Campus, Resource Sharing library).
Authentication of external users is performed outside of Alma—for example, in LDAP.
Student Information System (SIS) is the system in which the institution’s users are saved, managed and maintained. These users might be the students, as well as the institution staff.
Alma, as the library management system, needs to know the users information, in order to give them library services. Therefore, the users should exist in Alma: they are copied from the SIS into Alma, and synchronized on a regular basis.
The relation between Alma and the SIS is in a “Parent-Child” module: the SIS is the “Parent” system, which is responsible for the users’ information. They are managed and maintained in the SIS. Alma is the “child” – in which the user information is replicated. The users’ information in Alma might be edited, but it will be overridden with the SIS information during synchronization. Users that are managed by the SIS are considered as “external” in Alma.
The integration between Alma and SIS is configured in an Integration profile of type “Users” in Alma. If your institution has several SIS systems, a separate profile should be defined for each of them.
There are few usages in which Alma and SIS can be integrated:
The common usage is
- import and synchronize External users from SIS into Alma
2 additional usages are available, but are not commonly in use:
- Export user blocks
- Export user
For more information please see our Developers Network site for full information and examples about the different integration options available with Alma -https://developers.exlibrisgroup.com/alma/integrations
Integration with Discovery Systems
How do Alma and Primo integrate?
Primo simultaneously provides both centralized as well as personalized access to all resources in the institution’s repository.
Patrons can locate physical, electronic, and digital resources in all locations of the repository and also view availability information for physical resources as well as access options for electronic and digital resources.
Alma data is published to Primo on a regular basis, typically multiple times a day, for example every six hours. This is done by a publishing profile called “Publish bibliographic records to Primo”.
After the data is published Primo harvests and indexes it.
Electronic and digital resources are available not only from the institution’s repository but also directly from Primo's local database or the Primo Central Index (PCI).
While new, updated and deleted bibliographic records do need to be published to be reflected in primo, the inventory is automatically updated in real time via the RTA Real Time availability APIs.
For example when an item is loaned or returned, it will be immediately updated in primo when the user checks availability.
Primo primarily serves the following functions:
- Provides the Front End interface for patrons to:
- Search and request services for library resources managed in Alm
- Search for and request services for remote records (such as Primo Central records) via Alma’s link resolver.
- Perform My Library Card functions via the My Account tab.
- Provides the User Interface for Alma Link Resolver services for searches which are not initiated via Primo (for example searches made via a native interface such as EBSCO, Google Scholar, and PubMed). After performing a search in one of these native interfaces a dedicated Primo page (called the Services Page) is provided. The services pages offers both Primo and Alma services.
Student Information Systems
How does Alma integrated with student information systems?
Alma, as the library management system, needs to know the users information, in order to give them library services. Therefore, the users should exist in Alma: they are copied from the SIS into Alma, and synchronized on a regular basis.
The relation between Alma and the SIS is in a “Parent-Child” module: the SIS is the “Parent” system, which is responsible for the users’ information. They are managed and maintained in the SIS. Alma is the “child” – in which the user information is replicated. The users’ information in Alma might be edited, but it will be overridden with the SIS information during synchronization. Users that are managed by the SIS are considered as “external” in Alma.
The integration between Alma and SIS is configured in an Integration profile of type “Users” in Alma. If your institution has several SIS systems, a separate profile should be defined for each of them.
There are few usages in which Alma and SIS can be integrated:
The common usage is
- import and synchronize External users from SIS into Alma
2 additional usages are available, but are not commonly in use:
- Export user blocks
- Export user
For more information please see our Developers Network site for full information and examples about the different integration options available with Alma -https://developers.exlibrisgroup.com/alma/integrations
Can Alma integrate with PeopleSoft?
Integration between Alma and PeopleSoft is live and in use at several Alma institutions. The integration between Alma and a Student Information System (SIS) is configured in an integration profile of type “Users”. If your institution has several SIS systems, a separate profile should be defined for each of them.
There are few usages in which Alma and SIS can be integrated:
The common usage is import and synchronize external users from SIS into Alma.
2 additional usages are available, but are not commonly in use:
-
Export user blocks
-
Export user
For more information please see our Developers Network site for full information and examples about the different integration options available with Alma -https://developers.exlibrisgroup.com...a/integrations
As stated above, the loading of external users from the Student Information System can be performed in one of two modes
-
Import and
-
Synchronize.
The synchronize modes is an ongoing load, used to update external users and add new ones. The IT department and the library must determine the identifier that Alma and PeopleSoft have in common in order to provide a matching point when synchronizing external users in Alma with the incoming data from PeopleSoft. This may be the primary identifier or any other identifier, unique cross-institution or cross-type. For each external user in the input file, the synchronization job attempts to find a match according to the defined match identifier. All the existing external users are checked, regardless of the SIS to which they initially belonged. (Internal users are not considered for matching purposes.)
If no match is found, the synchronization job adds the user as a new external user or rejects the user, according to criteria selected in the external system profile. The addition of a new external user is similar to the addition of a new user via the import mode.
If a match is found (that is, the external user already exists in Alma), all the external information of the user is replaced as follows:
-
Core information – All the fields are replaced by those in the input file. Only the following fields are not replaced if they were updated manually (or if they are empty in the incoming user record): User group, Job title, PIN number, User language.
-
Related segments (identifiers, addresses, phone numbers, email addresses, notes, blocks, and statistics) – The existing external segments are deleted and the segments from the input file are added. Internal segments (that were added manually) are not deleted.
It might happen that a patron comes to the circulation desk, and the circulation staff finds that no such user exists in Alma. This can happen, for example, for a new student, whose information was not yet loaded from the student information system. In such a case, the circulation staff can perform a “fast registration” of the user: the user will be created manually as an external user. The information will be updated by the next synchronization.
Can data be imported from a bursar system?
You can import files from a bursar system to update Alma on the transactions that were exported from Alma to the bursar system.T
The bursar integration profile includes an import section. When this section is active, the export process sets the transaction type to Exported instead of Exported and Paid, which is set when the import section is not active. The section includes the job schedule for the import process and an option to run the import immediately:
Finance Systems
How does Alma integrate with campus or other external financial systems?
Alma may integrate with the institution’s financial system for payment for the following functions:
- Export Payment Requests - report to the ERP System on future purchases from the order state
- Import Payment Confirmations
- Export Orders
- Synchronize fund adjustments – this is the “reconciliation” process with the ERP system – load the fund allocations as they were created in ERP System
In general, the export and import processes between Alma and the financial system are performed using XML files that are placed at a predefined FTP location. These XML files can be fetched by the financial system (in the case of invoice or PO export) or by Alma (in the case of invoice import). Note that the fund allocation loader process is different because the format is an Excel or CSV file.This is illustrated in the following diagram:
After an invoice has been approved, it reaches the payment stage, in which the invoice awaits payment processing either through Alma or through the institution’s Enterprise Resource Planning system.
Alma’s default configuration assumes that the institution will export invoices to its ERP system. In order to support this workflow, it is necessary to configure a Finance Integration profile, as demonstrated in the screenshot below:
Note that if you do not want to export invoices to an ERP, you can configure Alma to skip the export stage and update the invoice status accordingly.
All the above invoices follow the same workflow:
-
In Review – initial step in the workflow
-
In Approval – if Approval rules exist in the institution
-
Ready to be paid – this is the state where all the invoices wait for the Export job to send them to ERP System
-
Sent to ERP (Waiting for payment) – after the invoice is sent to the ERP system it is waiting for payment confirmation
-
Closed – Invoice is paid and closed
Exceptions
-
Invoices may not follow ALL the above stations in the workflow. This is dependent on the invoice itself and the institutional configuration:
-
Some institutions do not use ERP integration
-
A specific invoice may not be sent to an ERP
-
Some institutions may not handle payment in the libraries
-
Invoices that have been closed or sent to the ERP can be sent back to the Review stage, to enable for editing the invoice after it was rejected by the ERP. Invoices rejected by the ERP are sent to the review stage automatically.
Does Alma support integration with online payment systems?
Integration with the e-payment systems, such as the WPM Education, allows Alma users to pay fines and fees via My Account in Primo. Once the request is initiated in Primo and processed in the payment system and Alma, both Alma and the e-payment system send payment receipt emails to the user.
The WPM Education E-Payment System has been integrated with Alma at Kingston University, Salford University and Sheffield University. The WPM Education E-Payment System must first be configured in Alma to enable online payments as no credit card information is stored in Alma. In addition, some configuration may be necessary in Primo.
In addition, the Alma APIs allow institutions the freedom to integrate with any payment system from a University portal application or even from Primo.
The general flow for integrating with any payment system is the same, and can be summarized as follows:
- A patron requests to view his fees on a student portal
- The portal queries Alma and displays a list of fees and the balance. The patron requests to pay his fees via PayPal
- The portal creates a transaction in PayPal for the relevant amount, then redirects the patron's browser to PayPal for approval
- The patron logs into PayPal and approves the payment and payment method. PayPal redirects the browser back to the portal application
- The portal executes the payment in PayPal using the specified transaction code
- Once confirmation is received from PayPal, the portal posts the payment to Alma to be reflected in the patron's account
- The portal displays a confirmation message and a zero balance
We do not support Electronic Payments through Alma.
Can Alma export invoice information to an external finance system?
Alma’s default configuration assumes that the institution will export invoices to its ERP system. In order to support this workflow, it is necessary to configure a Finance Integration profile, as demonstrated in the screenshot below:
Discovery Systems
Can Alma integrate with discovery systems other than Primo and Summon?
Ex Libris provides institutions with the flexibility to deploy third party discovery systems. Alma integrates with open source discovery systems using several protocols and methodologies. At the core of the integration is Alma publishing process that enables integration between Alma and third-party systems, based on the bibliographic information stored in Alma
The integration interfaces of Alma to be used for integrating with third party discovery are described below and at this link.
This section summarizes the integration points:
1. Search and retrieve information about library resources: In order to enable this functionality, all types of Alma data (such as physical, electronic, and digital data) must be published and loaded into the discovery tool’s DB.
2. Retrieve real time availability information on library resources: Discovery system can query Alma for the real time availability of print materials, using the Retrieve BIB API. This API is based on the MMS ID (BIB ID in Alma), which is retrieved as part of the publishing process in 001 field.
Note that the API should be invoked asynchronously via AJAX in order to give good performance in the results page in the discovery system.
3. Perform fulfillment services on library resources: Alma offers the ability to “get” printed material or “view” electronic and digital materials.
4. Perform My Library Card functions via the My Account tab: Discovery system can offer patron details, using the Users API. This API is based on the user ID, and supports patron info, list and renew loans, list and cancel requests and list of fines.
5. Provides the UI for Alma Link Resolver services for searches that are not initiated via the discovery system (such as EBSCO, Google Scholar). The result of these searches is a dedicated page (called the Services Page)
There are more than 130 APIs documented on our Knowledge Center for all sorts of library operations including Fulfillment, Resource Management, Courses, Resource Sharing, Users and more (https://developers.exlibrisgroup.com/alma/apis).
Self Service
How does Alma integrate with self-service machines?
Learn about Self-Check machines in the Integration with Self-Service Systems video: https://www.youtube.com/watch?v=Z-q-mCc33Bo&hd=1
Alma focuses on creating clean interfaces that support staff work, as well as building out the self-service checkout via SIP2.
RFID enabled machines can send SIP2 messages to inform that a check-out/check-in action has taken place at the machine. Alma will reply with SIP2 messages that include bin information for the return machine to be able to determine where the item needs to be reshelved.
Patrons can access their account information from self-service kiosks using the SIP2 protocol. Alma has been integrated with the self-service systems from vendors such as 3M, Bibliotheca, Envisionware, and Checkpoint. Alma supports intelligent self-service devices using the SIP2 protocol. This includes support for issues, returns, and renewals from RFID self-check machines.
Alma allows for the definition of any number of Self-Check Integration Profiles. The staff user is guided through a short wizard to define the parameters relevant for the Self Check unit.
How does Alma support the SIP2 protocol?
With standards-based integrations being one of its main design goals, Alma integrates with other fulfillment systems using a number of widely used standard protocols such as SIP2.0 and the NISO Z39.83 Circulation Interchange Protocol (NCIP).
SIP2.0
SIP2.0 is supported for managing self-check actions such as:
-
Self check-out
-
Self check-in
-
Self payment of fines/fees
All of the SIP2.0 messages that are required for supporting these actions are currently supported in Alma, including:
-
11,12 – Check -Out
-
09,10 – Check- In
-
37,38 – Fee Paid
-
93,94 – Login
-
23,24 – Patron Status Request
-
63,64 – Patron Information
A Self- Check Integration Profile is used to define which of the above listed actions is to be supported by the institution’s different self-check machines. The Self-Check Integration Profile is also linked to an Alma Circulation Desk, inheriting attributes from the attached desk such as which physical locations are served by the self-check machine.
For more details, see: https://developers.exlibrisgroup.com/alma/integrations/selfcheck/sip2
Can self-service kiosks be configured to accept payments?
SIP2.0 is supported for managing self-check actions such as:
-
Self check-out
-
Self check-in
-
Self payment of fines/fees
How are SIP2 communications secured?
As the messages sent during SIP2 communication contain patron personal information, the traffic must be secured to comply with privacy requirements. SIP2 generally communicates over a TCP connection. To secure SIP2 communication, Alma uses an open source TLS encryption wrapper called Stunnel, which is a lightweight component installed locally on standard operating systems. This component creates a secure "tunnel" communication over port 6443 with Alma and also serves as a means to uniquely identify each institution.
The communication flow is as follows:
-
The SIP2 local machines communicate with Stunnel software that is installed on the local Windows/Linux workstation.
-
The Stunnel encryption component encrypts the communication using a standard encryption method and a security certificate and sends the SIP2 requests to the Alma cloud over the secure port 6443.
The following diagram describes this architecture:
For more details please see https://developers.exlibrisgroup.com/alma/integrations/selfcheck
Can the library configure self-service messages?
A configuration table, Self-Check Messages enables you to edit messages for check-in, check-out, and renew on self-check machines:
RFID
Does Alma support RFID?
Alma supports integration with RFID systems that utilize the SIP2 standard or Alma Web APIs. A number of Alma clients in production are using RFID-enabled self-check machines that interact with Alma using the SIP2 protocol.
In addition, RFID support whereby Alma interacts directly with the RFID device is currently under development, and is included in the April 2016 release
-
Updating the RFID tags’ security bit at checkin\checkout
-
Updating the RFID tags’ barcode and other item information
-
Reading barcodes from the RFID tags
At present time, the integration described above is being developed with RFID devices from Bibliotheca. In addition Alma's development plans include developing the above integration with 3M’s RFID devices as well.
Can Alma write to RFID tags directly?
Integration with RFID machines is yet another integration that Alma does based on standard protocols such as SIP2. Being a cloud application, integrating Alma with RFID enabled machines can be best done based on a server-to-server type of integration, such as is provided by many RFID vendors. This type of integration is described below:
The RFID enabled machines may interact with Alma using this protocol, to:
-
Get feedback on loan/return actions that took place at the desk, signaling the RFID enabled machine that an update of the security bit is required.
-
Self Check – RFID enabled machines communicate can send SIP2 messages to inform that a check-out/check-in action has taken place at the machine. Alma will reply with SIP2 messages that include bin information for the return machine to be able to determine where the item needs to be reshelved.
-
Update of RFID tags – updating barcodes on the items via Alma’s item forms.
Does Alma support NEDAP RFID integration?
Alma supports an RFID integration profile for Nedap.
Can multiple RFID profiles be defined?
Multiple RFID integration profiles are supported. You can have more one RFID integration profile per system type (Bibliotecha, 3M, Seret, and Nedap).
Is RFID based self-service supported?
RFID based self-service is implemented with various vendors. To name some examples:
- 3M
- 2CQR
- Agresso
- Bibliotheca
- D-Tech
- EnvisionWare
Alma supports desentising/resensitising functionalities via 09/11 SIP2 messages. The institution therefore has to set the item record field ‘Is magnetic’ to ‘Yes’.
With what RFID readers and actions is Alma compatible?
|
Supported browsers
|
Firefox, Chrome
|
|
Supported vendors
|
3M™ RFID Staff Workstation (Model 896)
|
|
Supported actions
|
Read barcode from item on pad
Update security tag on loan and return Update item information (for single piece item and multi pieces item) |
|
Communication protocol
|
HTTP
|
How does Alma integrate with RFID Readers?
Alma communicates with RFID devices that are installed locally on a staff workstation. In order to allow communication between Alma and the locally running RFID software, a proxy should be installed on the workstation. The following diagram illustrates the communication:
How is the RFID connection maintained ?
If a RFID integration profile is defined, then Alma displays a connection icon on the menu bar.
The connection is maintained per user and desk/department. When switching to a new desk, you will need to activate the connection again by clicking the connection icon.
A “Read RFID” button will be displayed in the following places:
-
Patron Services Workbench
-
Return Workbench
-
Scan In interface (both tabs)
-
Repository Search
-
Persistent search bar
-
Physical item editor
-
Quick Cataloging
-
Receive
Email Servers and SMS
How does Alma integrate with the email server?
For full details see the Online Help - Configuring Alma Letters
Secured communication between Alma and institutional email servers –
Alma’s email servers in all regions now use secure SMTP over TLS (Transport Layer Security) by default to deliver mail securely (if the institutional email server supports TLS). Secure SMTP over TLS includes two key features:
1. Encrypted messages – TLS uses Public Key Infrastructure (PKI) to encrypt messages from mail server to mail server.
2. Authentication – TLS supports the use of digital certificates to authenticate the receiving servers. This process verifies that the receivers (or senders) are legitimate, which helps prevent spoofing.
Can notices be sent to patrons by SMS?
The transmission of SMS notifications is based on an external SMS service provider, which handles the actual SMS message delivery. Alma’s role is to identify the need to text the patron and produce a message with the required information in the format defined by the institution.
Alma places the required information at a configured FTP location for the service provider to collect and subsequently deliver to the patron. This is illustrated in the following diagram:
An example of an SMS profile:
Integration with remote storage
How does Alma integrate with a remote storage facility?
Many libraries use a remote storage facility for keeping material which is not used often, or should be kept in a special environment. The items which are kept in the remote storage facility are considered as part of the library collection, and as such can be requested by patrons. Communication between Alma and the remote storage facility system is required in order to allow both systems to have the accurate information about items, their location and status. The integration between the 2 systems can be done in the following ways:
-
NCIP based integration with remote storage facility:
Alma supports using NCIP messages in order to communicate with a remote storage facility system.
-
XML based integration with remote storage facility:
When a request is placed in Alma on an item that belongs to a remote storage location, an automatic job exports the requested information to a defined FTP location. The remote storage facility system will retrieve the file and process it, and the requested item will be taken from the remote storage location and sent to the relevant pickup location in the library.
The item will arrive at the library and scan-in there, in order to proceed with the request workflow in Alma.
The files placed at the FTP location adhere to the rules defined in the Export Requests to a Remote Storage Facility schema.
Automated Storage Retrieval Systems (ASRS)
Does Alma support integration with Automated Storage Retrieval Systems (ASRS)?
Alma has already achieved integration with the Dematic Automated Storage Retrieval System (ASRS), which has been implemented at, among several other institutions, Macquarie University in Sydney, Australia. Read the case study here.
The request workflow for this type of remote storage is:
-
A patron requests an item in the ASRS, - as for any other item – either in Alma, or in Primo.
-
A specific item is automatically selected by Alma to fulfill the title request. The item is defined as ‘Requested’ and is considered to be no longer available.
-
Alma automatically requests the item from the Dematic ASRS system by sending an online protocol based request to the system
-
The Dematic ASRS system automatically moves a robotic arm that fetches the bin in which the requested item is stored.
-
The Operator collects the item from the retrieved bin and scans it into Alma’s ‘Scan In’ interface, triggering a standard hold shelf notification
-
In most instances, the item will be waiting for the patron at the designated circulation desk within the time it takes the patron to walk to the desk
-
The item is loaned to patron using standard Alma fulfillment procedures
-
The item is returned by the patron using standard Alma fulfillment procedures
-
The item is reshelved at the Dematic system
Updates between Alma and the Dematic ASRS occur on an ongoing basis.
How does Ex Libris support the Dematic interface?
Ex Libris has worked closely with Dematic to develop integrated workflows between Alma and the ASRS system. Ex Libris designs the integration with the Dematic ASRS, configures it during the project, and supports the integration on an ongoing basis.
For more details see here on the Developers Network.
What Alma sites have integrated with Dematic?
Alma works today in production at a number of institutions in the United States, Ireland, Australia, Japan and Taiwan. All sites are using the same Alma software, although they might have migrated from different ILS systems and might have different Dematic interfaces. The exact details of the Alma Dematic interface and the upgrade process (if required) may be provided by Dematic. All upgrade and configuration work that is required for set up the integration from the Dematic side is done by Dematic staff.
Is additional software required to implement Dematic?
The only additional software that was required on the Alma side of the integration is the implementation of the Stunnel application, similar to the setup for using SIP2 self check machines.
Request workflow with Dematic
Authentication
See under: User Management - Authentication
Learning Systems
Can Alma integrate with 3rd party learning systems?
Alma allows for integrating the Alma-supplied reading list citations and their statuses into a Course Management System (CMS), and provides a link that can be used from within the CMS to view the services that the library can supply for a given citation.
To achieve this integration Alma provides a set of RESTful Web services for retrieving course information from Alma:
-
searchCourseInformation – Search for Course Information
-
createCourse – Create a Course
-
updateCourse – Update a Course
-
deleteCourse – Delete a Course
-
createReadingList – Create a Reading List
-
updateReadingList – Update a Reading List
-
deleteReadingList – Delete a Reading List
-
createCitation – Create a Citation
-
updateCitation – Update a Citation
-
deleteCitation – Delete a Citation
Is it possible to search using a SRU interface?
Alma allows you to open your institution to SRU/SRW (search retrieval via URL/Web service, an XML based protocol) searches for the purpose of integration with external systems that want to search the Alma repository. To activate this capability, each institution must define and activate its own SRU Server integration profile and also indicate whether to return availability information in the response to SRU queries.
The following core SRU operations are supported in Alma:
- explain
- searchRetrieve
The search via SRU allows querying the bibliographic record using the same search indexes as the staff search interfaces. It is possible to configure Alma to return availability information as part of the SRU response, which provides details on the inventory related to the bibliographic record. Availability information is stored in the AVA (physical availability), AVE (electronic availability) and AVD (digital availability) fields.
Total views:
13774