***APOLOGIES FOR CROSS POSTING ****
We are running Moodle as our institutional VLE and we have been using a custom built SRS integration with Moodle for the past 7 years. It’s time for an overhaul of the system and I was wondering if I can gather any experience from this forum.
Enrolment plugin: This plugin ensures that any new units in the SRS is created in Moodle overnight using the nightly cron. Using the same cron we also bring in students and teachers to the units and programmes by a way of mapping the course ID to the unit code. This then creates a ‘SRS enrolment’ type which can only be removed by a cron sync.
Block plugin: This plugin allows teachers to add / remove additional mappings (units or programmes) to an individual Moodle course and also perform an adhoc sync for the courses they are enrolled on. Since we don’t have the concept of parent and child courses in our SRS structure ( as of yet) we give the teachers the ability to add extra units to a course, hence making them ‘manually mapped’ which they can also choose to persist in the system beyond their end date .
All of this is done via an Oracle Connector (OCI8) running raw SQL queries.
Although we do not wish to reduce the functionality of the plugin in any way in our first iteration of Minimum Viable Product we do plan to add extra bells and whistles to the block plugin. This would also come with many other additional features such as better logging and debugging for developers etc.
We are also planning to move away from approaching of running SQL queries directly on the SRS to a more manageable REST API approach with the possibility of AMQP to listen to newly added events and react to that in Moodle.
We also plan to use Agile Business Methodologies (DSDM) for the purpose of this project.
Following are our main reasons for the overhaul:
1. Plugin is outdated: Since the plugin was built for Moodle 1.9 and later re-vamped for 2+ Moodle API has since changed quite significantly and we would like to use the latest technology and methods for our plugins.
2. Revisit old functionality to see if some features can be made redundant in order to (but not necessarily) make way for new features.
3. Move away from SQL to REST API for better sustainability.
It would be much appreciated to hear any similar experiences from other members on this list or just their view on whether this is the right approach.
[log in to unmask]
University of Bath
***************** List information: *****************
Remember - replies go by default to the entire list.
Access the list via the web on http://www.jiscmail.ac.uk/lists/vle.html
To unsubscribe, email [log in to unmask] with the message: leave vle