LMS Integration Points
Introduction
NTER is designed to make it easy to integrate new Learning Management Systems. This document describes the various connection points and how and where they are used within NTER.
Details
We have a few points of contact between LMS's and other NTER systems: A single sign-on server, a course catalog, and a student records feed.
Single Sign on
Single sign on (SSO) is implemented with SAML/Shibboleth. This connection is the LMS, acting as a "SP" or Service Provider, and the login server (http://login.nterlearning.org), which acts as an "IdP" or Identity Provider.
Some LMS's may already have Shibboleth integration ready to go. For example, Ilias and Moodle ship with a PHP script that consumes the SAML headers and synchronizes users at login time. Apache rewrite rules are typically used to protect web resources (those details are not documented here).
Course Catalog
The Course Catalog is what NTER front-end systems use to populate their course listings. The portals periodically enumerate the available feeds listed in the ServiceRegistry and process the course catalog feeds that they discover there.
The feed is an extension of the Atom specification and can be found here: http://www.nterlearning.org/xml/feeds/atom-extensions-schema_0.6.3.xsd. A live feed that can be used as an example can be found here: http://nwtp.nterlearning.org/nwtp/feeds/courses/
Student Progress
This is defined with the same XSD as the Course Catalog. The contents of this feed are used to populate the student's Course History page and show them where they are within a course on the Course Details page. A live feed that can be used as an example can be found here: https://nwtp.nterlearning.org/nwtp/feeds/progress/GetUpdatedProgressFeed.php
More Details on student progress. When the Portal first starts up it connects to the Registry server and grabs any new feed information. It doesn't delete old information for no longer active feeds. So when a portal is first started it has no information. It hits the Registry, populated the CATALOG_tables in the database with information from the registry. It then processes those feeds. This can take a while on the first run. From then on PubSubHubbub takes over the notification process (See below). Further, you can purge any or all feeds in the Administration -> Course Test section of the administration panel. Clicking this will purge, read...delete, ALL course history related to that feed and the feed itself. Upon next restart the Portal will again hit the Registry server and grab information and begin the process again.
About this specific feed (more technical).
In NTERLMS there are two tables of interest. il_lp_xml_cache and il_lp_xml_cache_seq. The latter simply holds the latest auto-incremented id from the former. This number is used as the "ETag" for the PSHB feed. The il_lp_xml_cache holds the xml imformation wiht each row holding a userid, objectid (From object_data) and related information and a type. The feed at the URL above only pulls those of type "crs" which is an amalgamation of all the required elements. If you feel it is somehow corrupt you can add ?feed_type=full to the end of the url. NOTE: This will truncate the il_lp_xml_cache table and rebuild the table. This can take some time. Further, there seems to be some correlation with that process and a CPU spike on Portal when this occurs. We are looking into that. This is probably due to an immense feed read.
Upon loading that URL you will see something similar to the following
nwtp.gov 2014-10-09T13:05:48Z tag:nwtp.nterlearning.org,2010-10-04:/feeds/progress/nwtp/nwtp
That is the topic tag used in PSHB. If you right click and "View Source" you will see the XML. The XML essentially reads in this format...
<entry nter:entryType="course-record">
<title/>
<id>tag:nwtp.nterlearning.org,<course creation date>:/nwtp/nwtp/<crs ref id>/<courseId>/<user ext_account></id>
<updated><course update dat?></updated>
<content/>
<nter:courseRecord
nter:studentUserId="<user ext_account>"
nter:courseId="tag:nwtp.nterlearning.org,<course creation date>:/nwtp/nwtp/<crs ref id>/<courseId>"
nter:progress="In Progress"
nter:assigned="false"
> <__STUDENT SPECIFIC DATA FOR COURSE>
<nter:componentRecord
nter:componentId="tag:nwtp.nterlearning.org,2013-04-09:/nwtp/nwtp/827/5212"
nter:completionPercent="67"
nter:progress="In Progress"
nter:progressDate="2013-04-10T20:27:28Z"
/>
</nter:courseRecord>
</entry>
The user_ext_account is from the usr_data table in usr_data.ext_account. The reference id is form the object_reference table. If you query the object_data table with the ID of the <courseid> in the feed you will see the basic information of that course.</courseid>
For this process to work the config file has to have the correct hub feed URL (pshb.nterlearning.org) configured in ilias.ini.php. The registry server URL also has to be correct (https://registry.nterlearning.org/nter-service-registry-1.1/services/RegistryService?wsdl). These should generally be set up automatically when you run the Hub Installer. If need be the install process also subscribes to the topic in PSHB (See Below).
In the portal under Administration -> Course Feeds you can also process a specific feed if you feel it is lagging. This will hit PSHB and check for updates.
PubSubHubbub
NTER front-ends are PubSubHubbub (https://code.google.com/p/pubsubhubbub/) aware. Typically only the student records feed would support PuSH since near real-time updates are more critical and the volume and rate of change of the data is higher that the course catalog would be. The link rel="hub" tag embedded in the feed directs the consumers where to go for live updates.
LMS systems can optionally pull a list of known PubSubHubbub hubs from the ServiceRegistry. The services definition for the ServiceRegistry can be found here: https://registry.nterlearning.org/registry-service-1.1/services/?wsdl
Related
