Page tree

Contents

Schools Interoperability Framework (SIF)

Tools > SIF

SIF Management is an add-on feature which requires a separate license. If you recently added SIF to your existing user license, re-register your software to enable the module.

One of the biggest challenges facing the K-12 community is the lack of software interoperability (i.e. sharing of database information). In other words, most school districts have a series of software applications which all require the same data, but have no way to talk to each other. Educators and administrators consistently lament the fact that their financial management, administration, library automation, transportation routing, telephone messaging, and cafeteria software applications don't work together (i.e. communicate or share data formats). For example, a school district might need to create a report using data from multiple school software applications and deliver this report over the internet, confident that their information remains secure. Another example would be when a student's home telephone number is changed in the main database management software; using SIF, the new telephone number will be sent to update Alexandria's patron information automatically. SIF solves these sorts of problems by allowing different third party software applications to communicate, dramatically reducing the redundancy of data entry so that administrators can maximize staff and faculty time and are able to better focus on education.

The Schools Interoperability Framework (SIF) is not a product and is not sold as such, rather, it's an industry-supported technical protocol that ensures that diverse primary and secondary (K-12) instructional and administrative software applications share information (data formats) and work together seamlessly, saving tremendous amounts of time and productivity. When different third party software applications can communicate with each other, access one another's database, resources, and tools, a school district can more effectively serve the needs of its users. 


Converting from Previous Versions

Alexandria's SIF capabilities have been substantially enhanced; if you used SIF Management in a previous version of Alexandira (v6.22.1 or older) and have recently updated to the latest version, we will automatically attempt to carry over and reestablish the following mapping locations:

  • Student/Staff Barcode 
  • Student/Staff Homeroom 
  • Student Grade 
  • Student/Staff Site ID Code

You should verify that our attempt to reinstate these mapping fields was performed correctly and, if not, change them to follow the recommended SIF standards whenever possible.


SIF is not compatible with Clever.

If you choose to add Clever integration, Alexandria will disable SIF and clear all patron-related SIF identifiers. If you have been using SIF and plan to use Clever, please contact Customer Support for assistance.

Link

How Does It Work?

Tools > SIF

A critical component of SIF is the Zone Integration Server (ZIS) which serves as the data integration broker (or hub) between disparate software applications that support the SIF protocol. The ZIS is an invisible courier that reliably delivers information from one source to several destinations. The ZIS does not do this blindly, it is aware of the data formats that are of interest to these differing applications, aware of what they're privileged to send and receive, and aware of the security requirements for each and every application, delivering secure and reliable message broker services. 

Third party vendors can connect their applications to one another via the ZIS by writing ‘SIF Agents’. These “agents” perform the task of brokering communications between existing applications and the ZIS; they are the boundary where translation between the application's internal data format and SIF format occurs. SIF is not limited to a particular operating system or platform. 


Agents and Objects

A SIF Agent must register with a ZIS in order to use SIF. When an agent is registered, it provides a name (which must be unique for that ZIS) and agrees to both subscribe to and to provide objects. If an agent subscribes to a type of object and an object of that type arrives on the ZIS, it is placed into a queue to be sent to the agent. Likewise, if an agent provides a type of object, it can send that object to the ZIS and the ZIS will place it in queues for other agents that have subscribed to that object.

The Alexandria SIF Agent can register with the ZIS to “provide” certain types of information; for instance, Alexandria can provide LibraryPatronStatus (fines, overdues, etc.).

The Alexandria SIF Agent can “request” certain objects if needed; for example, Alexandria can request all of the objects that it subscribes to in addition to the SchoolInfo object.

The ZIS keeps track of the objects that need to be sent out to agents. Any time that the ZIS sends data to an agent, it waits for the agent to acknowledge that it has received and handled the data. If the agent never acknowledges, then the data will be sent again the next time the agent requests data—this ensures that data will always be delivered to agents. Objects are queued up for agents so that if the agent is shut down, it will receive the data the next time it is started and requests data.

If an agent registers to provide an object, then it must keep a queue of any objects that it needs to send to the ZIS, and not remove the object from queue until the ZIS acknowledges that it has received the object. This mechanism ensures that data is propagated between agents without regard to whether any particular agent happens to be running at any time. For example, Alexandria might be shut down at night and any objects received by the ZIS during that time would be sent to Alexandria when it is restarted in the morning.

Communication with the ZIS is done with http and https. If the agent uses https with Push Mode, then private and public certificates must be specified in Alexandria's Web Administration settings.

Also, it is important to note that the transmission of information may not happen in real-time; data might not be sent from the originating program or received by the receiving program immediately. 


Adding New Patrons and Updating Existing Patrons via SIF

When patron information is received from SIF Add event messages or during routine synchronization, Alexandria looks for certain information in the objects being specified in order to add new patrons or update existing patrons in your database without relying soley on Alexandria's internal patron barcode number.

