The Support Center has moved!! See the new website https://support.goalexandria.com/  


You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 23 Next »

How helpful was this page? 

Tell us what we can improve.


Save as PDF

SIF Management


Last Updated: $action.dateFormatter.formatDateTime($content.getLastModificationDate())

Connection

Any changes made to settings in the Connection tab will not take place until Alexandria has been restarted. 

Settings
  • Enable SIF Communications. This will enable/disable Alexandria's SIF Agent services. Without the SIF Agent enabled, there won't be any communication with the ZIS system resources (e.g. the agent port, etc); therefore, Enable SIF Communications needs to be checked in order to use SIF.

Communication Method

Pull Mode will request data from the ZIS throughout the day.
Push Mode will wait for messages to be sent from the ZIS.

  • Use Pull Mode. If this box is checked, Alexandria will use Pull Mode when retrieving messages from the ZIS. An agent registered in Pull Mode receives data from the ZIS when it requests the data.
  • Use Push Mode. If this box is checked, Alexandria will use Push Mode when retrieving messages from the ZIS. An agent registered in Push Mode receives data from the ZIS when the ZIS receives the data (i.e. it is sent to Alexandria's SIF Agent just as soon as the ZIS can send it).


Connection Information
  • Agent Name. This is the case sensitive name that the Alexandria SIF Agent is known by to all other SIF agents and to the ZIS (Zone Integration Server). For those with multiple sites in the same SIF Zone[1], the Agent Name should be unique for each library; otherwise, there is no need to change it from the default: AlexandriaSIFAgent.
  • Push Mode Port. This is the TCP/IP port that Alexandria uses to communicate with the ZIS and to initiate messages in Push Mode. If using Push Mode, this portmust be open to outside connections through firewalls or software used to block unsolicited connections. Under Macintosh OSX, the default port requires that the user has administrative privileges on the computer (usually requires logging in as root). Setting this field is only required if Use Push Mode is selected.
  • ZIS Address. This is the internet address where the ZIS is located. This can be either an IP or resolvable address and can include a SIF Zone/Subzone. COMPanion recommends that a SIF Subzone be used for filtering incoming messages. If a subzone is specified and messages for Alexandria SIF Agents are only being sent to that subzone, then filtering messages is vastly simplified. The protocol header should be left out. Refer to your ZIS installation notes for this address. This address may include a subzone that only this installation uses. If that is the case, then it may not be necessary to use “other methods” to limit the Student and Staff events that are accepted by this agent. These “other methods” include settings that ignore messages from other schools or requiring a SchoolRefId; both of these are configured in the Message Handling tab.


Encryption
  • Enable Encryption. SIF can run in two modes: with (HTTPS) encryption or without (HTTP) encryption. However, since it can't run in both modes at the same time, use this check box to decide if you will enable/disable encryption. Unless necessary, running SIF without encryption is not recommended. However, whatever the ZIS is doing, Alexandria should be doing as well. If you are using encryption with Push Mode, then public and private certificates must be specified. The location of the public and private certificates can be configured in Alexandria's Web Administration settings; COMPanion does not supply this certification.
  • Disable TLS Encryption. If checked, a less secure mode of encryption will be used. However unlikely, it is possible for there to be communication errors with TLS v1 encryption protocol. Unless you experience these types of errors, you should always keep TLS encryption enabled (obviously this selection is ignored if the Enable Encryption setting is disabled).
  • Disable SSLv3 Encryption . If checked, the SSL communication method used does not accept SSL version 2.x or 3.x protocols; it will only accept TLS v1.


Registered Version
  • Registered Version. Select the version (1.5r1, 2.0r1, or 2.3) of SIF that you would like to use to register SIF; this is the version used to originate messages. This selection will also dynamically change the default values in the fields of the Message Mapping tab.


Accepted Versions

Select the version(s) for which your Alexandria SIF Agent will respond; in other words, the message versions that Alexandria can receive. Alexandria can tell the ZIS that you support version 2.0r1, but only accept messages from version 1.5r1. Alexandria supports versions 1.5r1 and 2.x.

  • Version 1.5r1. If selected, your Alexandria SIF Agent will accept and respond to messages from version 1.5r1.
  • Version 2.x. If selected, your Alexandria SIF Agent will accept and respond to messages from version 2.x.


SSL Certificates
  • The location of the public and private certificates can be found in Alexandria's Web Administration settings.

Actions Menu
  • Restart the SIF Agent. Each SIF Agent sends a SIF_Register message to become part of the SIF Zone. The ZIS then sends an acknowledgement (i.e. SIF_Ack) message to confirm the registration. This selection forces the registration message to be sent to the ZIS.

  • SIF Ping the ZIS. Sends a request to the ZIS and awaits an answer to make sure that it is on-line and available. A message window will appear when there is a response from the ZIS. An agent can “ping” the ZIS to check that it's online and “awake” by sending a SIF_Ping message to the ZIS. If the agent receives a successful acknowledgement, the ZIS is awake; however, the ZIS may also reply that it is asleep.

  • TCP/IP Ping the ZIS.  Sends a request to the ZIS via TCP/IP and awaits an answer to make sure that it is on-line and available. A message window will appear if there is a response from the ZIS.


Message Handling

Patron information cannot be imported into Alexandria until the Chosen Sites list has been populated. The SchoolRefId is used to ensure that only patrons from the Chosen Sites are imported into Alexandria via the SIF agent.  

Settings
  • Include Students. If this box is checked, students will be imported from schools in the Chosen Sites list. You must be requesting StudentSchoolEnrollment and StudentPersonal objects from the ZIS.
  • Request Students With an Entry Date Through. When a valid date is specified, the SIF agent will include StudentSchoolEnrollment messages with the TimeFrame attribute of Future and the EntryDate element less than (or equal to) the date specified. Without a date, only StudentSchoolEnrollment objects with the Timeframe of Current will be requested from the ZIS.
  • Include Staff. If this box is checked, staff for the entire school year will be requested from schools in the Chosen Sites list; the school year is determined using information found in the Advance Grade After field of the Grade Table preferences. Agents set to use SIF version 1.5r1 and greater may use the StaffAssignment object to request staff for schools in the Chosen Sites list. 


Policy Defaults
  • Default Student Policy. Select the policy that new patrons are assigned when added via SIF. This affects how StudentPersonal events and requests are handled.
  • Default Staff Policy. Select the policy that new operators are assigned when added via SIF. This affects how StaffPersonal events and requests are handled. 

Chosen Sites

The schools contained in the Chosen Sites list are selected using the Site List. During synchronization, only the schools selected for the Chosen Sites list will be processed. The Chosen Sites list is also used to filter events and requests that occur during normal operation.

  • Site List. This opens the Add Site List roll-down containing a list of all the schools available to Alexandria after requesting SchoolInfo objects from the ZIS. Clicking the Refresh (“”) button re-sends the request to refresh the Site List. However, due to the nature of SIF, this may take a few minutes (or a few days). If you don't manually refresh the Site List, an automatic attempt is made once each day. The Add Site List roll-down shows the last time that the Site List was updated (i.e. the last time a SchoolInfo message was received from the ZIS to fulfill a refresh request). It may take an indeterminate amount of time depending on the number of messages in the queue and the asynchronous nature of SIF communications. To add a site to the Chosen Sites list of schools to be processed by Alexandria, select (highlight) the one you desire and click Add. 
  • Sync Selected Sites. This starts the synchronization process for schools in the Chosen Sites list. This process can take an indeterminate amount of time. When the Sync Selected Sites roll-down appears, clicking Continue will send the synchronization request to the SIF Agent; clicking Cancel will close the Sync Selected Sites roll-down and will not send a synchronize request—keep in mind that this does not cancel any requests that have already been sent. 

Actions Menu
  • Remove Selected Site. This option removes a user-selected (highlighted) site from the Chosen Sites list.
  • Remove All Sites. This option removes all sites from the Chosen Sites list of schools that are handled by Alexandria. 

Message Viewer

When the SIF Agent is started, the database is checked to see if there are any messages that need to be handled. Any incoming or outgoing messages are added to the message queue; additionally, any outgoing messages not yet sent are added to the outgoing message queue. After incoming messages are handled, they are removed from the queue; after outgoing messages are received by the ZIS, they are either removed from the queue or, in some circumstances, saved in the SIF database.

Some messages are saved until a particular date is reached (such as future StudentSchoolEnrollment events); SIF_Request messages are saved until a response is received from the ZIS. Most messages, however, are never saved.

Messages are removed if they are invalid due to missing required elements. Obsolete StudentSchoolEnrollement messages are removed; these would be messages from any version of SIF not equal to v1.5r1 (since Alexandria no longer supports SIF v1.1). SIF version 2.x (or higher) re-broadcast messages with Future timeframes, so these are not saved. All other messages are removed if they are older than 30 days—except for the StudentSchoolEnrollment messages. When future StudentSchoolEnrollment messages have reached their specified entry date, they are added to the incoming message queue. 


The Message Viewer tab contains a list of all the incoming and outgoing SIF_Request and SIF_Response messages currently “in-process” (i.e. incomplete or unresponsive) in the message queue. Additionally, the message queue contains messages that are being cached for future processing.

By default, the list will contain the fifty most recent SIF_Requests and SIF_Responses, sorted by date (that the message was placed in the queue), and whether the message is incoming or outgoing.

You are allowed to select (highlight) a message to view its contents, including the <SIF_MsgId> (i.e. message IDs) taken from the header sent by the ZIS. 


SIF Message Types
  • SIF_Register. A SIF Agent must register with the ZIS to participate in a Zone. To do so, it sends a SIF_Register message. An agent may re-register at any time by sending another SIF_Register message. The ZIS updates the agent's registered settings accordingly.
  • SIF_Ack (Push Mode). Push Mode agents end Selective Message Blocking (SMB) by sending a final SIF_Ack to the ZIS.
  • SIF_Ack (Pull Mode). Pull Mode agents acknowledge messages received in response to SIF_GetMessage and remove them from their queue by sending a SIF_Ack message to the ZIS. SIF_Ack is also sent by Pull Mode agents to invoke and end Selective Message Blocking (SMB).
  • SIF_Event. When an application adds, changes or deletes data represented in one or more zones, its agent should publish the corresponding Add, Change, or Delete SIF_Event to the Zone. Upon successful delivery of a SIF_Event to the ZIS, the ZIS places the event in the queue for any agents subscribed to events for the object, including the Alexandira SIF Agent if it's a subscriber.
  • SIF_Request. An agent can request data from another agent at any time by sending a SIF_Request message.
  • SIF_Response. A ZIS places a SIF_Response in your agent's queue when a responder sends a response packet to your agent per a SIF_Request previously sent by your agent. It is delivered when it is the next message available for delivery to your agent.


Message Viewer Settings
  • Refresh. Clicking this button will cause the message queue to be refreshed; the processing of incoming and outgoing messages can change the configuration of the queue rather quickly.
  • Search. Clicking this button will call forth a roll-down that allows you to locate specific messages in the SIF Message queue; you can search by Message ID, Date (range) Added to Database, and Message Type (e.g. SIF_Request and SIF_Response). 

Actions Menu

Message saved in the database are most frequently SIF_Requests of some type that are awaiting responses.

  • Remove Selected Messages. This option removes selected (highlighted) messages from the SIF Message queue.
  • Remove All Messages. This option removes incoming and/or outgoing SIF_Request messages of all types.
  • Remove All Requests with Packets Received. This option will remove partially received SIF_Request messages (i.e. messages that have received some response, albeit incomplete).
  • Remove All Requests with No Packets Received. This option will remove all the SIF_Request messages that have had no response whatsoever.
  • Remove All Cached Messages. Some SIF_Requests are cached and saved in the database, assigned to be processed at a future date; this happens when StudentSchoolEnrollment objects are assigned a TimeFrame value of Future. Therefore, this option will remove all of the cached StudentSchoolEnrollment messages saved in the database; only valid for SIF v1.5r1 implementations.
  • Show SIF Activity Log. If available, returns the most recent (up to 1MB) SIF activity log information.
  • Clear All Patron RefIds. This option clears all StudentPersonal and StaffPersonal RefIds; object types will also be cleared as well as the dates that patron records were last updated via SIF. All incoming and outgoing messages in the queue will be deleted and the SIF Agent will be restarted. Under normal circumstances, this option should never be used; however, there are times it's necessary to perform before synchronization at the beginning of the school year.
  • Clear All Patron SIF Dates. This option clears the date that patron records were last changed or updated via SIF. During and after synchronization, you can run the Patron SIF Updates synchronization report to see how many patrons have been imported since the date was last cleared.
  • Show SIF Agent Status. Selecting this option calls forth a roll-down presenting all the most recent SIF Agent status messages received from the ZIS. This roll-down includes the time of the last ping and will refresh itself every second; it is also automatically opened when SIF Ping the ZIS is selected from the Actions menu in the SIF Connection tab.


Message Mapping


These settings allow you to specify the location (i.e. XML locations in SIF Messages) of every field that is supported by Alexandria's SIF Agent. Most of the Message Mapping fields have a default value that can be modified to customize the import to your exact specifications; the default values in these fields change dynamically if your Registered Version of SIF is adjusted in the Connection tab.

When the Restore From Defaults button appears to the right of a field, it signifies that information in a particular message mapping field has deviated from our default values; clicking this button will restore the field to its default value. If you delete everything in a specific field, it will remain blank and not import data for that field; for example, if Grade Level is intentionally left blank, then patron Grades will not be imported. However, blanked fields can be restored to their default values by clicking the Restore From Defaults button.


Required & Optional Objects

The following objects must be provided by a SIF Agent and Zone Administrator; Alexandria must be authorized by your zone settings to request and receive them.

Required Objects
  • SchoolInfo 
  • StaffAssignment
  • StudentSchoolEnrollment 
  • StudentPersonal 
  • StaffPersonal

Optional Objects

If optional objects are added or removed, then the SIF Agent is automatically restarted so that the changes may take effect. The following optional objects are only requested and subscribed to if used in any of the following fields:

  • StudentContact. If used in the Parent/Guardian, Email, Telephone, Mobile, or Address Parent mapping fields of the Student subtab.
  • StudentPicture. If used in the Homeroom Link mapping field of the Student subtab.
  • RoomInfo. If used in the Picture mapping field of the Student subtab.

SIF_ExtendedElements

Alexandria supports the mapping of extended elements; these elements are supported at the end of all SIF objects to extend existing SIF objects with locally-defined elements. Extended elements should not be used to duplicate data that can be obtained from other, standard SIF objects. Here's an example of how an extended element can be used for mapping Email addresses:

    StudentPersonal::SIF_ExtendedElements/SIF_ExtendedElement@Name=Parent_Guardian_Email

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. 


Student & Staff Mapping

The Message Mapping tab is divided into five subtabs: Student (1), Student (2), Staff (1), Staff (2), and Other. While you may be tempted to believe that the numbers in parentheses refer to the SIF version number (e.g. 1.x or 2.x), this is not the case—there are just too many Student/Staff-supported fields to store in each subtab. The object mapping fields in these subtabs allow the certified SIF-specialist or IT technician who configures the/your SIF Zone to specify where in the SIF Message XML to look for the information you want imported into Alexandria.

In Alexandria, operators are considered patrons. However, aside from differing Security Group and Policy settings, there is no real distinction between a patron (what SIF could consider Student) and an operator (what SIF could consider Staff). Regardless if a person is a Patron or a District Administrator, all of their personal information being imported from the StudentPersonal or StaffPersonal objects is saved into the same—indistinguishable and identical—patron record. This is why the Staff subtabs allow you to provide mapping for fields such as Homeroom and Grade Level, etc.

Also, you may be curious as to why the Student/Staff subtabs don't include “Name” as one of their configurable message mapping fields. This is because a patron name is a mandatory, required element in the StudentPersonal and StaffPersonal objects and will always be retrieved automatically from their standard location in those objects. Therefore, message mapping is not required for Name.


For details about what to enter in each of these fields, refer to SIF Message Mapping Fields.


Non-Standard Mapping Using OtherID

The OtherID element often occurs in StudentPersonal and StaffPersonal objects and is an 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. Currently, OtherIds can be used to support pre-v6.22.2 message mappings, but this usage has been deprecated, specifically for Barcode, Homeroom, and Grade Level; since a standard now exists, we don't recommend using OtherId in those fields.

There are currently several ways to retrieve StudentPesonal or StaffPersonal elements from providing SIF Agent messages using the OtherId element.

  • Using barcode as an example, if an OtherID of type ZB (OtherId@Type=ZB) is specified in the StudentPersonal or StaffPersonal object(s), the value stored in that location (e.g. 1001) is seen as the patron barcode. However, you would more commonly retrieve information from a standard element such as LocalId or ElectronicId.
  • In v1.5r1 specifications, since both Homeroom and Grade Level could be specified from an OtherId of type ZZ, you were required to include an identifying prefix after the @Type indicator (e.g. HOMEROOM or GRADELEVEL). For example:
        StudentPersonal::OtherID or OtherIdList@Type=ZZ:HOMEROOM 
        StudentPersonal::OtherID or OtherIdList@Type=ZZ:GRADELEVEL