10.2 Organisation

TODO: cette organisation plus complexe utilisant deux serveurs MongoDB ne convient pas à tous. Remainer en présentant une organisation classique autour d’un seul serveur, puis présenter de manière optionnelle la version avec deux serveurs, plus sécuritaire.

Ce type de base de données permet de stocker des données semi-structurées qui correspond bien à des évènements xAPI. Par sécurité, une base de données MongoDB locale est créée sur sur le serveur RStudio Connect. Elle n’est pas disponible depuis l’extérieur. Donc, seules les applications exécutées à partir de RStudio Connect y ont accès. Par contre, cela ne permet pas d’enregistrer les données générées ailleurs (H5P, applications learnr ou shiny exécutées localement …). Ainsi, nous déployons une seconde base MongoDB sur le cloud via MongoDB ATLAS. Cette dernière sert uniquement à collecter transitoirement les données externes au serveur. Ensuite, un script sur RStudio Connect est exécuté à intervalle régulier pour rapatrier ces données externes dans la base de données interne.

La solution à deux serveurs offre les avantages suivants :

  • Sécurité maximale des données une fois rapatriées dans la base sur le serveur dédié (parce qu’elle n’est pas accessible de l’extérieur).
  • Duplication des points d’accès (et MongoDB ATLAS utilise trois serveurs différents sur le cloud) afin de garantir que les données puissent toujours être récoltées, même si le serveur dédié ne répond plus (résilience en cas de panne).

10.2.1 Base interne

TODO: expliquer l’installation et le fonctionnement de la base MongoDB interne.

Pour tester l’accès à un port afin de vérifier si la base MongoDB est accessible, on peut utiliser la commande nc (netcat) ou netstat. Par exemple, pour tester le port 27017, on peut faire ceci :

# Accès en local (il faut succeeded!)
nc -zv 127.0.0.1 27017
# Accès distant (remplacer xxx.xxx.xxx.xxx par l'adresse ip du serveur)
nc -zv xxx.xxx.xxx.xxx 27017
# En local pour déterminer l'état du port 27017
netstat -pano | grep 27017

On peut aussi directement tester l’accès à la base MongoDB avec les outils en ligne de commande installés depuis un ordinateur distant comme ceci :

mongo "mongodb://xxx.xxx.xxx.xxx:27017"
db
quit()

10.2.2 Base externe

TODO: expliquer l’installation et le fonctionnement de la base MongoDB externe. Deux comptes, par exemple, input avec des droits limité uniquement en écriture pour l’introduction des données et teacher avec des droits en lecture et écriture.

10.2.3 Format des données

