rwth-acis / moodle-data-proxy

3 stars 1 forks source link

Moodle Data Proxy Service

The Moodle Data Proxy Service is a las2peer Service which enables the connection between Moodle and MobSOS. Related repositories can be found here: Mentoring Cockpit

Moodle configuration

To get Moodle data to MobSOS first a REST API has to be created on Moodle. This is done by creating a Moodle Web-service under following steps:

Additionally, the tech4comp Moodle API Extension has to be installed and activated. Information about how this is done, can be found in the associated README.

Service setup

To set up the service configure the property file with your Moodle domain, the corresponding Web-service token, and the courses for which activities should be logged.

moodleDomain = http://exampleDomain
moodleToken = exampleToken
courseList = 1,2,3
operatorList = example@mail.com,beautiful@address.com

Note, that if no courseList is provided, activities will be logged for all courses accessible via the provided moodleToken.

Build

The build includes a small test which tries to connect to a Moodle instance and retrieves course updates which requires access to a running Moodle instance. The test is deactivated by default to enable the automatic built, but it is generally recommended to activate it for development by filling in the relevant data in the test class.

Execute the following command on your shell:

./gradlew build

Start

To start the moodle-data-proxy service, follow the Starting-A-las2peer-Network tutorial and bootstrap your service to a mobsos-data-processing service.

Sending Moodle data to MobSOS

The sending of Moodle data to MobSOS is performed by a thread which is executed once every minute to retrieve new activities. The thread has to be started using a POST request after the node was successfully started and connected to the las2peer network. The POST request has to be sent by a registered las2peer user. The email address of the las2peer user has to be registered in the operatorList property or have to be the same email address as the one registered to the provided moodleToken. How to send the POST request as a registered las2peer user is described here. Send the request to the following path using the necessary authorization:

POST <service-address>/moodle/

Setting a Whitelist

One can specify a whitelist of users for whom xAPI statements are to be created and sent to MobSOS. Only xAPI statements referring to users in the whitelist will be sent to MobSOS. The specified whitelist is saved as a CSV file locally that is automatically reloaded if the Data Proxy is restarted. In the file, the users' e-mails should be separated by comma, for example:

user1@example.com,user2@example.com,user3@example.com

The whitelist file can be set by sending a POST request to the Data Proxy service after the node was successfully started and connected to the las2peer network. Send the request to the following path using the necessary authorization:

POST <service-address>/moodle/config/setWhiteList

The POST request's body should be formatted as a multipart form, and the CSV file containing the whitelisted users should be included in a part named "whitelist". One can also disable the whitelist by sending an empty POST request to the following path:

POST <service-address>/moodle/config/disableWhitelist

Assigning Courses to Stores

By default, xAPI statements sent to MobSOS from all courses are redirected to the default LRS store assigned do the admin client ID. If one desires, one could instead choose to assign Moodle courses to specific LRS stores. This assignment is kept in a .properties file, for example:

courseid1=clientid1
courseid2=clientid2,clientid3,clientid4

The key represents the ID of a course, and the value should be a comma-separated list of LRS client IDs that are assigned to the desired stores. The assignment file can be set by sending a POST request to the Data Proxy service after the node was successfully started and connected to the las2peer network. Send the request to the following path using the necessary authorization:

POST <service-address>/moodle/config/setStoreAssignment

The POST request's body should be formatted as a multipart form, and the .properties file containing the course-store assignments should be included in a part named "storeAssignment". One can also disable the assignment by sending an empty POST request to the following path:

POST <service-address>/moodle/config/disableStoreAssignment

How to run using Docker

First build the image:

docker build . -t moodle-data-proxy

Then you can run the image like this:

docker run -e MOODLE_DOMAIN="moodleDomain" -e MOODLE_TOKEN="moodleToken" -e COURSE_LIST="1,2,3" -e OPERATOR_LIST="example@mail.com,beautiful@address.com" -p port:9011 moodle-data-proxy

Replace moodleDomain with the domain of your Moodle instance, moodleToken with the corresponding Web-service token, 1,2,3 with you actual course list, example@mail.com,beautiful@address.com with the email addresses of las2peer users that are allowed to use the REST API and port with a free port in your network.

Node Launcher Variables

Set las2peer node launcher options with these variables. The las2peer port is fixed at 9011.

Variable Default Description
BOOTSTRAP unset Set the --bootstrap option to bootstrap with existing nodes. The container will wait for any bootstrap node to be available before continuing.
SERVICE_PASSPHRASE Passphrase Set the second argument in startService('service@version', '').

Setting up a local development environment with Docker-compose

The development environment consists of three services, the moodle-data-proxy itself, mobsos, and the learning-locker-service. All of can be setup using docker-compose, however you need to specify the web endpoint of a running Moodle instance (.e.g., https://moodle.tech4comp.dbis.rwth-aachen.de/) and a valid token, as well as the domain of a Learning Locker instance (e.g., https://lrs.tech4comp.dbis.rwth-aachen.de/) including respective access credentials. You can read more about the Learning Locker credentials in the README of the learning-locker-service.

After cloning the repository, you can build the image using:

sudo docker build -t moodle-data-proxy:develop ./moodle-data-proxy

Now the image is referencable under moodle-data-proxy:develop through the docker-compose file. Navigate into the moodle-data-proxy directory. First you have to once run:

sudo docker-compose up

to get everything in its initial state. THis will take some time because of the mysql database.

Some of the services will now try to access a database called LAS2PEERMON in mysql that doesn't yet exist. They will exit with error codes, but this is fine. Once you see a reference to this database you can stop the run with Ctrl + C.

Now we will create the database. First, start the mysql container so that we can interact with it:

sudo docker start mysql

Then, to access it:

sudo docker exec -it mysql mysql -p

When prompted for the password enter password. Now the mysql console should start. Create the desired database using:

create database LAS2PEERMON;
exit

This has now set up the database. Now running the command:

sudo docker-compose up

should run the system correctly. If the system seems to be deadlocked in some fashion, consider running:

sudo docker-compose up --force-recreate

List of generated xAPI Statement Verb/Object coverage

Verbs

The following xAPI verbs have been implemented, in regards to what Moodle API responds:

Objects

The following Moodle concepts have been covered, turned into the following xAPI Object types Moodle xAPI Object
Forum Post Activity - Forum Reply
Discussion Activity - Discussion
Exercise Activity - School Assignment
Module Activity - Item