← blogs.sussex.ac.uk

Making Moodle a scaleable enterprise solution

An early task after installing Moodle is to integrate as much existing data held within an institution that would be helpful in the virtual learning environment (VLE) context.  Even though Sussex has had an institutional Moodle installation since 2006 there are still many possibilities for further integration.

Pre-existing Sussex systems

Sussex has a history of ORACLE development and the majority of business systems use a central ORACLE database.  In 2003 Sussex engaged in a major project exposing Sussex data through a password protected portal, or managed learning environment (MLE),  called Sussex Direct.  This included personal staff data, programme and course data and student data, including assessments and grades.  This system had been extremely popular with Sussex staff and students.

Nightly sync/enrolment process

In 2005 it was decided to move from a small-scale WebCT installation to an enterprise-wide Moodle installation for the 06/07 academic year.  This is called Study Direct. In 2005 we were awarded a JISC-funded grant to integrate our central administration database (DB) with Moodle.

One of the conditions of the funding was that we followed a standards-based approach to integration, hence we used the IMS Enterprise specification. An enrolment plugin-based on IMS Enterprise had recently been contributed to Moodle by a developer at UCL. It works by passing the data out of the central DB into an XML document of IMS Enterprise specification and reading this file into Moodle. It is a robust process and problems are easily traceable, and we are relatively happy with this solution.

Unfortunately since its introduction into Moodle core it has only been partially maintained and as a result at Sussex we configure and improve it for every Moodle upgrade we do.

All Sussex course modules have a Moodle site

Sussex course data is passed to Moodle and a site is automatically created for that site.  Before 2008 this was at the request of the tutor, however since 2008 a policy decision was made and all courses now have a Moodle site.

The data we pass includes course name, study level, academic year, department, learning objectives and the start date. These become non-editable fields in the Moodle site settings.  We decided early on to that a Moodle site should exist for the duration of a student’s study. For more information about this decision see blogs post on “maintaining sites for the students programme duration”. As a result the identifier passed to Moodle was the course code appended with the term and academic year.

Before 2008 Moodle sites were made available to the students through an interface in the MLE (Sussex Direct). This was so the central DB was updated with the Moodle course site state and links were established from other systems. Now this process is reversed and we make Moodle sites available to students in Moodle and concurrently update the central DB.

We currently do not pass the timetable or assessment data although we may do in future projects.

All Sussex users have a Moodle account

Sussex staff, students and associates who have a computer service account can log in to our Moodle installation through the LDAP authentication service, however this service passes limited user data to Moodle.  We therefore decided to pass all user data through our nightly sync. Data such as their name, username, person code, and email updates the user table.  Within the edit profile screen these fields become non-editable.  However, we have also created a local Sussex roles table into which we pass a person roles and the departments and schools for which they serve this role. For the student role we pass study levels, programmes, programme years and candidate number. The user searches have been customized to use the local Sussex roles table. It is also very useful when extracting data for Moodle use analysis.

A development for the Spring term will be to pass card photos to Moodle.  We will still allow staff and students to add a Moodle picture, but where one does not exist and they have allowed use of their card photo we will pass it. We will run a script every month to look for new Sussex account card photos. For more information see blog post on importing user profiles into Moodle.

We currently do not pass user assessment data back to the central server, but we may do in the future. Furthermore we would like to link closer with user assessment records held on the central server.

Course roles are synced with Moodle course site roles

The nightly sync manages course site roles and enrolments.  We decided not to use IMS-Enrolment standards to manage unenrolment, which specified that an unenrolled user would be of a specified status. It was easier to use a “snapshot unenrol” method which looked at all current members of site and compare that with the incoming membership.

Within the membership possibilities we have added a Colleague role to Moodle. This role permits read only access to a user.  Some departments have selected to give all faculty members a Colleague role on each others’ Moodle sites.

A development for the Spring term is to make it possible to sync a course’s teaching groups with a Moodle site. This will be a manual process.  For more information, see the Teaching groups imported into Moodle blog post.

Data in to Moodle

Post a Comment

Your email is never shared. Required fields are marked *

*
*