Si vous utilisez les fonctionnalités {learnitdown} dans votre bookdown, vous pouvez diversifier l’offre d’exercices (H5P, Shiny, learnr). Il vous faudra bien entendu pouvoir enregistrer l’activité dans ces différents exercices. Afin d’éviter la multiplication des formats de données, la plateforme LearnIt::R LRS homogénise la présentation des événements entre les différentes applications. Ces données sont toutefois enregistrées dans des collections différentes (h5p, learnr et shiny) dans la base MongoDB. Chaque entrée contient les champs suivants :

  • **_id:** C’est l’identifiant unique du document MongoDB attribué automatiquement lors de son insertion

  • session: La session à partir de laquelle l’évènement a été généré. Cette information est surtout utile pour les applications Shiny. Pour H5P, c’est un identifiant complémentaire de l’utilisateur enregistré qui est indiqué. Le plus souvent du type email: mailto:user@site.com, mais pas forcément. Les tutoriels learnr n’introduisent rien dans ce champ.

  • date: La date au format GMT à laquelle l’évènement a été généré. Cette date est enregistrée à la microseconde près, mais la résolution réelle est moins bonne (probablement entre 50 à 150µsec, sauf pour les applications Shiny où le temps est comptabilisé à la milliseconde près).

  • id: Uniquement pour H5P, l’identifiant du widget, le numéro à rentrer dans le shortcode, par exemple, [h5p id="3"] pour l’item 3.

  • app: L’identifiant textuel de l’application, voir convention pour le nom des applications ci-dessous.

  • version: Le numéro de version pour les apps Shiny et learnr. Les applications H5P n’ont malheureusement pas de numéro de version. Ce champ contient donc null dans ce cas, sauf s’il s’agit d’un “sous-contenu” (voir convention de noms d’apps ci-dessous), dans ce cas, nous aurons l’identifiant du sous-contenu.

  • user: Utilisateur actuel sur la machine où l’application s’exécute.

  • login: Login GitHub/Wordpress de l’utilisateur (peut être le même ou différent de user).

  • email: Adresse mail institutionnelle (valeur passée par Moodle dans iemail). Pour les applications H5P, l’email Wordpress est renseigné généralement dans session, s’il a été défini. Pour les applications Shiny, l”identification complète de l’utilisateur, y compris son email Wordpress se retrouve dans le champ data pour l’évènement started.

  • course: Le cours que suit l’étudiant, sous forme de l’identifiant interne, Moodle ou autre.

  • institution: Nom de l’institution où l’étudiant est enrôlé.

  • verb: Le verbe xAPI correspondant à l’évènement (voir ci-dessous verbes xAPI).

  • correct: "TRUE" ou "FALSE" uniquement pour les évènement correspondant à des réponses à une question, donc les verbes answered (pour les questions) ou submitted (pour du code R). Dans les autres cas, sa valeur est "", sauf si une application Shiny a été lancée, mais sans que l’utilisateur ne clique jamais sur le bouton Submit. Dans ce cas, la valeur vaut "NA".

  • score: Nombre de points obtenus pour la question. Dépend de l’application. Pour les H5P, il s’agit du nombre d’items corrects moins le nombe d’items erronés. Pour Shiny, c’est le nombre de widgets correctement positionnés par rapport au nombre testé dans la solution. Enfin pour learnr, c’est 0 ou 1 selon que la question est complètement correcte ou pas. Pas pertinent en dehors de réponses et donc ce champ vaut null dans ce cas.

  • max: Score maximum pouvant être obtenu pour la question. Dépend du contexte. En dehors de réponses aux question, ce champ vaut 0.

  • grade: La fraction de bonne réponse, ou autrement dit, une note sur 1 pour la question. Si on a 1 la réponse est totalement correcte, mais si on a 0.5, elle ne l’est qu’à moitié. En dehors de réponse à une question, ce champ n’a pas de sens et sa valeur est null.

  • label: Le libellé de l’item générant l’évènement. Pour Shiny, c’est le nom du widget. Pour H5P, c’est le texte de la question, etc.

  • value: La valeur sélectionnée pour le widget Shiny, ou la réponse donnée pour H5P, par exemple. Dépendant du contexte.

  • data: Des données complémentaires sous forme d’une chaîne de caractères contenant un objet JSON. Pour H5P, il s’agit de l’évènement xAPI généré. Pour learnr, il s’agit d’une partie du contenu (moins correct et label qui sont extraits dans les champs correspondant). Pour Shiny il s’agit d’informations complémentaires sur les widgets.

10.2.4 Verbes xAPI

Les évènements xAPI de H5P sont déjà décrits par des verbes. Par contre, les évènements Shiny ou learnr sont décrits par des dénominations propres. Afin d’homogénéiser le tout dans la plateforme LearnIt::R, tous les évènements Shiny et learnr sont traduits en verbes xAPI selon le tableau suivant :

Verbe xAPI learnr shiny H5P Remarque
started session_start start L’utilisateur a démarré activement une application
attempted attempted L’utilisateur arrive sur un H5P (différent de started)
exited inputs/quit L’utilisateur quitte volontairement (différent de stopped)
stopped session_stop stop L’application s’est arrêtée
displayed section_viewed L’utilisateur visualise une section
progressed section_skipped progressed L’utilisateur avance dans les exercices (différent de displayed)
seeked video_progress Progression dans une vidéo
interacted inputs interacted Dans Shiny: sauf boutons ‘submit’ & ‘quit’
answered question_submission answered Réponse à une question (hors code R)
reset reset_question_submission Nouvel essai après une réponse erronée
executed exercise_submission Bouton ‘Run Code’ dans learnr
evaluated exercise_result Résultat de l’évaluation du code R, si correct == “”
submitted exercise_result inputs/result Idem, mais si correct != “” dans learnr, Bouton Shiny ‘submit’
computed outputs Par défaut, les outputs ne sont pas enregistrés dans Shiny
debugged errors Erreur détectée dans une app Shiny
assisted exercice_hint Sauf si dernier hint = réponse => revealed
revealed exercice_hint Pour les boutons ‘solution’ dans learnr & dernier ‘hint’
completed completed Dans H5P, un bilan général est calculé à la fin