May 28, 2021

LISS is a protocol allowing two different applications to directly exchange data using a standard format. (No CSV files involved)

LISS supports two different modes, “PUSH” and “PULL”. This results in the protocol having four different flavours:

1. Pushing data to some other application
2. Receiving data that has been pushed from some other application
3. Pull data from some other application
4. Pass data to some other application that has requested it

SOBS supports a number of different options depending on the data. These will be listed later.

Configuring LISS

Click on your school name (bottom left) and then on “School configuration”. This will display the configuration menu (pictured).

 

To configure your first LISS connection begin by determining how the data will be transferred. Will you be pushing data to SOBS, pushing data from SOBS, pulling data from SOBS or pulling data to SOBS?

Select the appropriate option from the first pull down. These four options relate to those four different flavours.

The second pull down will define the direction of the data and the type of data that is being processed. These are predefined by the LISS standard.  SOBS supports a number of relevant entries (but not everything).

Some of these are valid for SOBS, and some of them are not. For example, in your school you would typically go to a single source for a list of staff. This is most likely an Active Directory or similar user authentication system, however it would need to support the LISS standard.  So to update the SOBS list of staff you would use a “liss.getTeachers” call from SOBS to the authentication system. The authentication system would typically support this call and return the list of staff data to SOBS. On the other hand, I would not expect SOBS to support being called with the “liss.getTeachers” request, nor would I expect it to issue “liss.publishTeachers”. However, SOBS may respond to the authentication system issung a “liss.publishTeachers” to SOBS, ie the authentication system is sending SOBS a list of staff.

SOBS currently supports the following:

• liss.getTeachers : eg Retrieving a list of staff from another application (this action is initiated within SOBS)
• liss.publishTeachers : eg TimeTabler sending a list of staff (this action is initiated in Timetabler)
• liss.publishRooms : eg Edval sending a list of bookable rooms (this action is initiated in Edval)
• liss.publishTimetable : eg Edval sending timetable data (this action isinitiated in Edval)

In the instance we are pushing data (or publishing data) to another application you can add the URL for the other application here (screen shot below). Otherwise you can enter a description of the other application that will be using this LISS connection.  For example “Room data from Edval” or “Timetable data from Edval”

Currently SOBS is only supporting JSON connections. XML is a legacy option. All new LISS implementations will be using JSON.

When we configure a LISS connection we are essentially allowing another computer somewhere to send data into our application. In order to maintain security we will require the other application to pass through a username and password specified on our connection. If the username or password are not valid then the request will be rejected.  Note, this username and password should not be in the User table, they shouldn’t be valid for logging into the SOBS application.  The values should only be recorded here on this LISS record, and in the other application’s matching LISS entry.

Lastly the “Process immediately” option instructs SOBS to process the incoming request, for example a “liss.publishTimetable” initiated from within Edval will send timetable data to SOBS, and when “Process immediately” is checked we will immediately process that timetable data.  If the “Process immediately” is not checked, then the incoming timetable data will be saved to a local file for later processing.  Later when a SOBS administrator logs in and visits the LISS page, there will be a button saying “Process now” (see below).

 

The other option is to save the data that was provided and process it interactively at a later time. In the following screen shot you can see there is some data that has been received and stored and is awaiting processing.

 

The enable option is a quick method of enabling/disabling a LISS entry.  Only enabled LISS entries will be able to accept incoming requests.  

When processing teacher records into SOBS, if a matching User record is found we will update the details in SOBS.  However, if no matching record is found then we will create a new record.  By default the Username for this new record will be the TeacherCode from the LISS entry.  If the Username should be created using a different entry from the LISS data, then you can specify this here.  Note, this option will only appear when it is valid for selection.

 

The SOBS target URL

When another application is sending data to SOBS a target URL is required (similarly when SOBS is sending data to another application).  SOBS has a single generic URL that will be used for all of your LISS exchanges, the only additional parameter is your SOBS schoolid value.   You will find the URL on the LISS page just under the heading.

A simple example

As an example let’s assume you were wanting to transfer timetable data from Edval to SOBS.

Configure the LISS connection as follows:

When creating this LISS connection I entered the following detail:

This username and password are then entered into the LISS connection details on the Edval end. When Edval sends the data it will include this username and password. When the data arrives at SOBS we will confirm the username and password are correct.

Edval will also require the SOBS target URL. The URL is displayed under the heading on the LISS page.  It consists of:

https://sobs.com.au/liss/lissjson.php?schoolid=X

Replace “X” with your SOBS schoolid.

Now you should be able to press a button within Edval to electronically send your timetable data directly into SOBS.