The Series25 LYNX Interface is a web-based application that allows your Banner, Campus Solutions, Colleague, Workday, or other Student Information System (SIS) to share and update data with 25Live. LYNX keeps your data synchronized between your local SIS database and your remote Series25 database located on CollegeNET servers.
Basic LYNX Structure
All versions of LYNX operate on the same basic principle: in order to keep 25Live in sync with your SIS, we use an intermediate LYNX step. This means there are three databases involved:
- Your SIS database, the system of record for all academic data
- Your 25Live database, where scheduling and room assignment happens
- Your LYNX database, which is a staging ground between the two of them
All relevant changes in your SIS are tracked and recorded in LYNX. All changes in 25Live are tracked and recorded in LYNX. Nothing is transferred directly from your SIS to 25Live or vice versa.
Types of LYNX Interface
25Live and LYNX behave identically for all Series25 customers, but their connection with the SIS database changes based on the SIS itself.
LYNX for Banner, Campus Solutions, and Colleague
This is a high-level view of LYNX processing for all locally hosted student information systems. A lightweight, locally installed Java application (the LYNX client) acts as a bridge between your SIS database and Series25.
Image: LYNX Processing Cycle diagram
LYNX uses triggers and stored procedures in the SIS database to monitor changes to data pertinent to event scheduling.
Periodically (every minute, as needed) the LYNX client posts the changed data, as well as the nature of the change (add/update/delete), to LYNX WebServices.
LYNX WebServices receives the posted data and loads it into the LYNX database on CollegeNET servers that maintains all data changes in the SIS that are relevant to 25Live.
LYNX imports the subset of course sections in the LYNX database that match the criteria for an active import extract set into 25Live.
Location assignment additions and changes made to imported sections in 25Live are automatically saved to the LYNX database.
- The LYNX client periodically (every minute) polls LYNX WebServices to see if there is updated section data. If there is, it retrieves the sections that meet the criteria for an active export extract set and posts them to the SIS database.
LYNX for Workday
LYNX processing using the Workday version of the Interface is somewhat different than other versions. Because the Workday database is fully in the cloud and not hosted in a local database, LYNX monitors changes via an API rather than database triggers.
Image: LYNX for Workday Processing Cycle diagram with Transaction Log Connector
When course section data is initialized in LYNX, the API Dispatcher makes the appropriate API requests to retrieve data from the Workday tenant and save it to the LYNX database.
LYNX imports the subset of sections in the LYNX database that match the criteria of an active import extract set into 25Live.
Once locations are assigned to the sections in 25Live, the API Dispatcher makes the appropriate API request to export the section data that matches the criteria of an active export extract set back to the Workday tenant.
It is very important that the course section data in the LYNX database is up-to-date before running any import or export processes. There are three options for accomplishing this:
- Manually initialize the data beforehand (see Initializing SIS Data)
- Configure auto-initialization in LYNX for up to three terms (see Initializing SIS Data).
- Set up the Student Transaction Log Outbound Connector in Workday ("Transaction Log Connector" in the diagram above). This connector can be scheduled to run every 15 minutes to track changes to course sections and then process them as described in the steps above. For more information, see Creating the Student Transaction Log Outbound Connector in Workday.
Note: There is no change detection in Workday for reference data (term codes, locations, subject codes, etc.), so any changes to that data must be manually re-initialized.
Most versions of LYNX function via triggers directly in the database (Banner, Campus Solutions, Colleague) or through an API (Workday). If you have another SIS, you must use the Universal version of LYNX. This version requires you to create new tables according to CollegeNET's specifications and keep them updated with SIS data. From there on, the LYNX processing between these tables and 25Live is identical to the standard version depicted above.
Because of this added complexity, implementation of the Universal version requires the assistance of CollegeNET consulting staff. For more information, contact your CollegeNET Account Manager at email@example.com.
Image: LYNX Universal Processing Cycle diagram
LYNX for Colleague (UniData)
If you have a Colleague student information system with a UniData database, CollegeNET provides a specialized version of the LYNX Universal implementation. This is fundamentally the same LYNX Universal architecture described above, but the method to update LYNX history tables is standardized. It involves establishing an MS SQL database to hold these tables and a specific procedure to populate them from your SIS.
Read more about LYNX implementation for Colleague UniData here.
Image: LYNX Processing Cycle diagram for Colleague UniData
Most LYNX implementations follow a standard pattern, with one student information system and one 25Live database as described above. However, some institutions require a more complicated arrangement.
Many to One
LYNX can accommodate multiple SIS databases syncing with a single 25Live instance.
For example, the main campus uses Banner and the Medical School uses Campus Solutions. but they both want to share the same 25Live scheduling environment.
In this scenario each SIS has its own local LYNX application and associated historical tracking tables and triggers. Each one also configures its LYNX settings and processes separately.
Both SIS databases use LYNX to import into the same 25Live instance, where sections are identified behind the scenes as belonging to one or the other. When changes occur in 25Live, the LYNX architecture determines the matching SIS and triggers an export process back to the appropriate database.
One to Many
LYNX can also accommodate one SIS database syncing with multiple 25Live instances.
For example, all colleges in a state system share the same Campus Solutions database, but each has its own independent 25Live scheduling environment.
In this scenario the SIS has a single local LYNX application and one set of historical tracking tables and triggers. However, each 25Live environment configures its LYNX settings and processes separately.
Schedulers at each institution are responsible for designing extract sets that do not overlap, so that they only import the correct sections for their own campus. (For example, using campus codes or institution codes.) A section which is updated in the SIS will be imported into any and all 25Live environments where it meets extract set criteria, and location assignments in any 25Live database will trigger an export to the SIS.