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.