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
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.
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.comNote, that if no courseList is provided, activities will be logged for all courses accessible via the provided moodleToken.
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 buildTo start the moodle-data-proxy service, follow the Starting-A-las2peer-Network tutorial and bootstrap your service to a mobsos-data-processing service.
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/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.comThe 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/setWhiteListThe 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/disableWhitelistBy 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,clientid4The 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/setStoreAssignmentThe 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/disableStoreAssignmentFirst build the image:
docker build . -t moodle-data-proxyThen 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-proxyReplace 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.
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', ' |
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-proxyNow 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 upto 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 mysqlThen, to access it:
sudo docker exec -it mysql mysql -pWhen prompted for the password enter password. Now the mysql console should start. Create the desired database using:
create database LAS2PEERMON;
exitThis has now set up the database. Now running the command:
sudo docker-compose upshould run the system correctly. If the system seems to be deadlocked in some fashion, consider running:
sudo docker-compose up --force-recreateThe following xAPI verbs have been implemented, in regards to what Moodle API responds:
| 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 |