Interaction with the Library Management System

In order to function, IMMS needs to be in close communication with a Library Management System (hereafter referred to as the LMS). The LMS supplies the basic information about items, etc., that the IMMS’ functions are build on top of.

Communication between the two systems can be divided into the following 3 parts:

• Transfer of initial data from the LMS to IMMS at start-up
• Continual exchange of notifications bidirectionally between IMMS and the LMS
• Queries to IMMS from the LMS

These types of communication are described in the following sections.

Initial data

During start-up of IMMS, the LMS generates a dataset referred to as initial data, which IMMS transfers and loads. This provides IMMS with all of the information it needs from the LMS.

The initial data includes the following components:

• Float codes - depending on LMS
• Branches
• Departments
• Locations
• Sub-locations
• Item collections
• Discard codes
• Sorting points
• Chutes
• Titles (this allows IMMS to produce a list of possible item types)
• Items
• Holds (both holds for picking and items already taken or fulfilled)

Note that reservations (holds without any eligible items) can also be transmitted to IMMS.

The initial data is a snapshot from the LMS that brings IMMS up to date with the LMS. In order for the two systems to continue to be synchronized, all relevant changes in one system are transferred to the other system. This occurs bidirectionally between the systems via the exchange of notifications.

Notifications

A notification is a message about an event - typically, that a modification to some data has taken place.
In order for IMMS and LMS to continuously work with the same data basis, any modification to data in the one system is sent to the other system if the data is important to the other system.
For example, the LMS sends a notification to IMMS when an item has been checked out so that IMMS can also register the item as on loan. Likewise, IMMS sends a notification to the LMS when an item fulfills a hold in connection with picking.

It is crucially important that all of these notifications arrive at the recipient, but at the same time, the systems must be able to continue to function independently in the event of a temporary disruption in the connection between the two systems. Therefore, both systems are able to save outgoing notifications in a queue so that they can be sent at a later time once the connection has been reestablished.

The LMS notifies IMMS about the following:

• Modifications (additions/changes/deletions) to data included in the initialization data
• Item checked out
• Item sorted into a chute (typically, when an item is being returned)
• Item discarded
• Discard/item care/ad hoc order created or deleted
• Title ID changed
• Item ID changed

IMMS notifies the LMS about the following:

• Item updated (branch, department, placement text, status, availability)
• Item fulfilling a hold via picking
• Item discarded (as “not found” if applicable)
• Item ready for pickup (set on the holds shelf)

Via an item update notification, the LMS is notified about an item’s specific location in IMMS, e.g. with an indication of the name of the item grouping or name and location of the transport unit the item is in. In addition, the LMS becomes aware of the item’s status (from the transport unit) and whether the item is considered to be available or unavailable.

Available or not

As part of the information about an item's placement in IMMS notifications specify whether the item is available or not. This is determined by the item's placement based on these rules:

• In a transport unit: Availability is determined by the setting on the transport unit's status.
• At a location that is part of an active exhibition: Availability depends on whether the exhibition is open or closed. Open exhibitions are notified as available, closed exhibitions are notified as unavailable.
• At a location that is not part of an active ehibition: Availability depends on the location's usage type and can be controlled by 5 parameters at system or branch level:
  • Items at locations with usage type "<Not directly used>" are notified as available
  • Items at locations with usage type "Item grouping" are notified as available
  • Items at locations with usage type "Chaotic - Holds shelf" are notified as available
  • Items at locations with usage type "Chaotic - Exhibition" are notified as available
  • Items at locations with usage type "Chaotic - Storage" are notified as available
• In an item grouping: Open item groupings are notified as available, closed item groupings are notified as unavailable.

Queries

If one of the systems wants an answer from the other system about something, it can send a query. Only one particular type of query has been defined, specifically an assignment query that is sent from the LMS to IMMS.

When an item has been returned in the LMS and the LMS determines that the item should be shelved, it can query IMMS regarding the branch where the item should be shelved. IMMS then uses its intelligent distribution algorithm to figure out an appropriate branch for the item. This can be a media hotel if needed.

In contrast to the other types of communication, queries are always made directly and may never be put into a queue.