How LYNX Processes Data

The Series25 LYNX Interface is a web-based application that allows your Banner, Campus Solutions, Colleague, Workday,  Ethos, 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 Series25 database, where scheduling and location/resource 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.

LYNX determines what should be updated in 25Live or your SIS on the basis of extract sets that you configure. When something meets the criteria for an extract set, it can be imported or exported.

Types of LYNX Interface

25Live and LYNX generally behave identically for all Series25 customers, but their connection with the SIS database changes based on the SIS itself. Integrations can be divided into two categories, database integrations and API integrations.

LYNX versions that fall under a database integration include Banner (Oracle), Campus Solutions (Oracle), Colleague (SQL Server), Universal (SQL Server), and Universal (Oracle).

For a database integration, the LYNX-APP on customer servers runs from 6 am to 9 pm in your local timezone (unless your institution has customized this). 

LYNX versions that fall under an API integration include Workday, Ethos Banner, and Ethos Colleague.

For an API integration, the API Dispatcher on CollegeNET servers runs from 3 am to 8 pm Pacific time. This cannot be customized.


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-APP) acts as a bridge between your SIS database and Series25.
LYNX Processing Cycle diagramImage: LYNX Processing Cycle diagram for database integration 

  1. LYNX uses triggers and stored procedures in the SIS database to monitor changes to data pertinent to event scheduling. (Monitoring occurs every day from 6 am to 9 pm, in your local time zone.)

  2. 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. 
  3. LYNX WebServices receives the posted data and loads it into the LYNX database on CollegeNET servers that maintain all data changes in the SIS that are relevant to 25Live.

  4. LYNX imports the subset of course sections in the LYNX database that match the criteria for an active import extract set into 25Live. 

  5. Location assignment additions and changes made to imported sections in 25Live are automatically saved to the LYNX database.

  6. 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 and Ethos

LYNX processing using the Workday or Ethos versions of the Interface is somewhat different than other versions. Because API-based databases are fully in the cloud and not hosted in a local database, LYNX monitors changes via an API rather than database triggers.

LYNX for Workday or Ethos Processing CycleImage: 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.

  1. LYNX imports the subset of sections in the LYNX database that match the criteria of an active import extract set into 25Live.

  2. Once locations are assigned to the sections in 25Live, the API Dispatcher makes the appropriate API request to export the section data that match the criteria of an active export extract set back to the Workday tenant.

Image: Ethos processing differs with no Transaction Log Connector.

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:

Note: Manually Re-Initializing

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.

LYNX Universal

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 series25implementation@collegenet.com.

LYNX Processing Cycle diagramImage: 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.

LYNX Processing Cycle diagram for Colleague UniDataImage: LYNX Processing Cycle diagram for Colleague UniData

Multi-Database Architecture

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 that 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 export to the SIS.