OneRoster 1.2 Integration for LMS

Our client is a global provider of cloud-based learning management systems (LMS) for millions of students and teachers worldwide. The company also provides educational institutions with a range of technical services, from one-off training sessions through to full-scale system implementations.

The client asked us to develop a solution for passing grade information from the LMS to a student information system (SIS). The SIS is a part of the client’s ecosystem and by the time the task started, it already had a public API based on OneRoster® 1.2 standard that allowed for importing information, including results.

About OneRoster

The OneRoster® (OR) specification, developed by 1EdTech (former IMS Global Learning Consortium), supports securely sharing class rosters and related data between a student information system (SIS) and any other system, typically a content application or learning information system (LMS). The OneRoster standard supports spreadsheet-style (CSV) export-import as well as direct system exchanges using REST APIs. OneRoster defines two roles: a Provider, and a Consumer. Technical administrators or other users export from the Provider system, such as an SIS, and import to a consumer system, such as an LMS. The Consumer might return the results to the Provider. As of August 1, 2023, OneRoster 1.2 is the latest version of the standard.

As we became familiar with the standard and the SIS public API, we realized that the initial goal could be achieved by supporting two standard services of OneRoster Gradebook Service—LineItemsManagement and ResultsManagement. According to the standard, a learning resource must first be ‘registered’ with the SIS by creating a line item and only then the results for that resource must be communicated. The LMS then acts as a Consumer, i.e., calls the Provider’s REST API to manage line items and pass back the grade information.

In addition, we found that the LMS has a high chance of acting as a OneRoster Provider in the future, and ideally, we wanted to make the solution at least partially reusable for this purpose as well.

We investigated existing libraries, but none of them fully met the requirements. For instance, the existing client library OneRoster.NET did not implement the grade management at all. Therefore, we decided to develop our own solution.

First, we created a separate library that included OneRoster-compliant models and could be used for Consumer-to-Provider interactions. The library contained the minimum required for the two above-mentioned endpoints but could be easily extended in future if more endpoints needed to be supported. Those models, without modification, can be used for the OneRoster Provider API later.

Secondly, we created a client library that allowed the Consumer to call the Provider API. The client performed all underlying communication according to OneRoster standard, including authorization using OAuth. Using this client in the application, we could now create/update/delete line items for learning resources and post/update student grades in the resource referenced by external person identifiers within LMS.

The last step was to incorporate the client in the main web application. Given that some learning courses may have thousands of students and a teacher may want to pass the grades for all of them at once, all interaction was handled by a background service in order not to spoil the user experience if the operation took a long time. Since the integration could potentially fail for a multitude of reasons, we ensured maximum fault tolerance at all stages and meaningful messages to users.

The solution was designed and successfully implemented within 3 months. It allowed teachers to post student grades from the learning management system to the student information system using the OneRoster 1.2 standard.