Every object defined by SIF requires certain information. For example, any object being used to add a patron must include their full name; luckily, because the StudentPersonal and StaffPersonal objects both require the inclusion of a patron name, it is always available to check against during synchronization. Additionally, identifiers such as Community ID and Government ID are used for matchmaking if they are found anywhere in an object.

During an Add event, if an existing patron is found in your database, the event is then treated as a Change event. The following steps are performed (in order) when attempting to match an incoming SIF student with an existing Alexandria patron:

  1. Alexandria first looks for a matching RefId. If a patron is found in your database with a matching RefId, then the existing patron is updated.
  2. Regardless if a matching RefId was found, Alexandria will next look to see if a barcode is included in the SIF object; if one is found (and coincides with a potentially matching RefId), the existing patron is updated. However, if both a patron RefId and a barcode are defined in an incoming SIF message and the patron in your database only matches one of these unique identifiers and not the other, then the patron import is ignored and an error is recorded to the Transaction log.
  3. If no RefId was found, your database will then be examined for a potential Government ID match followed by Community ID. Unlike RefId and barcode, government and community identifiers do not have to be unique in order to make a match.
  4. If no government or community identifiers could be located, Alexandria next looks to piece together a patron's full name from the LastName, FirstName and (optional) MiddleName SIF locations. Your Alexandria database is then examined until the first matching patron name lacking a SIF RefId is found. Like government and community IDs, patron names do not need to be unique in order to make a match. 


Deleting Patrons via SIF

Alexandria does handle Delete events that are received during normal SIF operations. Obsolete patrons (e.g. those who have exited your site or district) can not be removed from your Alexandria database if:

  • They can't be found in your database.
  • They are a System Patron (barcodes 1-50).
  • They have any items checked out; if so, then their Satus is changed to Other and a notation is made to their General Notes.
  • They have a fine balance; if so, then their Satus is changed to Other and a message is added to their General Notes.
  • They are a patron responsible for a route. 


Link

Glossary

Tools > SIF

SIF Terminology

SIF Agent

An agent is an extension of an program that must register with the ZIS to either send or receive data objects via SIF; an agent serves as an intermediary between the software (e.g. Alexandria) and the SIF Zone. Agents communicate with the ZIS and never directly with each other. Alexandria is an agent; the main SIS database program for a school district could also be an agent. The ZIS keeps track of all the SIF Agents registered in the SIF Zone and allows them to provide data and respond to requests. The agent tells the ZIS about how it will receive data (Push or Pull Mode) and it specifies which objects it will subscribe to and/or provide. An agent can register with the ZIS to “subscribe” to certain types of information. By default, Alexandria subscribes to the StudentPersonal, StaffPersonal, SchoolInfo, StudentSchoolEnrollment, and StaffAssignment objects.

SIF (Schools/System Interoperability Framework)

An established set of rules and definitions that allow different software applications to share data within a SIF Zone.

SIS (School Information System)

A software application used by school districts to store and manage student (i.e. patron) and staff (i.e. operator) data.

SIF Specifications

The SIF Implementation Specification defines architecture requirements and SIF communication protocols, making it possible for diverse applications to interact and share data, now and in the future. 

SIF Zone

There are four pieces to a SIF Zone: the software program used within a school or district (in this case, Alexandria), data objects (defined by SIF specifications), the intermediary SIF Agent, and the ZIS. It's within this SIF Zone that software applications can communicate with one another via Agents (e.g. the Alexandira SIF Agent). Zones are managed by ZIS software; a single ZIS can manage multiple zones.

ZIS (Zone Integration Server)

A ZIS is an invisible courier that manages requests for information from SIF Agents and then delivers information to the right place—from one source to several destinations. The ZIS controls all access, routing, and security within the system. For example, when the Status of one of your patrons changes, the Alexandria SIF Agent broadcasting the change doesn't need to know anything about the other software applications in the SIF Zone, how they work, or how they're configured. The message is simply sent to the ZIS, which takes care of delivering messages to all the software applications subscribing to your agent.


Data Structure

Object

A SIF object is a batch of information whose contents are defined by the standards set in the SIF Specifications. Data Objects are shared by software applications through SIF messages and written using standard XML notation.

Element

A SIF element (or attribute) represents an encoded value.

Type

Code that defines the type of element; a subset of valid values may be specified in data objects.

Attribute

A SIF attribute (or element) represents an encoded value. 


Elements

OtherId

The OtherId special element often occurs in StudentPersonal and StaffPersonal objects and is an “other” identifier for elements that either don't exist or haven't yet been included in the SIF specification. Once new elements are created to replace those using OtherId, you should always update to the new SIF-standard.

LocalId

This is a common element used to define the locally assigned identifier associated with an entity. It is used in StudentPersonal, StaffPersonal, SchoolInfo, and other objects.

RefId

An object or element identifier; a reference to a StudentPersonal or StaffPersonal object. 

Link